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

[Lars Prehn]

Dear LACNOG,

Our apologies to those who received this message via multiple channels.

My colleagues and I recently revisited the topic of prefix 
de-aggregation attacks. We believe that the current IPv6 allocation 
policies combined with the ever-growing number of interconnection 
opportunities may facilitate those attacks to the point where they may 
circumvent traditional prevention mechanisms. Hence, we'd like to raise 
awareness on how to detect, mitigate, and prevent these kinds of attacks.


# Prefix De-aggregation Attacks

While allocation policies in IPv4 are very tight, even a new LIR can 
obtain, e.g., a /29 IPv6 address block from RIPE without justification 
[1]. This /29 may source more than a million unique IPv6 prefixes when 
using all CIDR sizes between /29 and /48 (the largest CIDR size that is 
not filtered). To prevent this many prefixes from flooding the DFZ, many 
ASes set a maximum prefix limit on their eBGP sessions.

When initially introduced, these max-prefix limits prevented prefix 
de-aggregation attacks. In today's hyper-connected world, prefix limits 
transform these attacks into session-hunting challenges. To better 
illustrate this relationship, consider the following example: If an 
adversary combines two remote-peering offerings of BSO's IXReach [2] and 
Epsilon's Infinity Platform [3], they can establish ports at more than a 
hundred peering LANs. If this adversary uses Hurricane Electric as their 
IPv6 transit provider and establish a BGP session at every in-common 
peering LAN [4], this will lead to 100+ sessions. With a per-session 
limit of e.g. 500 prefixes, the adversary could redistribute 50K unique 
prefixes via this setup alone.

If an adversary further increases the number of remote peering 
providers, adds announcements from BGP-enabled VPS services (e.g., Vultr 
[5] among many others [6]), and contracts additional IPv6 transit 
providers, they may globally increase the current IPv6 routing table 
size manifold. Notably, each of these new routes would have a valid ROV 
status once the adversary adds a single ROA entry for a /29 with a max 
CIDR size of /48; hence, they would pass the redistribution requirements 
for various transit providers.

While many current router models support multiple million IPv6 routes, 
especially older models may crash, drop sessions, or behave in other 
unintended ways when either their FIB or RIB runs out of memory. When 
the adversary also withdraws all routes simultaneously, the number of 
updates generated from BGP's path-hunting may further lead to very high 
load for extended periods of time.

To put this into perspective: Some of you might have noticed increased 
CPU load alongside other effects when Vultr was de-aggregating 12k IPv6 
prefixes on October 5th [7]. Using the different methods described 
above, an highly-motivated adversary might be able to produce 1-2 orders 
of magnitude more updates.

Please note that we performed various smaller (<600 prefixes) 
de-aggregation tests as part of our research---see sections 6 and 8 in 
the document referenced at the end of this notification for detailed 
explanations. While our experimental setup was very similar to the 
October 5th incident (we also announced address space obtained from 
SecureBit via VMs within Vultr), we are in no way related to that 
incident neither did we share any information about our research or 
findings with individuals outside our research group prior to the start 
of our private disclosure phase on October 11th.


# Detection, Mitigation, and Prevention Mechanisms.

Luckily, prefix de-aggregation attacks are easily detectable (e.g., 
based on prefix-limit notification thresholds or direct routing table 
size monitoring) and can be mitigated quickly by filtering either the 
more specifics of the covering prefix or all prefixes announced by the 
adversary's ASN(s). Effectively, damage can only be done within the 
human reaction time---which we hope to shorten with this notification.

To protect yourself from prefix de-aggregation attacks, you may 
establish dynamic yet tight per-session limits on all eBGP sessions. As 
an adversary could enter unreasonably large values into databases such 
as PeeringDB, we'd recommend to not solely rely on them but also accept 
at most 1.5-2x the number of yesterday's prefixes for peers and 
customers and 1.2x yesterday's routing table size for transit providers 
(which would currently reflect a headroom of ~32k prefixes with a yearly 
growth rate of <50k prefixes [8]). We'd also recommend ensuring that the 
summed prefix limits across all sessions do not drastically exceed the 
router's maximal FIB size.

To protect others, you may:

(i) ensure that you only redistribute a certain number of routes per 
origin; currently, AS 9808 announces the most (~4K) IPv6 prefixes.

(ii) ensure that you only redistribute a certain number of more-specific 
routes for each assigned address block; currently, 2409:8000::/20 is the 
prefix with the most (~10K) more-specifics.

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

Best regards,

Lars

[1] https://www.ripe.net/publications/docs/ripe-738#initial_size

[2] https://www.ixreach.com/services/remote-peering/

[3] https://epsilontel.com/global-network-footprint/internet-exchanges/

[4] https://he.net/peering.html

[5] https://www.vultr.com/features/advanced-networking/

[6] 
https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6ksY66c5o 
<https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6ksY66c5o/edit#gid=0>

[7] https://twitter.com/Qrator_Radar/status/1577748939805278209

[8] https://bgp.potaroo.net/v6/as2.0/index.html
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20221020/2c048e99/attachment.htm>