upvote
I think that way to solve BGPs security problems might be to use a new cryptographic hammer, "Proof-Carraying Data", where messages come with cryptographic proofs that they were produced correctly. This allows you to basically just run BGP, but every AS proves that it ran it correctly. The proofs take constant time to verify, regardless of how large the network is, or how many hops the routing message has taken. Feasibility is helped by latency not being super critical in BGP and BGP being a pretty simple protocol; which makes computing these proofs plausible.

https://rot256.dev/post/bgp-pcd/

Proof-carrying data has come a long way in the last 10 years.

EDIT: you would still need RPKI, but not BGPSec

reply
“Safe” the platonic ideal is an impossibility. Any cryptographic solution depends ultimately on handshake agreements between fallible human executives and/or fallible human registries, and there’s no known alternative to that today. Is RPKI “safe”, relative to not RPKI? Yes, obviously, it is. Is it reasonable to interpret “safe” as ‘no further improvement is required’? Never: this is the Internet; one could expect the domain to be repurposed to cover more than RPKI someday. Yes, short-sighted leaders may use “RPKI is safe” as justification to withhold investment forward past it; but that outcome is certain regardless of how they justify it.
reply
RPKI makes prefix ownership verifiable, but the path is still largely trust-based.

It feels like we’ve secured the part that’s easiest to validate, not necessarily the part that matters most.

reply
deleted
reply
I believe the current attempt at mitigation for this is ASPA[0]. It still has a long way to go, but there are some big names behind it.

[0]: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-asp...

reply
It has a long way to go, in the same sense that ROA had a long way to go when Cloudflare first launched this site in 2020. ASPA records are fully supported by both RIPE and ARIN these days.
reply
> and get the victim's traffic sent to it

This sounds "obviously bad" but the intricacies of routing aren't really my field, could you expand on why this is bad? (i.e. what specific bad things does it enable)

reply
Here are some examples:

The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.

The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.

The attacker can just deny access to the victim - just drop packets meant for the victim.

reply
I think RPKI is good enough. As we have TLS on top it doesn't need to be perfect.
reply
For LetsEncrypt, routing is authentication: if packets routed to the IP in the A record end up at your place, you can get a cert for that domain.
reply
Only with certificate pinning or something similar. Otherwise, the attacker can get valid TLS certificates for any domain hosted on the hijacked IP addresses.
reply
Those two things address orthogonal issues
reply
[dead]
reply