[routing-wg] Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks

Lars Prehn wrote on 20/10/2022 20:23:
> If you want to know more about the research that initiated this 
> notification (including our concluded private disclosure process), you 
> may find a write-up at:
> 
> https://arxiv.org/pdf/2210.10676.pdf

Lars,

thanks for sending your findings to routing-wg. The impact of 
deaggregation of ipv6 prefixes on router resources has been understood 
since well before ipv6 was standardised.

Your paper describes an attack which can either use a provider's 
customer cone or else use a selection of different transit providers to 
inject smaller numbers of prefixes from different injection points into 
either a providers routing table, or the ipv6 dfz.  Your argument is 
roughly equivalent to stating that if you send 20,000 cars from 
different starting points to a single destination, that you will end up 
with gridlock, as the taxi industry in Moscow discovered a couple of 
weeks ago - this isn't news for either cars or routing table prefixes. 
There are many other easily-staged attacks which are also efficient at 
causing disruption, e.g. sending 1tbit/s of data at a destination, 
gluing oneself to the road on a commuter trunk during rush hour, cutting 
fibre cables in chambers, etc. All of these are low cost, regularly 
tested, and are known to work well.

Your list of takeaways in section 6.1 is correct, but it stopped at the 
point of detection and mitigation.  Routing tables are monitored, and 
some people / organisations have alerts triggered, particularly transit 
providers.  Another is that routing operations people tend to notice 
things like routers and routing tables blowing up. In other words, you 
will cause damage if you try this in anger, but fairly quickly the 
source(s) will be noticed and you'll find that mitigation action will be 
taken. As quickly as providers might increase prefix limits on a bgp 
session, they will drop them too, or shut down the session entirely, or 
terminate your free ipv6 transit, or cut off your ixp peering.

This is important because one of the more important aspects of network 
reliability is not closing off all angles of potential attack / failure, 
but ensuring that detection and time-to-recovery are optimised.

The Vultr incident on October 5 this year was noticed fairly quickly on 
operator forums, both because of alerting on router FIB resource usage 
and control plane CPU usage.  Incidentally, production de-peering 
happened as a result of the incident, although hopefully that has been 
undone at this point.

Nick