<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p data-pm-slice="1 1 []">Dear Routing WG,</p>
    <p>Our apologies to those who received this message via multiple
      channels.</p>
    <p>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.</p>
    <p><br>
    </p>
    <p></p>
    <p># Prefix De-aggregation Attacks</p>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
    <p>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. </p>
    <p>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. </p>
    <p>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. <br>
    </p>
    <p><br>
    </p>
    <p></p>
    <p># Detection, Mitigation, and Prevention Mechanisms. </p>
    <p>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.</p>
    <p>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.</p>
    <p>To protect others, you may:</p>
    <p>(i) ensure that you only redistribute a certain number of routes
      per origin; currently, AS 9808 announces the most (~4K) IPv6
      prefixes.</p>
    <p>(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.</p>
    <p></p>
    <p>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:</p>
    <p><a href="https://arxiv.org/pdf/2210.10676.pdf"
        title="https://arxiv.org/pdf/2210.10676.pdf" rel="noopener
        noreferrer nofollow" class="moz-txt-link-freetext">https://arxiv.org/pdf/2210.10676.pdf</a></p>
    <p>Best regards,</p>
    <p>Lars</p>
    <p></p>
    <p>[1] <a
        href="https://www.ripe.net/publications/docs/ripe-738#initial_size"
title="https://www.ripe.net/publications/docs/ripe-738#initial_size"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://www.ripe.net/publications/docs/ripe-738#initial_size</a></p>
    <p>[2] <a href="https://www.ixreach.com/services/remote-peering/"
        title="https://www.ixreach.com/services/remote-peering/"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://www.ixreach.com/services/remote-peering/</a></p>
    <p>[3] <a
href="https://epsilontel.com/global-network-footprint/internet-exchanges/"
title="https://epsilontel.com/global-network-footprint/internet-exchanges/"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://epsilontel.com/global-network-footprint/internet-exchanges/</a></p>
    <p>[4] <a href="https://he.net/peering.html"
        title="https://he.net/peering.html" rel="noopener noreferrer
        nofollow" class="moz-txt-link-freetext">https://he.net/peering.html</a></p>
    <p>[5] <a
        href="https://www.vultr.com/features/advanced-networking/"
        title="https://www.vultr.com/features/advanced-networking/"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://www.vultr.com/features/advanced-networking/</a></p>
    <p>[6] <a
href="https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6ksY66c5o/edit#gid=0"
title="https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6ksY66c5o/edit#gid=0"
        rel="noopener noreferrer nofollow">https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6ksY66c5o</a></p>
    <p>[7] <a
        href="https://twitter.com/Qrator_Radar/status/1577748939805278209"
title="https://twitter.com/Qrator_Radar/status/1577748939805278209"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://twitter.com/Qrator_Radar/status/1577748939805278209</a></p>
    <p>[8] <a href="https://bgp.potaroo.net/v6/as2.0/index.html"
        title="https://bgp.potaroo.net/v6/as2.0/index.html"
        rel="noopener noreferrer nofollow" class="moz-txt-link-freetext">https://bgp.potaroo.net/v6/as2.0/index.html</a></p>
    <p></p>
  </body>
</html>