Network Fundamental Out to the wider world

BGP — the internet works because everyone believes the neighbours

The routing article ended saying nothing proves the neighbour is telling the truth. This one shows that BGP's own standards documents say exactly that

2026-09-14 · Part 8 · Out to the wider world · 9 min read

The routing article ended on a sentence it left hanging.

"That somebody knows because someone else told them, and nothing proves the one who told them is telling the truth."

This article checks whether that was overstated. It was not, and the IETF's own documents are what say so.

If you have never looked, start here

The internet's routing data is public. RIPE records what real routers around the world can see, and opens it over an API.

$ curl "https://stat.ripe.net/data/routing-status/\
data.json?resource=8.8.8.0/24"

It answers with who originates that route, and how many observers see it.

BGP's unit is not a router; it is an organisation

RFC 4271 defines itself in one sentence.

"The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol."

Inside one organisation many routers talk among themselves, while BGP runs between organisations and sees each of them as a single point

An Autonomous System is an organisation that decides its own routing. One provider is one AS; a large university can be one; each has its own number.

How many routers sit inside is its own business, and BGP does not care. It sees only which organisation connects to which — which is why it scales to the whole world, because there are vastly fewer organisations than routers.

And its job is

"The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems."

Loop prevention by writing down everyone who touched it

The STP article solves loops by switching a port off. The IP article prevents them with a TTL that falls at every hop. BGP uses a third way, unlike either.

Each organisation the route passes through appends its own number to a list, and a route arriving with your own number already in the list is one that has come back round, so it is discarded

Every time a route crosses an AS, that AS appends its own number to a list travelling with the route. RFC 4271 describes the check.

"AS loop detection is done by scanning the full AS path (as specified in the AS_PATH attribute), and checking that the autonomous system number of the local system does not appear in the AS path."

Seeing your own number in the list means the route has come back round to you, so you discard it.

A benefit falls out that nobody had to design: the list also says who the route came through, which a TTL can never tell you.

Measured against the real thing, at 375 points

I pulled what RIPE's observers could see for 8.8.8.0/24 on 2 September 2026.

  AS_PATH length   observers
       2 AS              279
       3 AS               82
       4 AS               12
       5 AS                2
                         ---
                         375

The shortest and the longest paths collected

  328977 15169
  328840 327727 174 6453 15169

Look at the last entry in each. It is the same number, and across all 375

  observers            375
  path lengths           4
  origin AS numbers      1

Not everyone reaches it by the same road, but everyone agrees on who it comes from. That is what BGP achieves — and the very thing it has no mechanism to verify.

Chosen by policy, not by distance

This is where people arriving from OSPF or RIP go most wrong.

RFC 4271 says the information BGP exchanges is enough for

"constructing a graph of AS connectivity, from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced."

The word "policy" is in the defining sentence. "Fastest" and "nearest" are not.

A path through 2 ASes can be discarded in favour of one through 4, if the first costs money and the second does not. That is not a malfunction; it is what the protocol was built to allow.

RFC 4271's security section protects the pipe, not the claims

I read the whole Security Considerations section of RFC 4271, about four thousand characters, and it discusses one thing: the MD5 key that protects the TCP connection between two routers that are talking.

  word in that section   count
  authorization              0
  hijack                     0
  entitled                   0

Not one word about whether an announced route belongs to whoever announced it. And the section closes with a single sentence pointing elsewhere.

"BGP vulnerabilities analysis is discussed in [RFC4272]."

RFC 4272 says what RFC 4271 does not

That document states it in three sentences.

"BGP has no internal mechanism that provides strong protection of the integrity, freshness, and peer entity authenticity of the messages in peer-peer BGP communications."

"no mechanism has been specified within BGP to validate the authority of an AS to announce NLRI information."

"no mechanism has been specified within BGP to ensure the authenticity of the path attributes announced by an AS."

The second means nothing checks that you are entitled to announce those addresses. The third means nothing checks that the route you claim to have come by is real.

That is the sentence the routing article left hanging, written by the IETF.

Why hijacking a route works

The routing article established the rule: the longer prefix always wins, no exceptions. That rule is the opening.

The genuine holder announces a /24 while the hijacker announces a longer /25, so longest-prefix match picks the forgery with nothing behaving abnormally

  announcement   addresses   result against /24
  /24 genuine          256   genuine wins
  /25 forged           128   forged wins
  /26 forged            64   forged wins

The hijacker breaks into nothing. They announce a longer prefix, and every router that hears it picks the forgery, by following the rule correctly.

How many options a hijacker has against a single /24

  /25    2
  /32  256

RPKI closes half of that

RFC 6811 adds a check on whether the AS claiming to originate a prefix is authorised by the prefix holder. It yields three states.

The three origin-validation states, with a dashed line marking the rest of the path, which still has nothing checking it

"NotFound: No VRP Covers the Route Prefix."

"Valid: At least one VRP Matches the Route Prefix."

"Invalid: At least one VRP Covers the Route Prefix, but no VRP Matches"

I checked the real thing for 8.8.8.0/24 and AS15169.

  status       valid
  ROA prefix   8.8.8.0/24
  ROA origin   15169
  maxLength    24

That maxLength of 24 is what closes the opening above, because a /25 announcement of this prefix is judged Invalid immediately, even if whoever announced it put 15169 in the origin themselves.

But only half of it, genuinely

RFC 6811 states its own limits more plainly than most documents do.

"does not protect against 'AS-in-the-middle attacks' or provide any path validation."

"Note that the complete path attestation against the AS_PATH attribute of a route is outside the scope of this document."

It checks who the origin is. It does not check that the path claimed is real — which is exactly RFC 4272's third sentence, and that one is still unanswered.

When it lies

"BGP picks the shortest path." The defining sentence says policy, not short. A longer path may be chosen because it is cheaper.

"Fewer ASes means faster." A count of ASes is not a distance. One AS can span a continent.

"With RPKI we are safe." RFC 6811 says itself that it does no path validation, only origin.

"A hijack is a break-in." It is not. It is announcing something false and letting everyone follow the rules, which a configuration mistake produces as readily as an intention.

"We can check our routes are correct ourselves." From an endpoint you see only the route that won. You do not see the ones discarded, or why.

Real cases from real work

Case 1 — check your addresses are announced from where they should be

Situation You want to know who is announcing your organisation's addresses.

Command

$ curl "https://stat.ripe.net/data/routing-status/\
data.json?resource=<prefix>"

How to read it Look at origins. An AS number that is neither yours nor a provider you delegated to is a signal to follow up. Then look at ris_peers_seeing: if unusually few observers see it, the route is not propagating everywhere.

What this does not prove RIPE's observers are one set of viewpoints, not all of them. Their seeing nothing wrong does not mean nowhere sees anything.

Case 2 — traffic leaves by the expensive link with nobody asking it to

Situation Two providers, and traffic piles onto the one that charges more.

How to read it Check three things in order.

  1  local preference   your own setting; comes before everything
  2  AS_PATH length     shorter wins, if 1 is equal
  3  prefix length      longer wins, before either of the above

The third always comes first, because route selection happens per prefix, not per destination. If the other side announces a more specific prefix, what you set in step one has no effect at all.

What this does not prove The tie-breakers after these three differ between vendors and are not all fixed by the standard. Check the manual for the equipment actually in use.

Case 3 — decide whether to publish a ROA

Situation You hold your own addresses and must decide whether RPKI is worth the effort.

How to read it Two questions.

  1  what is the longest prefix you will genuinely announce
  2  if somebody announces one longer, what do you want to happen

The first is the maxLength to set, and setting it wider than you need reopens precisely the gap the ROA exists to close.

What this does not prove A ROA only matters where the receiving network chooses to act on it. Having a correct one does not mean every router on earth will reject the forgery for you.

Where the whole series has been heading

ARP believes the answer about who holds an address. DHCP believes whichever machine answers first. STP believes the values the neighbours announce. And BGP believes that the routes it receives are true.

All four work by believing, and all four are fooled the same way: speak loudly, and speak first.

What differs is the blast radius. ARP is fooled within one network. BGP is fooled across the internet.

And the answer people have found so far is not to stop believing, but to make the lie detectable afterwards — which RPKI does for half of it, with the other half still open.

References

Standards

RFC 4271, January 2006, A Border Gateway Protocol 4 — the defining sentence, AS_PATH loop detection, and the Security Considerations section that discusses only TCP keys
RFC 4272, January 2006, BGP Security Vulnerabilities Analysis — the three sentences quoted here
RFC 6811, January 2013, BGP Prefix Origin Validation — the three states, and the limits the document sets on itself

Measured from public data

RIPEstat API for 8.8.8.0/24 on 2 September 2026 — origin AS15169, seen by 99 of 99 observers, 375 paths from vantage points worldwide, and an RPKI result of valid with the ROA setting maxLength to 24
This data comes from real routers that RIPE collects from, not from the machine this was written on

Computed here

The tables of addresses per prefix, and of how many smaller prefixes one can be cut into, are computed directly from the prefix length

Trust Measured on a real machine Computed here

อ่านหน้านี้เป็นภาษาไทย