Remix.run Logo
maltalex 8 hours ago

RPKI doesn't make BGP safe, it makes it safer. BGP hijacks can still happen.

RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.

The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.

rot256 7 hours ago | parent | next [-]

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

altairprime 3 hours ago | parent | prev | next [-]

“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.

heyethan 6 hours ago | parent | prev | next [-]

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.

6 hours ago | parent [-]
[deleted]
impl 7 hours ago | parent | prev | next [-]

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...

greyface- 6 hours ago | parent [-]

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.

Retr0id 7 hours ago | parent | prev | next [-]

> 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)

maltalex 7 hours ago | parent [-]

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.

hugo1789 4 hours ago | parent | prev | next [-]

I think RPKI is good enough. As we have TLS on top it doesn't need to be perfect.

maltalex 3 hours ago | parent | next [-]

Only with certificate pinning or something similar. Otherwise, the attacker can get valid TLS certificates for any domain hosted on the hijacked IP addresses.

rot256 3 hours ago | parent | prev | next [-]

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.

zymhan 2 hours ago | parent | prev [-]

Those two things address orthogonal issues

diablevv 7 hours ago | parent | prev [-]

[dead]