BGP and Routing Security Guide: RPKI and Route Origin Validation

The Border Gateway Protocol still believes almost any route announcement it hears, so one mistyped prefix or one malicious network can pull traffic for someone else's addresses across the internet in minutes. BGP hijacks and route leaks have taken major services offline, and the fixes are now mature enough that governments expect operators to deploy them. This guide covers how BGP trust fails, RPKI and route origin validation, BGPsec, ASPA and BGP roles, prefix and IRR filtering, session security, MANRS and the 2024 US policy actions, then rollout, monitoring and hijack response. It is for network engineers at ISPs, hosting and cloud providers, and enterprises that hold their own IP space or run their own autonomous system (AS).

Key takeaways

• Origin validation is the baseline. Publish Route Origin Authorizations (ROAs) for every prefix you hold and drop RPKI-invalid routes on every external session; this catches origin mistakes and simple hijacks before they spread.
• ROV alone does not validate the path. RFC 6811 says it "does not protect against "AS-in-the-middle attacks" or provide any path validation", so forged-origin hijacks and route leaks need filtering, BGP roles (RFC 9234) and, as it matures, ASPA.
• Keep ROAs minimal. RFC 9319 says "operators SHOULD avoid using the maxLength attribute in their ROAs", because a loose maxLength authorises more-specific announcements an attacker can forge.
• Filters still do most of the work. Customer prefix lists from the Internet Routing Registry (IRR) and RPKI, maximum-prefix limits, AS path filters and bogon filters are what stop a customer's mistake from becoming everyone's outage.
• Routing security is an identity problem too. Whoever controls your Regional Internet Registry (RIR) account controls your ROAs, and whoever holds router admin credentials controls your announcements, so treat both as privileged access.

How BGP trust works and where it fails

BGP-4 (RFC 4271) is the path-vector protocol that autonomous systems use to tell each other which IP prefixes they can reach. Sessions run over TCP; RFC 4271 states "BGP listens on TCP port 179." Routes are carried in UPDATE messages, alongside OPEN, KEEPALIVE and NOTIFICATION. Each BGP announcement carries the prefix and an AS_PATH listing the networks it has crossed, with the originating AS last.

Two design facts drive almost every case of BGP hijacking, prefix hijacking or lost BGP routing integrity. First, the base protocol has no way to check that the origin AS is entitled to announce a prefix, or that the AS_PATH is real. Second, routers forward along the longest matching prefix, so a more specific BGP announcement (a /24 inside someone else's /22) wins over the legitimate, shorter route wherever it propagates.

The classic route hijacking example is well documented by the RIPE NCC. On 24 February 2008 Pakistan Telecom (AS17557) announced 208.65.153.0/24, a more-specific of YouTube's 208.65.152.0/22, and its upstream PCCW (AS3491) propagated it. YouTube announced two /25s at 20:18 UTC to pull traffic back, and the hijack ended when PCCW withdrew the routes at 21:01 UTC. A customer prefix filter at the upstream would have stopped it at the first hop.

RPKI, ROAs and route origin validation

The Resource Public Key Infrastructure (RPKI, architecture in RFC 6480) mirrors the address allocation hierarchy: IANA, the five RIRs, then national or local registries and address holders. A resource certificate binds a key to IP prefixes or AS numbers. A Route Origin Authorization (ROA, also spelt route origin authorisation) is, in RFC 6480's words, "an attestation that the holder of a set of prefixes has authorized an autonomous system to originate routes for those prefixes." Each ROA names one AS, a list of prefixes and an optional maximum length.

Route origin validation (ROV) is how a router uses that data. Validator software (the relying party) downloads and checks the signed objects from the RIR repositories, which RFC 6480 calls "the untrusted clearing-house for all signed objects", builds a list of Validated ROA Payloads (VRPs) and feeds them to routers over the RPKI-to-Router protocol (RFC 8210). The router then tags each route with one of three states from RFC 6811:

A VRP matches when it covers the prefix, the route is no longer than its maxLength and the origin AS is the same. If a ROA allows 192.0.2.0/24 for AS64500, the /24 from AS64511, or a /25 from AS64500, is Invalid.

Writing good ROAs

• Minimal ROAs: list only the prefixes you actually announce. RFC 9319 explains the forged-origin sub-prefix hijack: a ROA for a /16 with maxLength 24 authorises every /24 inside it, so an attacker can announce an unused /24 with your AS as origin and pass ROV. Its June 2017 measurement found 84% of maxLength prefixes were non-minimal.
• Cover every origin: if a DDoS scrubbing provider or CDN announces your space during an attack, it needs its own ROA for its AS. RFC 9319 allows a pre-created non-minimal ROA for this case only.
• AS0 for unused space: a ROA naming AS0 (RFC 6483, RFC 7607) says nobody should originate the prefix, which turns any announcement of dormant space into an Invalid route.
• Hosted versus delegated RPKI: most holders use the RIR's hosted certificate authority and manage ROAs in its portal. Run your own (delegated) CA only if you need automation the hosted service lacks and can keep it highly available.

Beyond the origin: BGPsec, ASPA and BGP roles

AS path validation is the unfinished part of routing security. Three mechanisms address it.

The ASPA draft states limits: added or removed prepends are not detected, and some provider-driven manipulation can pass. RFC 8205 says BGPsec "is intended to be used to supplement BGP origin validation", not replace it. Plan for ROV now, roles where supported, ASPA as support arrives, and BGPsec only for a specific requirement.

Route leaks

RFC 7908 defines a route leak as "the propagation of routing announcement(s) beyond their intended scope" and classifies six types. Two common causes of BGP route leak outages are Type 1, a hairpin turn where a multihomed customer passes routes from one upstream to another, and Type 6, the accidental leak of internal or more-specific prefixes. RFC 7908 records the Telekom Malaysia leak of about 179,000 prefixes accepted by Level3, and a 2014 event where about 22,000 more-specific prefixes leaked from AS701 and AS705.

Route leaks usually pass ROV because the origin is unchanged. What stops them:

• Customer-only acceptance: accept from a customer only the prefixes registered to it and its customers, built from IRR route objects and ROAs.
• Maximum-prefix limits: a customer that normally sends 20 routes should lose its session at, say, 50, not at a full table.
• AS path filters: reject routes from a customer or peer whose AS_PATH contains a large transit network the neighbour would never legitimately sit in front of.
• Roles and OTC: RFC 9234 treats a route carrying OTC that arrives from a Customer or RS-Client as a leak, and the marking lets compliant networks several hops away detect it.
• Export by relationship: tag routes on ingress as customer, peer or transit, and export to peers and transits only customer and own routes.

Prefix filtering, IRR and BGP session security

RFC 7454 (BCP 194, BGP Operations and Security) is the operational baseline. BGP prefix filtering comes first.

• IRR filtering: build per-neighbour prefix lists from the customer's AS-SET and route objects in the Internet Routing Registry, refreshed at least daily as RFC 7454 suggests. Most IRR data is not authenticated, so cross-check against RPKI and prefer RIR-operated registries.
• Bogons and special-purpose prefixes: drop prefixes IANA marks as not globally routable, and private or reserved AS numbers in paths from non-customers.
• Too specific: RFC 7454 notes that IPv4 prefixes longer than /24 and IPv6 longer than /48 are generally neither announced nor accepted. This is also why defenders cannot out-specific a /24 hijack and must rely on ROV and upstream action.
• Path sanity: reject your own AS in received paths, and require the first AS to be the neighbour's except at transparent route servers.

BGP session security

• Control-plane ACL: allow TCP 179 only from configured neighbours; rate-limit the rest.
• GTSM (RFC 5082): send with TTL 255 and require 255 on receipt, so spoofed packets from off-link hosts cannot reach the BGP process.
• TCP-AO (RFC 5925) or MD5 (RFC 2385): RFC 7454 says "TCP-AO SHOULD be preferred when implemented"; MD5 persists because both ends support it. Either way the keys are shared secrets needing rotation and an owner.
• Source address validation: apply BCP 38 (RFC 2827) and BCP 84 (RFC 3704) ingress filtering or unicast RPF on customer edges so your network cannot be used for spoofed-source attacks. This is MANRS anti-spoofing and is covered in NIST SP 800-189 alongside DDoS mitigation; see the DDoS Protection Guide.

MANRS and the policy landscape

MANRS (Mutually Agreed Norms for Routing Security) is an industry initiative with programmes for network operators, internet exchanges, CDN and cloud providers, and equipment vendors. The four network operator actions are:

1. Filtering: "Ensure the correctness of your own announcements and those from your customers to adjacent networks."
2. Anti-spoofing: source address validation "for at least single-homed stub customer networks", their end users and your own infrastructure.
3. Coordination: keep contact details current in the routing databases so other operators can reach you during an incident.
4. Global information: "Publish your data so others can validate", meaning IRR objects and ROAs.

Governments are now asking for the same things. The White House Office of the National Cyber Director published its Roadmap to Enhancing Internet Routing Security on 3 September 2024 with 18 recommended actions, including "All network operators and entities holding IP address resources should create and publish ROAs" and "Network service providers should deploy ROV filtering for their customers or arrange for upstream providers to do so." On 6 June 2024 the US Federal Communications Commission adopted a Notice of Proposed Rulemaking (FCC 24-62, PS Docket 24-146) proposing that broadband providers prepare and update confidential BGP security risk management plans at least annually, with the nine largest filing them and quarterly public data on RPKI progress. Treat it as a proposal unless you have confirmed a final rule. NIST SP 800-189 (December 2019) remains the US technical baseline for RPKI, origin validation, filtering and source address validation.

Choosing your approach: enterprise, multihomed or provider

Small networks gain most from ROAs and a strict outbound filter. Large providers carry the bigger duty, because one missing customer filter turns a customer's error into a global outage; their effort goes into generating filters automatically from IRR and RPKI data.

Rolling out ROAs and ROV

1. Inventory: every prefix you hold, which AS announces it today (including DDoS and CDN providers) and which are unused; compare with what RIPE NCC's RIS sees.
2. Secure the RIR account: named users, phishing-resistant MFA, a short list of who may change ROAs.
3. Create ROAs: minimal ROAs per legitimate origin AS, AS0 for dormant space; confirm with a validator that all current routes show Valid.
4. Deploy validators: at least two relying-party instances on different software and hosts, feeding routers over RTR, with alerts on stale data.
5. Observe first: tag and log Invalids without dropping for two to four weeks, and chase any that are your customers' stale ROAs.
6. Drop Invalids: on peers and transits first, then customers after notice. Keep NotFound accepted.
7. Add path protections: RFC 9234 roles, AS path filters, max-prefix review, ASPA objects as support arrives.
8. Roll back safely: keep a pre-built policy that depreferences Invalids instead of dropping them, for validator or repository failures. RFC 6811 warns that rejecting invalids can be a denial-of-service vector if validation data is tampered with.

BGP monitoring and hijack response

You cannot see a hijack from inside your own network, because your routers still prefer your own routes. BGP monitoring needs an outside view: public route collectors (RIPE NCC RIS, RouteViews), looking glasses and a monitoring service feeding your SOC (see the SIEM Guide). Alert on any unauthorised origin AS, any more-specific of your prefixes, a new AS adjacent to yours, your prefixes going RPKI-Invalid, ROA or ASPA changes in your RIR account, session flaps and max-prefix shutdowns, and prefix-list or route-map changes outside change control.

Hijack response playbook

1. Confirm from at least two external vantage points; record origin, prefixes, first-seen time and upstream path.
2. Rule out your own side: a recent ROA change, new provider or leaked internal route.
3. Contact the offending AS's upstream through its NOC and PeeringDB or IRR contacts and ask for a filter; escalate through your transits.
4. If the hijacked prefix is shorter than /24, announce more-specifics to compete, as YouTube did in 2008.
5. Assume interception: check Certificate Transparency for unexpected certificates on your domains and rotate credentials that crossed the network in clear. See the Incident Response Guide.

Metrics: share of announced prefixes covered by a Valid ROA (target 100%); share of external sessions dropping Invalids; customer sessions with IRR or RPKI filters and max-prefix set; mean time to detect an origin or more-specific anomaly; mean time to mitigate a confirmed hijack; and stale or non-minimal ROAs found per quarterly review.

Where identity fits

Routing security rests on a few very powerful credentials. The RIR portal account can make your prefixes Invalid everywhere. Router admin accounts, automation service accounts that push filters, monitoring API tokens and TCP-AO or MD5 session keys are privileged or non-human identities: put human access behind phishing-resistant MFA and PAM, give automation scoped service accounts, and keep session keys in a secrets manager. Network device credentials are a favoured target: the Salt Typhoon telecom intrusions show how stolen credentials and network device secrets kept attackers inside carrier networks for years. See the Privileged Access Management Guide and the Service Account Security Guide.

Framework mapping

Common failure patterns

• ROAs never maintained: a prefix moves to a new provider or a DDoS service, the old ROA makes the new route Invalid, and validating networks drop your own traffic.
• Loose maxLength: one /16-24 ROA authorises 256 /24s you never announce, exactly what a forged-origin hijack needs.
• Validation without dropping: routers tag Invalids but policy still accepts them, so dashboards look green and nothing is protected.
• No customer filters at the provider: the root cause of the 2008 YouTube hijack and most large route leaks.
• Single validator: one relying-party instance fails or goes stale, and protection disappears silently.
• Shared RIR and router logins: one phished password rewrites ROAs or announcements with valid access, and no log ties the change to a person.

Practitioner checklist

• Publish minimal ROAs for every announced prefix and origin AS, and AS0 ROAs for unused space.
• Protect the RIR account with phishing-resistant MFA and alert on ROA changes.
• Run two or more RPKI validators and alert on stale data.
• Drop RPKI-Invalid routes on external sessions after a log-only period, with a rollback policy ready.
• Filter every customer session with IRR and RPKI prefix lists, max-prefix and AS path checks.
• Enable RFC 9234 roles and publish ASPA objects as support arrives.
• Restrict TCP 179 to neighbours, use GTSM, and keep TCP-AO or MD5 keys in a secrets manager.
• Apply BCP 38 on customer edges and meet all four MANRS actions.
• Monitor prefixes from external collectors and test a hijack playbook.
• Require ROV and customer filtering in transit and hosting contracts.

Standards and references

• IETF: RFC 6811 BGP Prefix Origin Validation
• IETF: RFC 6480 An Infrastructure to Support Secure Internet Routing
• IETF: RFC 9319 The Use of maxLength in the RPKI
• IETF: RFC 7454 BGP Operations and Security
• IETF: RFC 9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
• IETF: BGP AS_PATH Verification Based on ASPA Objects (Internet-Draft)
• NIST: SP 800-189 Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation
• MANRS: Actions for Network Operators

Related NHI Mgmt Group resources: DNS Security Guide · DDoS Protection Guide · Edge Device Security Guide · Top 10 Network Security Misconfigurations · Privileged Access Management Guide