The Scourge of Excessive AS-SETs#

Jac Kloots, Kentik

• Why: IRR AS-SETs remain the operational backbone of BGP filtering, and this talk quantifies — with real case data — how uncontrolled nesting has made many of them useless as allowlists, then points at the actual fix (ASPA, RFC 9234). Directly relevant to network security and BGP-internals work.
• What: An analysis anchored on the March 11, 2024 MTS (AS8359) / HKIX route leak. The leaker's AS-MTU expands to 43,823 ASNs; bgpq4 -J produces a ~1.29M-line Junos config (271k lines even with -A aggregation) covering 1.8 billion of the ~3 billion routable IPv4 addresses — so any transit filtering on AS-MTU is effectively filtering nothing. The largest AS-SETs (e.g., AS39533:AS-PEERS) expand past 100k ASNs, exceeding the ~90k ASNs in the global table, because nested sets pull in unrouted ASNs; 2,192 AS-SETs expand beyond 1,000 ASNs. A traced nesting chain from AS-XUA-UA runs Ukraine → NL-IX → Balkan-IX → TTK → CN2 → South Africa → CTGNet → Rostelecom before landing on an unrouted Russian air-traffic-corporation ASN. Root cause: AS-SETs mix semantically undefined member types (customers, peers, IXP members) with no limits on membership or recursion depth.
• How: Recursive IRR expansion mechanics; tools (bgpq4, irrtree, bgp.tools) as measurement instruments; a key operational gotcha — AS-SET contents differ by source IRR (NTT mirror is bgpq4's default), so authoritative source must be declared, e.g., in PeeringDB. Proposed long-term fix: RFC 9234 BGP role signaling in-band, RPKI ASPA verification, and Signed Prefix Lists, rather than ever-larger self-asserted allowlists.
• Where applicable: Every transit operator filtering with IRR data. Speaker is from an observability vendor, but this is data analysis with named collaborators (bgp.tools, Comcast, Cogent, Google, Telia), not a product pitch.