False Immunity: long prefixes that bypass ROV#

Bryton Herdes – Cloudflare

• Why: ROV deployment creates false confidence — this talk demonstrates two concrete bypass classes with live tests against tier-1 networks. Routing security at its most operational.
• What: (1) Long-prefix "TE" announcements: at least two tier-1s (Lumen AS3356 for IPv4, Zayo AS6461) accept RPKI-invalid >/24 and >/48 prefixes, apparently filtering on IRR only — enabling the demonstrated 1.1.1.1/32 hijack accepted via AS8452/AS3356. Tested by advertising purposely invalid /32 and /128s to peers one-by-one and checking reachability from looking glasses. (2) RTBH: blackhole routes are generally exempt from RPKI filtering (IRR-based, long by nature, RFC 7999 community), creating a hijack vector that took a Tier-1. Proposed fixes: loose ROV restricted strictly to RFC 7999 BLACKHOLE routes, or a dedicated RPKI Discard Origin Authorization object (draft-spaghetti-grow-rpki-doa); vendor feature requests (Cisco IOSXR-I-1742, Juniper ROUTSP-I-71, Arista RFE 1964539) are pending.
• How: Active measurement from Cloudflare's peering position, plus the tension spelled out: RFC 9319 minimal ROAs (maxLength) vs long-prefix TE, and the forged-origin-hijack tradeoff of maxLength=32 ROAs.
• Where applicable: Every ROV-validating network (check whether you exempt long prefixes or blackhole routes) and every prefix owner publishing ROAs. Test method is limited by Cloudflare's relationship types with the tested ASes, as the speaker notes.