Your AS-set is crucial to your routing security. 3 tips on securing your AS-set#

Lasse Jarlskov — Telia

• Why: Routing security hygiene with a concrete rule of thumb and free tooling — the kind of immediately actionable operator talk this digest exists to surface. Mismanaged IRR AS-SETs are a real leak/hijack vector via recursive expansion.
• What: Three tips from a transit operator: (1) know your AS-set's purpose — customer vs. peer vs. IXP-member sets serve different filter-building use cases and conflating them causes confusion (example: AS-DATAIX, an IX AS-set that expands to more ASNs and prefixes than the global table, with a shown inclusion chain from AS-DATAIX down to Bahnhof's AS8473); (2) watch what you include — recursive references are powerful and dangerous, bigger is not better, check the size of customers' AS-sets; (3) monitor who includes you — every inclusion of your ASN/AS-set in someone else's policy is a potential hijack or leak affecting your customers, with no automatic approval mechanism.
• How: RPSL/IRR objects built into upstream route filters; audit via bgp.tools' reverse-inclusion tool and Cloudflare Radar's IRR AS-set view; the recurring decision heuristic is "would you readvertise this in BGP?" — if not, it doesn't belong in the set.
• Where applicable: General technique, applicable to any network with transit customers, peering, or route-server sessions — no scale or topology dependency. References (DKNOG, Kentik, MANRS, Cloudflare) are all public. Based on the slide deck (no abstract was published).