RPKI doesn't sign hops in the path for a BGP update. That means to hijack a prefix, all you need to do is to take a legitimate route and re-advertise it with your AS as the second hop in the path.
This isn't as damaging as being able to advertise a smaller prefix because it won't send all traffic to you. It will just send from routers where your path is shorter than the original.
To actually prevent hijacking via path shortening attacks like this, you need a full BGPSEC implementation https://en.wikipedia.org/wiki/BGPsec which is a much higher barrier than RPKI because the crypto operations jump 1 or 2 orders of magnitude (signing every re-advertised route rather than just originated routes).
So RPKI gets the cert infra in place, but it doesn't really fully solve the problem.
But, with RPKI getting the cert infra in place, would that not then make it relatively easier to take that 2nd step, than when not even RPKI was in place?
The problem is the number of updates / changes that happen all the time in BGP, and having each router cryptographically validate each one / sign every update it sends.... it doesn’t scale well.
The BGPSEC theory is there but not sure if we can make a workable system.
Current routers can't handle it, but ... it's not like routes changes that much that we're talking about an intolerable amount of RSA operations. We're really talking about fewer operations per day per router than some web frontends do in a second.
60k/second across 24 cores, admittedly on very fast hardware (though not using all the cores that hardware has). Pretty much the same number on 16 cores.
In general, telling someone they're "way off" about performance and citing 6 year old benchmarks isn't a winning plan.
In any case, it's immaterial to what we're discussing. My slow laptop could verify all the signatures for a busy day of updates in a couple seconds, and it's clearly -possible- to put a big fraction of this horsepower in a router.
Took me a minute to realize you were Job Snijders too lol.
We both know there are still garbagey nets out there using ARM32, MIPS and who knows what else out there for control plane processing. Only the big guys are gonna upgrade to support this.
I guess we'll see what happens TBH.
I didn't realize it'd been available in JunOS since 12.2 which covers a variety of devices (even some old stuff I've seen on customer sites), I've yet to come across a site with it deployed. Maybe I should do some consulting for folks.
Nothing stops you hooking up a regular PC to do route validation and run the BGP protocol and stuff, and load validated routes into any router you choose.
The first namely being that nobody is going to do that unless they have too much time on their hands and don't actually run a real network. "Just loading routes" into a router is not really that straightforward.
> mine uses PPC, which hasn't been in a desktop in quite some time
Raptor sells desktops with IBM POWER9 CPUs – https://www.raptorcs.com/content/base/products.html – they are expensive, and the same amount of money would buy you a much more powerful x86 system, but they exist.
This isn't as damaging as being able to advertise a smaller prefix because it won't send all traffic to you. It will just send from routers where your path is shorter than the original.
To actually prevent hijacking via path shortening attacks like this, you need a full BGPSEC implementation https://en.wikipedia.org/wiki/BGPsec which is a much higher barrier than RPKI because the crypto operations jump 1 or 2 orders of magnitude (signing every re-advertised route rather than just originated routes).
So RPKI gets the cert infra in place, but it doesn't really fully solve the problem.