Exploring the Blind Spot of IXP Route Server#

Stefano Servillo, Sapienza University of Rome

• Why: Most peering-edge routing security attention goes to RPKI, but IRR-based route-server filtering — still the primary mechanism at most IXPs — has a structural hole that enables prefix hijacking. If you peer via route servers, this is a direct exposure assessment.
• What: The blind spot: IRR validation expands a member's AS-SET into a prefix list but never binds a prefix to its real owner. So an attacker whose route object for a prefix lists an AS that appears in some member's AS-SET gets their (hijacked or misconfigured) announcement accepted by the route server. The authors found most analyzed IXPs in the EURO-IX community affected, and validated the practical impact against real route-server RIBs of two major European IXPs. Feasibility is real: roughly a third of prefixes are RPKI NotFound (no ROA coverage), leaving IRR as the only filter — and AS-SETs are badly maintained (they accumulate inactive ASes against ~77k active of ~130k allocated, plus duplication in non-authoritative IRRs).
• How: Walks through how IXPs compile IRR data (bgpq4 expansion into prefix lists linked to peer sessions), derives the attack preconditions (no covering ROA, prefix in a route object for an AS that's in a member's AS-SET), and proposes fixes for both IXP operators (filtering changes) and members (ROA coverage, AS-SET hygiene).
• Where applicable: Applies to any IXP using IRR-based RS filtering and any member relying on RS filtering instead of bilateral sessions. The validation data is from two large European IXPs, but the mechanism is protocol-level and general.