A paper circulating on NANOG and SANOG mailing lists discusses the risks inherent in the de-aggregation of prefixes announced into the global BGP system, at scale. Titled “Kirin: Hitting the Internet with Millions of Distributed IPv6 Announcements”, the paper by Lars Prehn, Pawel Foremski, and Oliver Gasser discusses how the vast address space of IPv6 presents a ‘new’ attack surface on the Internet’s routing infrastructure.
What’s in the paper?
The paper describes a problem that really does exist. If an ISP has a large delegation of IPv6 like a /32 (which is the typical delegation for an ISP), it’s possible to deaggregate the /32 and announce it as quite a large number of more specific routes. It’s normal and common to deaggregate, within reason.
Usually, the intent is to construct routing information that gives traffic engineering or policy outcomes to ‘direct’ IPv6 traffic down specific links, or to specific places. After all, while the ISP has ‘all’ the space in BGP, it also probably has complex relationships with peers and an Internet Exchange Point (IXP) and wants to manage things in more detail than just ‘all of it’, sometimes.
This is normal — but the normal engineering outcomes here reflect the normal engineering investments. An ISP might have ten or 100 Points of Presence (PoPs) and may have ten or 100 sub-contexts of routing being announced, but not millions, or tens of millions, or billions. So, the global BGP system might expect this size of delegation to have at least some potential to announce millions and billions of more specific routes, up to the /64 boundary and beyond (if another entity will accept and forward them).
IPv6 is big, really big
Even when limited to a /48, there are 65,000 more specifics that can be potentially announced in a /32. And deaggregated to a /64, the address space in a /32 has the equivalent of the whole of the IPv4 address space in routes — there are 4B prefixes lurking in there.
The paper discusses the theoretical consequences of an entity announcing millions and billions of more specific routes, what it might look like if done in a distributed manner from more than one location into the global BGP space, and the consequences of having these routes withdrawn.
A secondary effect in BGP is the ‘update to withdraw’ sequence. This happens when a BGP speaker is told one specific path no longer works and attempts to ‘hunt to the end’ all the other alternatives. The BGP speaker would then receive the subsequent updates one by one as those alternatives confirm that they too cannot see the route.
This is not exactly a ‘combinatorial explosion’ effect, but it is a magnifier — the kind of magnifier that brings all BGP speakers that learned the routes to the table. That is, the BGP speakers who learned the routes will announce their learning of not having the route. It takes a while for this to settle down and makes a huge spike in BGP traffic.
Does it work? In theory, yes.
The authors of the paper suggest the ‘attack’ is possible and would have effects at scale.
But here’s the thing — it’s not new. This is old news in many ways. This email from Nick Hilliard to the RIPE routing-wg makes it clear. Not only have operators known about this since the start of the IPv6 BGP story, but they know the mitigations. They’re actually pretty simple. In short, do your job.
Do your job: NOCs
So, the ‘in theory’ part above is important because if a Network Operations Centre (NOC) of an ISP is doing its job and monitoring BGP behaviour, this kind of attack is going to be detected at launch and nipped in the bud. It won’t simply run rampant across the entire BGP surface. It could potentially have bad effects — even devastating for some ISPs — but in practice, it will be seen and stopped by the BGP speakers who are keeping an eye on BGP change, the volume of change, and rate of change.
The paper authors point out that if some reasonably clear logic is used to filter what the BGP speakers see and set limits on how ‘big’ the BGP tables are expected to be, the ISP can limit its exposure. The downsides of this approach are that proscriptive BGP filter limits tend to become reduced into ‘golden rules’ that have unintended consequences, and the scale limits of setting table size can rebound in other ways if badly implemented (first-hand experience — I’ve personally caused this by misconfiguring BGP at a much earlier time, and for a smaller table).
The moral of the story is not to walk away from IPv6 or even BGP traffic engineering and policy. Instead, it’s essential to consider your NOC and the 24/7 nature of the network. Be prepared, be alert, but also don’t panic.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.