BGP Security and Route Filtering
BGP Security and Route Filtering
This domain tests the controls that stop a peer from sending you a default route, a full table or someone else's prefix, plus the validation frameworks layered on top.
Controls you configure
Prefix limits: prefix-limit under the neighbor with a threshold percentage for logging and an idle-timeout to hold the session down after a breach. Set the maximum modestly above the expected table size so a peer's normal growth does not take the session down.
Filters: inbound prefix-lists accepting only what the peer should announce, AS_PATH filters rejecting paths containing your own AS or bogons, martian prefix filters, and explicit denial of the default route unless contractually expected. Outbound filters prevent you leaking transit to a peer.
Session protection: TCP MD5 (authentication-key) is legacy; TCP-AO (RFC 5925) with key chains is its replacement. GTSM (ttl-security, RFC 5082) requires TTL 255 on eBGP packets and drops off-path spoofing attempts.
Origin validation: RPKI ROAs let a router classify a route as Valid, Invalid or NotFound (RFC 6811). SR OS supports RPKI sessions and origin-validation policy that can reject Invalid. RPKI validates origin only, so route leaks still pass.
Worked example
A peer is expected to send at most 900,000 prefixes. Configure prefix-limit maximum 950000 threshold 90 log-only, watch the logs, then remove log-only and add idle-timeout 300. A jump to 950,000 then trips the limit and holds the session down for five minutes rather than flapping indefinitely.
Traps
Setting the limit at exactly the current table size; rejecting Invalid routes without monitoring NotFound; treating MD5 as strong authentication; and believing RPKI prevents path manipulation or route leaks.