Hi Nick,
As we wrote in the mail and the write-up (§7): mitigation is quick and
fairly easy (to the point where damage is limited to the human response
time/time-to-action).
Our notification aimed at (i) cutting down the the time-to-action by
re-raising awareness for the problem and (ii) providing operators
(especially of smaller networks) with prevention mechanisms to lower the
impact on their networks until transit providers and IXPs acted.
Best regards,
Lars
On 20.10.22 23:15, Nick Hilliard wrote:
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
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/routing-wg
