BGP security and convergence: route leaks, RPKI, next-hop tracking, Add-Path and PIC

What goes wrong in internet routing

A BGP router believes what its neighbours announce. Two kinds of incident follow from that:

• Prefix hijack: an AS announces address space it does not hold, by mistake or on purpose, and attracts traffic for it. A more specific prefix is especially effective, because longest match wins everywhere.
• Route leak (defined in RFC 7908): routes are passed on beyond their intended scope, for example a customer re-announcing one provider's routes to another, as in the transit AS problem in BGP filtering.

Both have caused well-known regional outages. Defences are layered: filter what customers and peers may send, validate origins with RPKI, and protect the sessions themselves. The industry initiative MANRS (Mutually Agreed Norms for Routing Security) sets out these practices for operators.

RPKI route origin validation

The Resource Public Key Infrastructure (RPKI) lets the holder of an address block publish a signed Route Origin Authorisation (ROA): "prefix 203.0.113.0/24, up to length /24, may be originated by AS 64500". A validator, run by you or a trusted party, collects and checks ROAs and feeds the results to routers using the RPKI-to-Router (RTR) protocol. Each received route then gets one of three states:

• Valid: a ROA covers it and the origin AS and length match.
• Invalid: a ROA covers the prefix, but the origin AS or length is wrong. Most large networks now drop these.
• Not found: no ROA covers it; accept it, since much address space still has no ROA.

router bgp 64500
 bgp rpki server tcp 10.1.9.10 port 3323 refresh 600
 neighbor 198.51.100.1 route-map RPKI-IN in
route-map RPKI-IN deny 10
 match rpki invalid
route-map RPKI-IN permit 20

RPKI validates the origin only, not the whole path. Path validation is developing through ASPA (Autonomous System Provider Authorisation). Publish ROAs for your own prefixes as well as validating others: it protects your addresses from being hijacked.

Protecting the sessions

• TTL security (GTSM): neighbor x ttl-security hops 1 only accepts packets that arrive with a TTL showing they came from one hop away, which stops remote spoofed attacks on the session.
• Authentication: TCP MD5 passwords (neighbor x password), or TCP-AO where supported.
• Maximum-prefix: shut down or warn if a neighbour sends far more routes than expected, a typical sign of a leak.
• Control plane protection and filtering TCP 179 from anyone who is not a configured peer, as covered in securing routing.

Faster convergence

BGP was designed for stability, not speed. With default timers, a silent neighbour is only declared dead after the 180-second hold time. Modern features close the gap:

• Fast external fall-over and BFD: drop the session as soon as the link goes down, or use Bidirectional Forwarding Detection to detect a failure in milliseconds.
• Next-hop tracking: BGP watches the routing table for changes to its next hops and reacts within seconds, rather than waiting for a periodic scan.
• Add-Path (RFC 7911): advertise more than one path per prefix, so routers behind a route reflector already know a backup.
• Prefix Independent Convergence (PIC): pre-install a backup path in the forwarding table. When a next hop fails, the router switches every affected prefix at once, regardless of how many there are.

Real-world example: a regional internet provider's customer misconfigured a new router and re-announced several thousand routes learned from another provider, including more specifics of a popular cloud service's prefixes. Because the provider applied per-customer prefix lists built from registry data, plus a maximum-prefix limit, the session was shut down automatically and none of the leaked routes spread. The provider also validated RPKI and dropped invalid routes, which would have caught any announcement with the wrong origin AS.