Complementary Mechanisms: IRR Filtering, Prefix Filters and AS_PATH Filters

Author

K19G

Updated

October 31, 2026

Complementary Mechanisms: IRR Filtering, Prefix Filters and AS_PATH Filters

Because RPKI ROV only authenticates the origin of a route, robust edge security requires defense in depth. Network operators must combine ROV with deterministic inbound and outbound prefix filtering, regular-expression AS_PATH filtering, and hardware resource limits.

Prefix Filters: What Prefixes Should Be Announced

Every eBGP session must enforce strict boundaries on what prefixes may be received and transmitted:

1. Bogon and Special-Purpose Filtering

Routers must unconditionally discard advertisements for IP space that should never appear on the public Internet (RFC 6890): - IPv4 Bogons: 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4 (Multicast), 240.0.0.0/4. - IPv6 Bogons: ::/8, 0100::/64, 2001:db8::/32, fe80::/10, fc00::/7 (ULA), ff00::/8 (Multicast).

2. Prefix Length Boundaries

  • In IPv4: drop any prefix smaller than /8 or longer than /24.
  • In IPv6: drop any prefix smaller than /19 or longer than /48.

AS_PATH Filters: Detecting and Rejecting Suspicious Paths

Operators use regular expressions (regex) to inspect AS_PATH segments:

! Reject private ASNs, reserved ASNs, or path anomalies (Cisco IOS XR / Junos)
as-path-set BOGON-ASNS
  64512-65534,          # 16-bit Private ASNs
  65535,                # Reserved
  4200000000-4294967294 # 32-bit Private ASNs
end-set

! Reject routes containing bogon ASNs in transit
if as-path enters-with BOGON-ASNS then
  drop
endif

! Customer session enforcement: enforce that the first hop in AS_PATH matches customer's configured ASN
if not as-path starts-with ^65001 then
  drop
endif

By enforcing that the first ASN in the AS_PATH matches the neighbor’s ASN, an ISP prevents a customer from spoofing direct peering sessions with other networks.

IRR-Based Filtering: Still Relevant After RPKI

While RPKI validates origins, IRR filters validate topology and customer cones: - An ISP queries the customer’s as-set (e.g., AS-HURRICANE) using bgpq4. - The tool recursively expands all downstream customer ASNs and their registered route objects into an explicit prefix-list. - Even if an attacker uses a valid origin ASN to execute a route leak, the route is rejected at the ISP’s border because it is not registered inside the customer’s legitimate IRR cone.

Maximum-Prefix Limits: Protection Against Table Poisoning

Every BGP session must be configured with a hardware safety valve: the Maximum-Prefix Limit:

! FRR / Cisco IOS Syntax
router bgp 65001
 neighbor 192.0.2.2 maximum-prefix 100 80 restart 15
  • If a customer who normally announces 5 prefixes accidentally leaks 100,000 routes, the moment the count crosses \(80\) (80%), the router issues a high-severity syslog alarm.
  • When the count exceeds \(100\), the router immediately sends a BGP NOTIFICATION (Cease / Maximum Number of Prefixes Reached) and tears down the TCP session.
  • This protects the router’s control-plane CPU and TCAM from buffer exhaustion.

BGP Communities for Policy Signaling and Leak Prevention

Operators classify every imported route using internal BGP communities:

Community Operational Meaning Policy Action
65000:100 Learned from Customer Propagate to Transit, Peers, and Customers
65000:200 Learned from Settlement-Free Peer Propagate to Customers only; NEVER to Transit
65000:300 Learned from Paid Transit Provider Propagate to Customers only; NEVER to Peers or Transit

Before exporting routes to any external transit provider or lateral peer, an export route-map checks the community. Any route carrying 65000:200 or 65000:300 is unconditionally suppressed, programmatically guaranteeing that the network cannot become an accidental transit pipe.