Theoretical foundations and architecture

Security of external inter-operator BGP routing rests on three mechanisms: ingress and egress filters (prefix-list, AS-path), prefix limits (Maximum-Prefix) and route origin validation with RPKI ROV (RFC 6811). 1. RPKI ROV: a ROA (Route Origin Authorization, RFC 6482) is a signed record of "prefix, permitted origin ASN, maxLength"; the resource holder signs it with a certificate issued through the RIR hierarchy (RIPE NCC, ARIN, APNIC and other trust anchors). A validator (Routinator, rpki-client, FORT) downloads the repositories, verifies the signatures and hands the validated tuples to the router over the RTR protocol (RFC 6810, version 1 in RFC 8210; the registered port is TCP 323 and many validators listen on an unprivileged port such as 3323). Krill is certificate-authority software, not a validator. The router classifies every route: Valid, Invalid (a different origin ASN or a prefix longer than maxLength) or NotFound (no ROA). Operator policy: reject Invalid on ingress, optionally prefer Valid and accept NotFound. ROV checks only the origin ASN: it does not catch a forged AS path (forged origin) or route leaks, and if the RTR session stays down longer than the expire interval the cache is emptied and every route becomes NotFound (fail-open). 2. Maximum-Prefix: protection of RIB memory. If a customer or peer announces more prefixes than agreed (for example above 100), the router warns at a 75-90% threshold and tears the session down when the limit is exceeded.

Why BGP needs external protection

BGP does not check whether the neighbouring AS has the right to announce a prefix: any peer can announce someone else's network (a hijack) or pass on a route that should never have left its boundary (a route leak). Classic examples are the announcement of a YouTube subnet from the Pakistan Telecom AS in 2008 and the route leak through providers in 2019. The protection is built in three layers: prefix and AS-path filters on ingress and egress (whom we listen to and what we announce), prefix-count limits (resource protection) and route origin verification through RPKI (ROV, RFC 6811).

Ingress filters: what to always drop

  • Bogon prefixes: 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, 224.0.0.0/3 and their longer parts (the list uses le 32). The same applies to IPv6 (::/8, fc00::/7, fe80::/10, ff00::/8, 2001:db8::/32).
  • Prefixes that are too long: in the public network the usual maximum is /24 (IPv4) and /48 (IPv6). Longer routes are not propagated and clog the tables.
  • A default route from a peer, unless it was agreed.
  • Bogon ASNs in the path: AS 0 (RFC 7607), AS_TRANS 23456, documentation ASNs 64496-64511, private 64512-65534 and 4200000000-4294967294 in a path that came from the outside world.
  • Customer filters are strict: the list of permitted customer prefixes is built from IRR/AS-SET records (generators such as bgpq4) and refreshed automatically; customer traffic must not be able to become transit between providers.
  • Egress: the operator announces only its own and customer prefixes. Routes learned from peers and upstreams are not passed on to peers and upstreams.

Prefix limit

maximum-prefix (Cisco), route-limit (Huawei) and prefix-limit (Junos) protect RIB/FIB memory and tear down the session of a neighbour that suddenly sends too much. The value is chosen as the real number plus a margin (on public peerings PeeringDB data is the guide), the warning threshold is 75-90%, and after it triggers the session can be restarted automatically (restart N minutes / idle-timeout) or kept down until manual intervention. Counting differs between platforms: some count all received prefixes, others only those accepted by policy. This has to be checked on the target release, otherwise the ingress filter will never let the count reach the limit.

RPKI and ROV: components

  • ROA (Route Origin Authorization, RFC 6482) is a signed record: a prefix, the permitted origin AS and maxLength. It is signed with a resource certificate of the RIR (RIPE NCC, ARIN, APNIC and other trust anchors).
  • Relying party / validator (Routinator, rpki-client, FORT, OctoRPKI) downloads the repositories, verifies the signatures and produces a list of valid bindings (prefix, maxLength, ASN). Krill is certificate authority software, not a validator.
  • RTR (RPKI-to-Router, RFC 6810, version 1 in RFC 8210) is the protocol through which the router receives these bindings from the validator. The registered port is TCP 323; many validators listen on an unprivileged port by default (for example, Routinator - 3323). RTR can run over SSH or TLS, but labs usually use plain TCP.

The ROV algorithm (RFC 6811)

For a route (prefix P, origin AS being the last one in the AS-path), all ROAs covering P are looked up. If there are no covering ROAs, the state is NotFound. If there is a ROA with the same ASN and the length of P is not greater than maxLength, the state is Valid. Otherwise it is Invalid (a foreign ASN or a prefix that is too long). A ROA with ASN 0 (RFC 6483) makes the prefix always Invalid. The operator's policy is this: Invalid is dropped, Valid may be preferred (for example, Local-Pref 120), NotFound is accepted with the normal priority: for a significant share of prefixes a ROA has not been created yet, and rejecting them would harm traffic.

How it works on the platforms

  • Cisco IOS-XE: bgp rpki server tcp defines the validator, and the route-map gets the conditions match rpki valid|invalid|not-found. bgp bestpath prefix-validate allow-invalid keeps Invalid routes as best-path candidates so that policy controls them (by default the state itself influences selection). The state is recomputed on every cache update, so it must be possible to re-evaluate (route refresh or Adj-RIB-In storage).
  • Juniper Junos: routing-options validation group ... session attaches the validator, and policy uses from validation-database valid|invalid|unknown; the state is visible in show route ... detail (Validation State).
  • Huawei VRP: prefix filters, AS-path filters and route-policies are given in the lesson code; ROV configuration depends on the release and is moved to review.
  • MikroTik RouterOS v7: the lesson uses route filters (/routing/filter/rule) and a limit on the connection; for ROV on RouterOS, check the documentation of the installed version.

Validator failure: fail-open

If the RTR session is unavailable for longer than the expire interval (by default 7200 seconds per RFC 8210), the router deletes the cache entries, and all routes become NotFound: the protection is silently switched off. That is why at least two validators are kept in different locations, the cache serial number and the time of the last update are monitored, and an alarm is raised when the session is lost. Local exceptions (SLURM, RFC 8416) allow a ROA to be added or cancelled manually.

Preventing route leaks

The usual technique is community marking by source: customer routes get 65000:100, peer routes 65000:200, upstream routes 65000:300, and the outbound policy to peers and upstreams permits only the 65000:100 tag (and the operator's own routes). The newer approach is BGP roles and the Only-to-Customer attribute (RFC 9234): the sides declare roles (provider, customer, peer, rs-server, rs-client), and routes that violate the model are dropped automatically. Support depends on the release.

Protecting the session itself

Filters do not help if the neighbour can be impersonated: TCP MD5 or TCP-AO authentication (RFC 5925) and GTSM (RFC 5082) are configured in the hardening lab. What matters here is that RPKI and filters check the content of the announcement, not who actually sent the TCP segment.