Protection against BGP hijacking

[Michel Le Bihan]

Hello,

I know that this has been discussed several years ago, but I didn't see any definitive final conclusion. In regards to the recent incident https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 that involved the malicious actor reacquiring a valid TLS certificate, I think that it might be worth to restart the discussion.

I know that the recommended solution is RPKI, but should there be other solutions that would mitigate this issue when RPKI is not deployed?

Some possible solutions:

1. Allow restricting validation methods in CAA records

2. Require CAs to have multiple vantage points

3. Not issue certificates shortly after suspicious BGP events

[Ryan Sleevi]

I’m not sure I see how 1 addresses this risk by itself. Are you thinking about this in isolation, or combined with some other mitigations (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the method, versus something like account binding?

2 is, effectively, unauditable and, at best, a probabilistic defense whose quality varies based on the selection of vantage points. Any attempt to make it auditable (e.g. via documentation about where and how points are selected) functionally serves to document the means to evade. There’s nothing wrong, in theory, but it’s akin to saying “Don’t open links from QR codes”: well meaning advice that, in theory, can mitigate attacks, but in practice, serves to do very little.

3 requires defining suspicious BGP events in a way that’s automateable enough to result in programmatic decision making, with limited false positives (false negatives roughly reduce into the same problem as #2). While there’s certainly interest in post-incident investigation to declare something anomalous, hindsight is 20/20, and typically based on combining perspectives from multiple vantage points.

I would be interested to know if there is something technically concrete, formalized, and readily accessible to solve #2 and #3, from the technical experts. My understanding of the state of the art is that it’s generally regarded that, between those two and RPKI (with ROV), RPKI is orders of magnitude easier and more measurable, and with less risk of inducing centralization through “blessed” transit providers/IX viewpoints. Has that state changed?

I don’t think advisory recommendations for #2 and #3 do much for mitigating the problem, if only because the weakest link problem of CAs. However, I’d be curious to know if there was more concrete proposals in this area for something that can be objectively and independently quantified, whether as part of an audit or by root program review. At present, it feels a bit like a tiger-repelling rock: yes, rocks can help mitigate the risk of tigers, but when and how is very contextual.

[Michel Le Bihan]

> I’m not sure I see how 1 addresses this risk by itself. Are you thinking about this in isolation, or combined with some other mitigations (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the method, versus something like account binding?

Yes, I assume that there is DNSSEC or the nameserver has RPKI, but the website ISP/hosting provider does not. I think that there might be many such cases.

[Ryan Sleevi]

On Mon, Feb 21, 2022 at 11:38 AM Michel Le Bihan <michel.le...@gmail.com> wrote:

> I’m not sure I see how 1 addresses this risk by itself. Are you thinking about this in isolation, or combined with some other mitigations (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the method, versus something like account binding?

Yes, I assume that there is DNSSEC or the nameserver has RPKI, but the website ISP/hosting provider does not. I think that there might be many such cases.

I would think that there wouldn't be that many, given the lower cost/risk of RPKI+ROV vs DNSSEC.

That said, it sounds like your threat model is assuming DNSSEC and relying on methods (3.2.2.4.7 - DNS Change  and 3.2.2.4.12 - Validating Applicant as a Domain Contact) exclusively, right?

That is, methods based on HTTP (3.2.2.4.6, 3.2.2.4.18, 3.2.2.4.19), TLS (3.2.2.4.20), SMTP (3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14), and/or (potentially) SIP (3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.15, 3.2.2.4.16, 3.2.2.4.17) would all be potentially hijackable. However, isn't there also an assumption here that the registrar and DNS servers are resistant to hijacks. For example, wouldn't an account password reset flow - which I think there might be many - defeat the security here?

That's not to say there may not be some value, but I'm just wondering if the nuanced return here might be more simplified via encouraging more RPKI (e.g. as https://www.manrs.org/ does)

[Matthias van de Meent]

On Mon, Feb 21, 2022 at 6:02 PM Ryan Sleevi <ry...@sleevi.com> wrote:

On Mon, Feb 21, 2022 at 11:38 AM Michel Le Bihan <michel.le...@gmail.com> wrote:

> I’m not sure I see how 1 addresses this risk by itself. Are you thinking about this in isolation, or combined with some other mitigations (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the method, versus something like account binding?

Yes, I assume that there is DNSSEC or the nameserver has RPKI, but the website ISP/hosting provider does not. I think that there might be many such cases.

I would think that there wouldn't be that many, given the lower cost/risk of RPKI+ROV vs DNSSEC.

That said, it sounds like your threat model is assuming DNSSEC and relying on methods (3.2.2.4.7 - DNS Change  and 3.2.2.4.12 - Validating Applicant as a Domain Contact) exclusively, right?

That is, methods based on HTTP (3.2.2.4.6, 3.2.2.4.18, 3.2.2.4.19), TLS (3.2.2.4.20), SMTP (3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14), and/or (potentially) SIP (3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.15, 3.2.2.4.16, 3.2.2.4.17) would all be potentially hijackable. However, isn't there also an assumption here that the registrar and DNS servers are resistant to hijacks. For example, wouldn't an account password reset flow - which I think there might be many - defeat the security here?

Yes, that would indeed defeat the security. But the point of closing down the verification methods is that it closes down potential attack vectors outside of the end users' control:

I _could_ currently implement an attack flow that uses BGP hijacking of the IPs of the servers that my A-records point to to receive a certificate using the HTTP verification methods, and get signed certificates at any of the CA's indicated in my CAA records; assuming the CA does no further verification than only what is required in the baseline requirements. We can remove this attack vector completely by limiting the allowed verification methods on my domain to only DNS Change (3.2.2.4.7), but this would currently require specific support from the CA that I have defined in my CAA record (I'm not sure there are CAs that do this).

Sure, this might also be implemented through CA account binding (or something similar); but that means that each CA would need to implement their own account binding system; which is not a scalable solution for users, and introduces the same issues as the DNS account reset flow, but now there's one more password that can be compromised.

[Ryan Sleevi]

On Mon, Feb 21, 2022 at 12:16 PM Matthias van de Meent <matt...@thisisntrocket.science> wrote:

I _could_ currently implement an attack flow that uses BGP hijacking of the IPs of the servers that my A-records point to to receive a certificate using the HTTP verification methods, and get signed certificates at any of the CA's indicated in my CAA records; assuming the CA does no further verification than only what is required in the baseline requirements. We can remove this attack vector completely by limiting the allowed verification methods on my domain to only DNS Change (3.2.2.4.7), but this would currently require specific support from the CA that I have defined in my CAA record (I'm not sure there are CAs that do this).

Correct, there aren't, because it turns out this is tricky to define in a way that doesn't ossify the validation methods (e.g. how .18 and .19 were introduced). That's not to say some CAs aren't in favor of it, but it requires a strict level of discipline in the CABF, and that's never been one of the Forum's virtues.

 

Sure, this might also be implemented through CA account binding (or something similar); but that means that each CA would need to implement their own account binding system; which is not a scalable solution for users, and introduces the same issues as the DNS account reset flow, but now there's one more password that can be compromised.

Yes, this is generally where I lean to as a solution, because it allows a degree of method agility that can be negotiated out-of-band. It has the downside that it's not as strict as the CAA method of limiting validation methods, but that's actually the upside/virtue trying to be achieved.

To the point of password compromise, though, it moves the risk model from the DNS Registrar/Registry to the CA, which allows for avenues like the Baseline Requirements (and/or NetSec) to set prescriptive requirements here around such flows. It's a trade-off, admittedly, between allowing users to select registrars that implement the desired level of security (e.g. WebAuthN bindings!), but provides a level of accountability at scale that would otherwise not exist.

 

[Matthias van de Meent]

On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <ry...@sleevi.com> wrote:

On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan <michel.le...@gmail.com> wrote:

Hello,

I know that this has been discussed several years ago, but I didn't see any definitive final conclusion. In regards to the recent incident https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 that involved the malicious actor reacquiring a valid TLS certificate, I think that it might be worth to restart the discussion.

I know that the recommended solution is RPKI, but should there be other solutions that would mitigate this issue when RPKI is not deployed?

Some possible solutions:

1. Allow restricting validation methods in CAA records

2. Require CAs to have multiple vantage points

3. Not issue certificates shortly after suspicious BGP events

I’m not sure I see how 1 addresses this risk by itself. Are you thinking about this in isolation, or combined with some other mitigations (like RPKI and DNSSEC)? And, if combining, do we really need 1 to bind the method, versus something like account binding?

Account binding might not be available for certain CAs. I would like it if e.g. CAA would also allow for restricting validation methods: A well-implemented DNS verification method uses DNSSec, which protects against BGP hijacks; whereas (to the best of my knowledge) there is no way to detect BGP hijacks  for HTTP- or other certificate requestor client verification (unless DANE is implemented, but this isn't widely deployed).

2 is, effectively, unauditable and, at best, a probabilistic defense whose quality varies based on the selection of vantage points. Any attempt to make it auditable (e.g. via documentation about where and how points are selected) functionally serves to document the means to evade. There’s nothing wrong, in theory, but it’s akin to saying “Don’t open links from QR codes”: well meaning advice that, in theory, can mitigate attacks, but in practice, serves to do very little.

Although difficult, locality of a resolver can be verified to some degree using a latency-based proof, using the signature of multiple timestamp signing servers

Example: if 10 distinct public (but with known location) timestamp signing servers sign increasing requests within half a second, the locality of the requestor is known as being within an average 50ms ping of all of those (or more precise: N1 ms from server 1, N2 ms from  server 2, etc.). A seperate set of 10 TsSigServers in a different locale can be used to bind the location of a different response, all assuming high enough signed timestamp precision).

3 requires defining suspicious BGP events in a way that’s automateable enough to result in programmatic decision making, with limited false positives (false negatives roughly reduce into the same problem as #2). While there’s certainly interest in post-incident investigation to declare something anomalous, hindsight is 20/20, and typically based on combining perspectives from multiple vantage points.

I would be interested to know if there is something technically concrete, formalized, and readily accessible to solve #2 and #3, from the technical experts. My understanding of the state of the art is that it’s generally regarded that, between those two and RPKI (with ROV), RPKI is orders of magnitude easier and more measurable, and with less risk of inducing centralization through “blessed” transit providers/IX viewpoints. Has that state changed?

There is RPKI, which uses a certificate/PKI-based approach to the question of who is allowed to publish routes for certain prefixes. This makes certain prefixes 'bgp-hijacking-proof' for some definition of 'proof': If your ISP and all ISPs in between you and the client implement RPKI correctly, then your route to the client is guaranteed to be authorized by the owner of that prefix (excluding the possibility of key compromise).

Sadly, not all infrastructure providers have implemented RPKI yet (see also: https://isbgpsafeyet.com/), but it doesn't seem impossible (or implausable) to require a CA to do validation from RPKI-protected (and filtering) endpoints.

I don’t think advisory recommendations for #2 and #3 do much for mitigating the problem, if only because the weakest link problem of CAs. However, I’d be curious to know if there was more concrete proposals in this area for something that can be objectively and independently quantified, whether as part of an audit or by root program review. At present, it feels a bit like a tiger-repelling rock: yes, rocks can help mitigate the risk of tigers, but when and how is very contextual.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGB8c%2BJFKEmzvyGtkvHvwX4fcoe_Sq64VmmpF%2B6ODph2Q%40mail.gmail.com.

[Matthew Hardeman]

On Mon, Feb 21, 2022 at 11:51 AM Matthias van de Meent <matt...@thisisntrocket.science> wrote:

There is RPKI, which uses a certificate/PKI-based approach to the question of who is allowed to publish routes for certain prefixes. This makes certain prefixes 'bgp-hijacking-proof' for some definition of 'proof': If your ISP and all ISPs in between you and the client implement RPKI correctly, then your route to the client is guaranteed to be authorized by the owner of that prefix (excluding the possibility of key compromise).

This assertion is inaccurate.  RPKI ensures that the advertised prefix has the/an origin-as (first ASN in the AS path) as dictated by the RPKI ROA records.  RPKI does literally nothing to ensure that the advertisement in question did actually occur at the behest of the stated origin.  Only that the stated origin is one of those authorized for that prefix.

For example: Consider a hypothetical prefix 12.0.0.0/12 with hypothetical ROA authorizing AS 4444 to advertise this.  Further consider hypothetical bad actor AS 5555 with upstreams AS174 and AS6939.

If AS 5555 wants to hijack this prefix, AS 5555 can synthesize a fake prepend of 4444 to their advertisement, as though they were a transit serving AS4444 and further sending that route upstream.  The advertisement is thus  4444 5555 174 / 4444 5555 6939.  If the upstreams consider that the best route, that will propagate.

What RPKI prevents in this case is a prefix advertisement of merely "5555 174" from being accepted as valid for 12.0.0.0/12.  RPKI by itself will not stop an advertisement like "4444 5555 174" from going out, even if AS4444 did nothing to facilitate or authorize 5555 making such an advertisement.

[Job Snijders]

On Mon, Feb 21, 2022 at 02:03:18PM -0600, Matthew Hardeman wrote:
> On Mon, Feb 21, 2022 at 11:51 AM Matthias van de Meent <matt...@thisisntrocket.science> wrote:
> > There is RPKI, which uses a certificate/PKI-based approach to the question
> > of who is allowed to publish routes for certain prefixes. This makes
> > certain prefixes 'bgp-hijacking-proof' for some definition of 'proof': If
> > your ISP and all ISPs in between you and the client implement RPKI
> > correctly, then your route to the client is guaranteed to be authorized by
> > the owner of that prefix (excluding the possibility of key compromise).
>
> This assertion is inaccurate. RPKI ensures that the advertised prefix has
> the/an origin-as (first ASN in the AS path) as dictated by the RPKI ROA
> records. RPKI does literally nothing to ensure that the advertisement in
> question did actually occur at the behest of the stated origin. Only that
> the stated origin is one of those authorized for that prefix.

I'd like to offer some nuance to the above claim that Matthias'
assertion is inaccurate. :-)

RPKI is a multi-purpose infrastructure: through certificates and a
PKI-based approach entitlements to Internet Number Resources ("INRs" aka
IPs and ASns) are securely delegated to the INR holders.

The RPKI can be used to publish various kinds of 'Signed Objects'. One
example is ROA records. ROA records bind prefixes to Origin ASNs in BGP
(as Matthew Hardeman mentioned)... however another example of records
published through the RPKI are BGPsec Router Keys - keys which can be
used to sign & validate entire BGP AS_PATHs (which is what Matthias
alluded to "If all ISPs implemented RPKI correctly").

A third example of an application using the RPKI are GBR records (RFC
6493) which are used to publish contact details for RPKI operators. More
applications build on top of the RPKI are in development in the IETF
SIDROPS working group.

> What RPKI prevents in this case is a prefix advertisement of merely "5555
> 174" from being accepted as valid for 12.0.0.0/12. RPKI by itself will not
> stop an advertisement like "4444 5555 174" from going out, even if AS4444
> did nothing to facilitate or authorize 5555 making such an advertisement.

The use of the phrase "RPKI" in the above paragraph is imprecise, what
Matthew appears to refer to is known as RPKI-based BGP Origin Validation
(also known as "RPKI ROV", the most widely deployed and used RPKI
application).

back to the core of this thread: I'm inclined to agree with Ryan's
observations in this message: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lxiA7zcKLws/m/L38QVnztAQAJ

Kind regards,

Job

[Matthew Hardeman]

I concur in full with the clarifications that Job made.

I was, indeed, referring to RPKI ROV, which to my knowledge is the only application built upon RPKI with substantial in-the-field uptake at this time.

[Matt Palmer]

On Mon, Feb 21, 2022 at 06:03:43PM +0100, Matthias van de Meent wrote:
> On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <ry...@sleevi.com> wrote:
> > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan <michel.le...@gmail.com> wrote:
> >> I know that this has been discussed several years ago, but I didn't see
> >> any definitive final conclusion. In regards to the recent incident
> >> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
> >> that involved the malicious actor reacquiring a valid TLS certificate, I
> >> think that it might be worth to restart the discussion.
> >>
> >> I know that the recommended solution is RPKI, but should there be other
> >> solutions that would mitigate this issue when RPKI is not deployed?
> >>
> >> Some possible solutions:
> >> 1. Allow restricting validation methods in CAA records
> >> 2. Require CAs to have multiple vantage points
> >> 3. Not issue certificates shortly after suspicious BGP events
> >
> > I’m not sure I see how 1 addresses this risk by itself. Are you thinking
> > about this in isolation, or combined with some other mitigations (like RPKI
> > and DNSSEC)? And, if combining, do we really need 1 to bind the method,
> > versus something like account binding?
>
> Account binding might not be available for certain CAs.

Then don't use those certain CAs, and restrict those CAs from issuing for
your domain by not including them the domain's CAA records.

> I would like it if
> e.g. CAA would also allow for restricting validation methods:

RFC8657 defines the `validationmethods` parameter to the `issue` and
`issuewild` CAA properties. Again, if a given CA doesn't support those
parameters, you can avoid the problem by not including that CA in your CAA
records.

- Matt

[Matthias van de Meent]

On Tue, Feb 22, 2022 at 2:30 AM Matt Palmer <mpa...@hezmatt.org> wrote:

On Mon, Feb 21, 2022 at 06:03:43PM +0100, Matthias van de Meent wrote:
> On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <ry...@sleevi.com> wrote:
> > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan <michel.le...@gmail.com> wrote:
> >> I know that this has been discussed several years ago, but I didn't see
> >> any definitive final conclusion. In regards to the recent incident
> >> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
> >> that involved the malicious actor reacquiring a valid TLS certificate, I
> >> think that it might be worth to restart the discussion.
> >>
> >> I know that the recommended solution is RPKI, but should there be other
> >> solutions that would mitigate this issue when RPKI is not deployed?
> >>
> >> Some possible solutions:
> >> 1. Allow restricting validation methods in CAA records
> >> 2. Require CAs to have multiple vantage points
> >> 3. Not issue certificates shortly after suspicious BGP events
> >
> > I’m not sure I see how 1 addresses this risk by itself. Are you thinking
> > about this in isolation, or combined with some other mitigations (like RPKI
> > and DNSSEC)? And, if combining, do we really need 1 to bind the method,
> > versus something like account binding?
>
> Account binding might not be available for certain CAs.

Then don't use those certain CAs, and restrict those CAs from issuing for
your domain by not including them the domain's CAA records.

That assumes that there are CAs that implement RFC8657, and that I trust for my domains, and would issue certificates for my use cases.

> I would like it if
> e.g. CAA would also allow for restricting validation methods:

RFC8657 defines the `validationmethods` parameter to the `issue` and
`issuewild` CAA properties.  Again, if a given CA doesn't support those
parameters, you can avoid the problem by not including that CA in your CAA
records.

Of the roots in the Mozilla root store [0], only one CPS mentions RFC 8657, and that one does not give me any guarantee that it will actually limit issuance to only the verification methods in my CAA record: "Google may choose to limit issuance according to RFC 8657" (i.e. non-conformance to RFC 8657 does not violate their CPS). Additionally, the CPS does not provide validation method identifiers to be used for BR validation methods; so only ACME validation methods are usable (while at the same time useless because there is no ACME endpoint that I could use).

CA/B Forum Baseline Requiremets requiring compliance to RFC 8657 would be a great improvement.

- Matthias

[0] https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport, searched each root for CP/CPS queried for "CAA", stopping the search when I find a CP/CPS for that root / CA that contains the Issuer Domain Name.

[Michel Le Bihan]

Recently there was another case of BGP hijacking where an attacker acquired a TLS certificate: https://www.coinbase.com/blog/celer-bridge-incident-analysis

[Ben Wilson]

All,

In the article, I saw advice about actions that project owners can take to protect themselves, but what about things that CAs or root store programs can or should do?

Ben

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b84287a6-94bd-450e-aa6b-49c629cae2ddn%40mozilla.org.

[Moudrick M. Dadashov]

Consider telco root store applications as high risk ?

Thanks,

M.D.

Sent from my Galaxy

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabKH4xi5EXUydci0A8WJNZUawxsGWHeWAuJA2tX_uyLvA%40mail.gmail.com.

[Henry Birge-Lee]

Hi Ben,

My name is Henry Birge-Lee. I am a researcher at Princeton University. I began studying the use of BGP attacks to obtain bogus TLS certificates in 2017 and worked to design a countermeasure known as multiple vantage point domain validation which can be implemented by CAs. It involves a CA performing domain control validation from multiple vantage points spread throughout the Internet. This allows the CA to detect BGP attacks because many BGP attacks do not affect the entire Internet (vantage points not affected by the attack contact the server of the victim and realize that the victim never requested the certificate).

We have since worked diligently through a collaboration with Let’s Encrypt to get this countermeasure fully deployed at scale in Let’s Encrypt’s production operation and we co-authored a USENIX Security paper with Let’s Encrypt engineers to explain the details of and evaluate this deployment from a security and performance perspective ( https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee ). Cloudflare also has a deployment of multiple-vantage-point validation ( https://blog.cloudflare.com/secure-certificate-issuance/ ) which I was  involved in evaluating as well. Finally, Google Trust Services recently started performing multiple vantage point validation and Ryan Hurst at google posted a series of tweets referencing this in light of these recent BGP + TLS attacks: https://twitter.com/rmhrisk/status/1574995320727293952 

We have been internally working on the most appropriate way to bring this topic to the CAB Forum (I was lucky enough to be invited to a validation working group meeting several years ago, but this project was not as mature then and I feel it needs to be further reassessed in light of the recent attacks), but at a high level I feel it is really important to mention there is an effective and deployable mitigation available to CAs, and we are working on taking the next steps to expand the adoption of multiple vantage point validation.

P.S. We also wrote a blog about the KLAYswap attack in February of this year that was performed using a similar technique: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/

[Michel Le Bihan]

Hi Henry Birge-Lee,

I found your USENIX presentation very interesting. However, I don't quite understand the example of the real world attack. In the graphic it seems that the malicious announcement

propagated to about 50% of the internet. Will a malicous announcement stop propagating at some point and reach x% or could it reach around 100% if for example it is a more specific prefix?

[Henry Birge-Lee]

Hi Michel,

You are correct that it is possible for an attack to propagate to the vast majority of the Internet (I hesitate to say 100% as there are usually some clients using a particular route) and sub-prefix attacks (where the adversary announces a more-specific prefix than the victim) are a good example of this. That said, I think it is important to mention that sub-prefix attacks are becoming increasingly less viable as more and more of the route table is secured with RPKI. Let’s Encrypt’s vantage points all perform Route Origin Validation (or ROV where routes are filtered based on RPKI data) and the major cloud providers we see hosting TLS domains have published Route Origin Authorizations (or ROAs, cryptographic authorizations of IP prefix length and origin AS): Amazon, Azure, ClouFlare, Google, OVH to name a few (see https://isbgpsafeyet.com/). RPKI prevents sub-prefix attacks because it specifies not only the proper origin ASN for IP prefixes but also the length of the IP prefix that can be announced in the route table. Thus, sub-prefix attacks are filtered by ROV (which is deployed by Let's Encrypt).

Furthermore, sub-prefix attacks are very easy to detect with BGP monitoring both because of their global propagation (meaning they propagate to pretty much any monitoring node) and because of their distinctive signal in the BGP feed.

As for equally-specific prefix attacks, affecting the entire Internet is extremely difficult which is what we demonstrated with our Internet topology simulations and resilience calculations. An equally-specific prefix attack can be thought of as competing for traffic with the victim's own announcement, and the result is that nodes topologically closer to the victim tend to prefer the victim's route and vice versa. We modeled millions of equally-specific attacks to see how many of them multiple vantage point validation could detect, and Let's Encrypt's current deployment was able to detect the vast majority (94%) of them. The attacks that were missed could be detected simply by adding more vantage points.

I think the overall takeaway is that because of the dynamics of BGP routing and continually improving routing security measures, actually launching an attack that affects the entire Internet is extremely difficult. Furthermore, multiple vantage point validation synergies very well with what is happening in the world of BGP, as sub-prefix attacks are much easier to address with BGP security measures than equally-specific prefix attacks.

Feel free to reach out if you have any more questions.

Best,

Henry

P.S. We are working on some really interesting new results looking at the interaction of multiple vantage point validation and RPKI which we are hoping to publish in a conference paper coming up.