BGP Policy and Security - Steering, Hijacks, Leaks and RPKI
- BGP picks routes by policy first. LOCAL_PREF (and a vendor-local weight) sit above AS-PATH length, so the longer path can and often does win. LOCAL_PREF steers outbound traffic. Inbound traffic is only influenced, with prepending, MED, communities and more-specific prefixes.
- The export rule follows the money: routes from customers go to everyone, routes from peers and providers go only to customers. A path that breaks it is not valley-free.
- A hijack is an origin problem (an AS announces a prefix it does not own, often a more specific one). A leak (RFC 7908) is a path problem (a valid route is passed on where policy forbids it). A withdrawal outage is neither.
- RPKI origin validation (RFC 6480, RFC 6811) marks each route Valid, Invalid or NotFound by comparing it with signed ROAs. It checks the origin and the length, not the path, and only helps where a neighbour actually drops the Invalid routes.
- Path protection is still mostly future work: BGPsec (RFC 8205) is barely deployed, ASPA is an in-progress IETF draft, and day to day defence is filters, max-prefix limits, IRR data and MANRS practice.
Mental model
Think of airline alliances. Each carrier decides which partners' flights it will sell, and to whom, according to contracts, not distance: it happily sells a long itinerary through a partner who pays it, and refuses to sell a free connection through itself for two other airlines. Nobody checks a seat map. If a small airline announces "we fly to the capital, cheap," booking systems believe it until someone complains.
Where it breaks: airlines are checked by regulators and ticket inspectors. BGP has no inspector built in: nothing in the protocol proves that the announcer owns the destination or that the route was passed along legitimately.
A BGP speaker is a policy engine for routes, much like a firewall rule set or a service-mesh routing config. Each rule matches on prefix, AS-PATH or community and applies an action: accept, drop, set LOCAL_PREF, prepend, tag. The decision process then ranks whatever the rules let through. The protocol is the transport, the policy is the program.
Where it breaks: a firewall sees traffic it can verify at the packet. A route filter acts on a claim made by a neighbour, so the policy is only as good as the data it is built from (customer cones, IRR objects, signed ROAs) and every unfiltered session is a place a wrong claim can enter.
How it works
Policy sits on top of the decision process
BGP basics gives the order in RFC 4271 section 9.1. This page is about the steps an operator can write to. Vendors add two steps above the RFC order, so the ranked list that engineers use looks like this:
| Step | Attribute | Prefer | Scope |
|---|---|---|---|
| 1 | Weight (vendor feature) | Highest | Local to one router, never sent to anyone |
| 2 | LOCAL_PREF | Highest | Carried across iBGP, never sent over eBGP; the main outbound lever |
| 3 | Locally originated (vendor step) | Routes this router created | Local |
| 4 | AS-PATH length | Shortest | Visible to everyone downstream; the inbound lever, with prepending |
| 5 | ORIGIN | IGP, then EGP, then incomplete | Rarely used as policy |
| 6 | MED | Lowest | Compared only between routes from the same neighbouring AS (default); a polite hint from the neighbour |
| 7 | eBGP over iBGP | eBGP | Prefer leaving the AS |
| 8 | IGP metric to NEXT_HOP | Lowest | Hot-potato: exit the AS by the cheapest internal path |
| 9 | Tie-breakers | Router ID, then peer address (vendors add oldest-route and others) | Last resort |
Weight and the locally-originated step are not in RFC 4271, and their exact position is a platform detail (Cisco's best path page, FRR's BGP documentation). The RFC 4271 section 9.1.2.2 rules can also be changed by features such as multipath, so read your platform's documentation before relying on a tie-break.
Worked example: the longer path wins
AS64496 hears the same prefix, 198.51.100.0/24 (from the RFC 5737 documentation range), whose origin is AS64500, from two neighbours. The AS numbers are the RFC 5398 documentation range.
| Attribute | Route A, from a customer, AS64497 | Route B, from a provider, AS64501 |
|---|---|---|
| AS-PATH | 64497 64498 64499 64500 (length 4) | 64501 64500 (length 2) |
| LOCAL_PREF | 200 (set by import policy for customers) | 100 (the default) |
| Decision | Wins at step 2, before AS-PATH is ever compared | Loses despite the shorter path |
The operator chose LOCAL_PREF 200 for customer routes because a customer pays to be reached through you, while a provider route costs you money. Distance never entered the decision. AS-PATH length only decides among routes that tie on everything above it.
The export rule
Selection chooses what a router uses. The export rule decides what it tells others. It is the same economics seen from the other side: you announce a route to a neighbour only if doing so earns or saves you money. The rule is explained, with the paths it produces, on autonomous systems. Here is the full rule as an allow matrix, the half that people forget is the first row.
| Learned from \ Export to | Customer | Peer | Provider |
|---|---|---|---|
| Own prefixes | Yes | Yes | Yes |
| Customer | Yes | Yes | Yes |
| Peer | Yes | No | No |
| Provider | Yes | No | No |
A route learned from a customer is revenue, so it goes everywhere. A route learned from a peer or provider is something you are not paid for, so it goes only to customers who pay you. Passing a provider's route to another provider or to a peer means carrying traffic between two networks for free. That "No" cell is exactly what a route leak violates.
Two failures, two pictures
First, an origin failure. The owner AS64496 announces 192.0.2.0/24 and has a signed ROA with maximum length 24. The attacker AS64499 announces the more specific 192.0.2.0/25. A network that does not validate accepts it, and longest-prefix match (forwarding) then sends the traffic for those 128 addresses to the attacker. A network that does validate sees an Invalid route and drops it. (The AS numbers and prefix are documentation values, as in network attacks.)
Second, a path failure. AS64503 originates 198.51.100.0/24 and is a customer of provider P1. P1 passes the route to its customer C, which is allowed (provider to customer). C is also a customer of a second provider, P2, and re-announces what it learned from P1 to P2. That is the forbidden cell in the matrix. The origin is correct, so origin validation says Valid. P2 now has a customer route through C, ranks it above its other routes by LOCAL_PREF, and pushes traffic through a small network that was never meant to carry it.
A hijack and a leak therefore need different fixes: origin validation for the first, path and relationship checks for the second. The formal leak taxonomy is in RFC 7908 (it lists six types; this one is Type 1, a "hairpin turn with full prefix", and it also covers the accidental leak of internal more-specifics).
Try both failures, and the policy behind them, on one graph. Step the announcement through the seven documentation ASes, open an AS to see its RIB and the decision that picked its route, then switch scenario: edit LOCAL_PREF and relationships under Policy, run a same-length or more-specific hijack under Hijack with ROV switched on at some ASes or all of them, or leak a provider route under Leak with and without RFC 9234 OTC or a customer filter.
× unreachable: no route. AS64502 to 192.0.2.10 (not converged yet).
RIB of AS64499 (10.0.0.4)
No route to 192.0.2.0/24 in this table yet.
Deep dive
Steering outbound is easy, inbound is a negotiation
Outbound traffic follows your best path, and your best path is whatever your policy ranks first. Set LOCAL_PREF on import and you are done. Inbound traffic follows other people's best paths, and you can only change what you advertise to them:
- AS-PATH prepending repeats your ASN in outbound announcements on one link, so the path looks longer there. It matters only to ASes that reach the AS-PATH step without an earlier policy decision. A neighbour that sets LOCAL_PREF higher for a customer link ignores your prepending entirely.
- MED (RFC 4271) is a hint from you to one neighbouring AS about which of several links it should use to reach you. By default it is compared only between routes from the same neighbouring AS, and it is below AS-PATH in the order.
- Communities (RFC 1997, large communities in RFC 8092) are tags. Providers publish what theirs do: "set LOCAL_PREF to 80 inside your network," "prepend twice toward AS X," "do not announce to peers." This is the most precise inbound tool because it is the provider's own LOCAL_PREF doing the work. The well-known
NO_EXPORTcommunity tells a neighbour not to pass the route outside its AS. - More-specific prefixes split your block, announcing one half on one link and one half on another. Each more specific is a separate prefix in the BGP table, not a competitor of the less specific one: best-path selection runs per prefix, and forwarding then uses longest-prefix match to choose between the entries (forwarding). There is a limit. Operators commonly filter announcements longer than a
/24for IPv4 and/48for IPv6 (RFC 7454 discusses prefix-length filtering), so splitting past that point does not propagate.
Why is inbound hard? Because you do not run the routers that decide. Every AS that can reach you chooses by its own policy, and some of them will never compare AS-PATH lengths at all.
Hot potato and cold potato
With two equal-preference exits, steps 7 and 8 above decide: hot potato hands traffic to the nearest exit by internal metric, which is cheapest for you. Cold potato carries it across your own network to the exit nearest the destination, which costs you capacity and gives you control of quality. Content networks often do cold potato because they own the long haul. The mechanics are in autonomous systems. The security point is only that the two directions of a conversation may take different paths, so a defence has to work per direction.
Prefix hygiene: the filters that stop most mistakes
The first line of defence is dull and effective: filter what a neighbour is allowed to announce.
- Prefix lists on customer sessions accept only the customer's own prefixes (and their customers'), usually generated from IRR data. Everything else is dropped. A hijack or leak from a customer then stops at the first hop, which is exactly where the 2008 incident was not stopped.
- AS-PATH filters accept only paths that start with the customer's ASN (or an allowed customer-cone as-set).
- Max-prefix limits shut down or warn on a session when a neighbour sends far more prefixes than expected. They are a seatbelt for a flood of de-aggregated routes, not a security control.
- Bogon and default filters reject private, documentation and reserved space, and too-specific routes.
- RFC 8212 (default behaviour without policies) says an eBGP session should accept and send nothing until policy is configured. Several implementations follow it, which is why a new FRR eBGP session shows no routes until a route-map is attached.
RFC 7454 (BCP 194) is the operational reference for all of this.
IRR and RPSL: unsigned data
The Internet Routing Registries (RADB and the RIR-run databases) hold route and aut-num objects in RPSL (RFC 2622) saying who may originate what, plus as-set objects for a network's customer cone. Operators generate prefix lists from them. They are also not cryptographically signed, anyone can create objects in some registries, and old objects are never cleaned up, so IRR filtering reduces mistakes more than it stops attackers (Cloudflare's write-up of the 2018 hijack makes this point about unsigned IRR data).
RPKI: signed origin
The Resource Public Key Infrastructure (RFC 6480) hangs certificates off the address registry hierarchy: IANA to the five RIRs (trust anchors) to the holders of address space. A holder signs a ROA (Route Origin Authorization, RFC 6482) with three facts: a prefix, a maximum length, and the origin ASN allowed to announce it. Validators fetch and verify everything, reduce it to a list of validated ROA payloads, and feed that list to routers over the RPKI-to-Router protocol (RFC 8210). The router then labels each route using RFC 6811:
| State | Condition (RFC 6811) | Example with a ROA for 192.0.2.0/24, max 24, AS64496 |
|---|---|---|
| Valid | At least one covering ROA matches both the origin ASN and the length limit | 192.0.2.0/24 from AS64496 |
| Invalid | Covered by at least one ROA, but none matches: wrong origin ASN, or longer than the maximum length | 192.0.2.0/24 from AS64499 (wrong origin), or 192.0.2.0/25 from AS64496 (too long) |
| NotFound | No ROA covers the prefix at all | 198.51.100.0/24 from anyone |
The policy decision is yours: most operators drop Invalid, accept Valid and NotFound, and may prefer Valid over NotFound. NotFound cannot be dropped, because most of the internet's space did not have ROAs for most of RPKI's life and many holders still have none.
The maximum length trap. A ROA with a loose maximum length, such as 192.0.2.0/24 with max length 28, authorizes the origin AS to announce any of the more-specifics up to /28. An attacker who forges the origin AS (prepending the owner's ASN to the path) can then announce a /28 that validates. RFC 9319 (BCP 185) recommends minimal ROAs: set the maximum length equal to the prefix length, and publish a separate ROA for each more-specific you really announce.
Limits. ROV checks only the origin. It does not see the rest of the AS-PATH, so it cannot catch a leak with a genuine origin, or a hijacker who puts the genuine origin at the end of a forged path. It protects you only where networks enforce it: an Invalid route that nobody upstream drops still propagates. And a route with no ROA is NotFound, not suspicious.
Path validation: BGPsec and ASPA
BGPsec (RFC 8205) signs the path: each AS signs the update to the next AS it hands it to, so a receiver can check the whole chain. It is barely deployed. The commonly cited reasons are structural: it only pays off when every AS on the path signs, so a partial deployment gives little protection; each update must be signed and validated per hop, which costs routers CPU and memory; and signed updates cannot be packed together the way ordinary UPDATEs are. Operators have preferred to deploy origin validation first.
ASPA (Autonomous System Provider Authorization) takes a lighter route. An AS publishes a signed list of the providers it uses; a validator checks whether every hop in an AS-PATH is consistent with the customer-provider relationships those records declare, which catches many leaks and forged paths without per-hop signatures. As of 2026-10-14 it is still an Active Internet-Draft in the IETF SIDROPS working group (verification draft, profile draft), so treat details as subject to change.
RFC 9234 roles and OTC. RFC 9234 lets two ends of a BGP session declare their relationship (Provider, Customer, Route Server, Route Server Client, Peer) in the OPEN message and checks that the declarations match. A route received from a customer or peer gets an Only to Customer (OTC) attribute so that it is never passed to a provider or peer. This is the export matrix built into the protocol, and it needs no PKI, only both sides implementing it.
Incident timeline
Each incident links its primary source. The classification is the point: three different failures.
| Date | Event | Type | Cause | Impact | Source |
|---|---|---|---|---|---|
| 2008-02-24 | Pakistan Telecom (AS17557) announces 208.65.153.0/24, inside YouTube's 208.65.152.0/22; PCCW Global (AS3491) propagates it | Hijack (more specific) | Domestic block implemented by announcing the prefix, not filtered by the upstream | YouTube traffic redirected from 18:47 UTC; the bogus routes were withdrawn at 21:01 UTC | RIPE NCC case study |
| 2018-04-24 | eNet (AS10297) announces more-specifics of Amazon address space used by Route 53 | Hijack (more specific) | Unauthorized origin accepted by a peer that then forwarded it | Amazon DNS answers redirected for the affected resolvers, about 11:05 to 12:55 UTC | Cloudflare |
| 2019-06-24 | DQE (AS33154) leaks its optimizer's more-specifics to customer Allegheny (AS396531), which passes them to Verizon (AS701) | Leak | A BGP optimizer created many more-specific routes and a customer re-announced them to a second provider with no filter | Large parts of the internet, including Cloudflare, Amazon and Linode, affected as traffic funnelled to small networks | Cloudflare postmortem |
| 2021-10-04 | Facebook's DNS servers withdraw their BGP announcements | Withdrawal | A maintenance command disconnected the backbone; the DNS servers withdrew themselves because they could not reach the data centres | Facebook names stopped resolving | Meta engineering, Cloudflare |
The 2008 and 2018 events are retold in network attacks with their security consequences. The 2019 event is a leak in the RFC 7908 sense: the origin was fine, the paths broke the export rule, and it would not have been caught by ROV on its own. Cloudflare's postmortem lists IRR filtering, RPKI, and the MANRS actions as the defences. The 2021 outage was self-inflicted and is not a security event at all.
MANRS
MANRS (Mutually Agreed Norms for Routing Security) is an industry programme that asks network operators to commit to four actions: filtering (prevent propagation of incorrect routes), anti-spoofing (block traffic with spoofed source addresses), coordination (keep contact information in registries current), and global validation (publish routing information in the IRR or RPKI so others can validate). Its value is that it turns the filters above into a checklist a customer can ask a provider about. See manrs.org for the current actions and participants.
Textbook vs real world
| The textbook says | Production does | Why |
|---|---|---|
| The shortest AS path wins | LOCAL_PREF and policy decide first; AS-PATH length breaks ties | A customer pays you and a provider costs you, so the route choice follows the contract, not the hop count |
| BGP finds the best route | BGP finds the route your policy ranks highest, which is often the cheapest or most profitable | Each AS optimizes for itself with no shared metric |
| RPKI solves hijacks | ROV stops wrong-origin and too-long announcements where a network drops Invalid routes | It does not validate the path, ROAs can be too loose, and enforcement is partial |
| Valley-free routing is a rule | It is a convention that is violated by accident, regularly | Nothing in classic BGP enforces it, so a missing filter or a mistaken redistribution is a leak (RFC 9234 and ASPA aim to enforce it) |
| A filter on the customer session is optional hygiene | It is the most effective single control | It stops a bad announcement at the first hop, before anyone else can see it |
In production
- Cloudflare runs a public scorecard, Is BGP safe yet?, that tests whether a network drops RPKI-invalid routes and lists large transit and access networks by whether they sign their own routes and filter their customers' routes. The list changes as networks deploy, so read the page rather than a figure from a blog post. Cloudflare's own RPKI deployment is described in its RPKI article.
- Adoption is measured by several public dashboards: the NIST RPKI monitor, APNIC's RPKI statistics, and RIPEstat show the share of prefixes with ROAs and the share of validating networks. These numbers move every month, so none is reproduced here.
- Transit providers filter customers with IRR-derived prefix lists and, increasingly, with RPKI, which is what the "signed + filtering" entries on the Cloudflare scorecard record.
- Remote-triggered blackholing uses the well-known BLACKHOLE community (RFC 7999,
65535:666): a customer under DDoS tags a /32 and the provider drops traffic to it at the edge. - CDN anycast (global traffic steering, CDN) is the same prefix announced from many sites, so a CDN's routing security is also its availability: a hijack of an anycast prefix is a global outage, which is why CDNs sign and validate.
History and evolution
- 1989 BGP-1 (RFC 1105) connects networks on trust: any neighbour's announcement is believed. That is fine with a handful of academic and government networks.
- 1996 Communities (RFC 1997) let ASes tag routes so neighbours can apply policy without per-neighbour configuration.
- 2008 The Pakistan Telecom and YouTube incident shows a single unfiltered customer session can pull a major site offline worldwide (RIPE NCC). Registry data had no signatures, so there was no origin check to deploy.
- 2012 The RPKI architecture (RFC 6480) ties signed ROAs to the address registry hierarchy. 2013 - RFC 6811 defines how a router uses them.
- 2016 RFC 7908 gives the route-leak problem a precise definition, which separates leaks from hijacks.
- 2017 BGPsec (RFC 8205) is published for path validation, and sees almost no deployment.
- 2018 The MyEtherWallet and Route 53 hijack shows that unsigned IRR data does not stop an unauthorized origin, and Cloudflare publishes its RPKI deployment the same year (hijack analysis, RPKI article).
- 2019 The Verizon, DQE and Allegheny leak shows that origin validation alone cannot stop a leak (Cloudflare postmortem).
- 2022 RFC 9234 adds roles and the OTC attribute so leaks can be prevented by the protocol itself, and RFC 9319 tightens ROA maximum-length guidance.
- Now ROV is widely deployed by large networks and ROA coverage is a live number on the NIST and APNIC dashboards.
- Next ASPA completes path-level checking for leaks and forged paths, and RFC 9234 roles move from optional to expected.
Hands-on
Commands use FRR, a free routing daemon, in vtysh. Configuration is shown for illustration; the addresses are documentation ranges and the syntax follows recent FRR releases, so check show version and the FRR manual if a command is rejected.
Inbound policy on a customer session, with a prefix filter, LOCAL_PREF, and a max-prefix limit:
Anything the prefix-list does not permit falls through to the implicit deny of the route-map. To prepend toward a neighbour for inbound steering, an outbound route-map with set as-path prepend 64496 64496 does it. To attach a community, set community 64496:80 additive.
Origin validation, with a validator cache (Routinator or another RTR server) at 192.0.2.10 port 3323 (illustrative address):
To see which path won and why (illustrative output, abbreviated from the format FRR prints):
The first path is four ASes long and still best, and the reason in parentheses is Local Pref. In FRR, show rpki prefix 198.51.100.0/24 inspects the validation state of a prefix.
To check a real prefix, query RIPEstat's rpki-validation data call, which uses a Routinator validator. This output is real, queried on 2026-10-14 and abbreviated; the response will change if the ROA does:
Change the resource to a different ASN, for example AS64499, and the same ROA is reported as invalid_asn: the prefix is covered, but the origin does not match, which is the Invalid row of the validity table. Routinator offers a local equivalent, routinator validate --asn 13335 --prefix 1.1.1.0/24; see the Routinator documentation.
IRR lookups use the plain WHOIS protocol. This output is illustrative, with documentation values:
Look at the object's source: a route object in a registry that anyone can write to is weaker evidence than a signed ROA. RIPEstat also offers a BGPlay and routing-history view of any prefix.
Gotchas
Interview questions
Show answer
Per RFC 4271 the router prefers highest LOCAL_PREF, then shortest AS-PATH, lowest ORIGIN, lowest MED (same neighbouring AS), eBGP over iBGP, lowest IGP metric to the NEXT_HOP, then router ID. Vendors add steps above that, Cisco and FRR notably weight (local) and a locally-originated preference. Policy attributes sit above distance, so the shorter path does not always win.
Follow-ups:
- Where does AS-PATH rank? After LOCAL_PREF, so it only breaks ties among equally preferred routes.
- What is weight? A vendor-local attribute, higher than LOCAL_PREF, that is never advertised.
Show answer
Outbound: set LOCAL_PREF on the routes you import, because you control your own best-path choice. Inbound: you can only influence other ASes, with AS-PATH prepending, MED toward a single neighbour, provider-defined communities, and announcing more-specific prefixes on one link.
Follow-ups:
- Why is inbound hard? Other ASes decide using their own policy, and many look at LOCAL_PREF before AS-PATH.
- Which tool is most reliable? Provider communities, because they set the provider's own LOCAL_PREF.
Show answer
Routes learned from customers are exported to everyone. Routes learned from peers or providers are exported only to customers. Paths that follow it go up customer-to-provider links, cross at most one peer link, and go down. It follows the money: you advertise a route only if it earns you money or saves you money.
Follow-ups:
- Why would a customer not give free transit? Passing one provider's route to another provider carries traffic for nothing, which is a leak.
- Where is it defined? Gao and Rexford's work, described on autonomous systems.
Show answer
A hijack is an origin violation: an AS announces a prefix (or a more specific) it does not own. A leak is a path violation: a genuine route is propagated beyond its intended scope, as RFC 7908 defines. YouTube 2008 was a hijack, the Verizon 2019 incident was a leak, and the Facebook 2021 outage was neither: a withdrawal after a configuration change.
Follow-ups:
- How do you classify the three? Hijack, leak, withdrawal respectively.
- Which does RPKI ROV address? The origin case, not leaks or withdrawals.
Show answer
A prefix holder signs a ROA naming the prefix, maximum length and origin ASN. Validators feed these to routers, which classify each route Valid, Invalid or NotFound under RFC 6811 and typically drop Invalid. That blocks wrong-origin and too-long announcements. It does not validate the path, so it misses leaks and forged-origin paths, and it only protects networks that enforce it.
Follow-ups:
- What is the max-length trap? A loose maximum length lets a forged-origin more-specific validate, so use minimal ROAs (RFC 9319).
- What adds path checks? BGPsec (RFC 8205, barely deployed) and ASPA (an IETF draft).
Show answer
A maintenance command disconnected Facebook's backbone. Its DNS servers, which advertise their own prefixes via BGP, withdrew those announcements when they could not reach the data centres, so Facebook's names stopped resolving and internal tools that depended on the same network were hard to use. No attacker was involved and it was not a leak.
Follow-ups:
- How can a design avoid the dependency? Keep out-of-band access to routers and tooling independent of the network it manages, and separate failure domains for DNS and the control path.
- Where is the primary source? Meta engineering.
Show answer
Hot potato hands traffic to the nearest exit by internal metric, which spends the least of your capacity. Cold potato carries it across your own network to the exit nearest the destination, which costs more and gives you control of quality. The hot-potato behaviour is the IGP-metric step in the decision process, and it can make the two directions of a flow asymmetric.
Follow-ups:
- Which do CDNs use? Often cold potato, because they have their own backbone.
- Why asymmetry? Each direction is another AS's own exit choice.
Show answer
Forwarding uses longest-prefix match, so a more specific prefix attracts the traffic even when the owner's shorter prefix has a better path. They are separate entries, not competing routes. Mitigations are prefix filters on customers, ROAs with a maximum length equal to the announced length so a longer prefix is Invalid, and monitoring. De-aggregation by the owner is limited because many networks drop routes longer than a /24 (IPv4).
Follow-ups:
- Can the owner fight back by announcing more-specifics? Yes, as YouTube did in 2008, until the filter limit, which is why ROV matters.
- Does ROV stop it? Only where Invalid routes are dropped.
Fun facts
- During the 2008 YouTube event, the bogus route had spread to its widest extent in the RIPE RIS routing view within about two minutes of 18:47 UTC, and the last unauthorized announcement was received at 21:01:22 UTC (RIPE NCC).
- YouTube's response in 2008 was to announce two /25 prefixes of its own, so that longest-prefix match favoured the owner again.
- The
NO_EXPORTcommunity has been standardised since 1996 (RFC 1997). - The 2019 leak started with a BGP optimizer, a tool that splits routes into more-specifics for traffic engineering (Cloudflare).
Cheat sheet
- Wrong origin or too-long prefix - RPKI ROV, with minimal ROAs.
- Customer announcing what it should not - prefix and AS-PATH filters, max-prefix.
- Leak of a genuine route - RFC 9234 roles and OTC, ASPA (draft), filters.
- Accidental withdrawal - change management and out-of-band access, not routing security.