A professor at my University mentioned that when he was a student, the professors at that time claimed that the security of BGP is a solved problem and nobody is going to talk about it in ~2 years. This was +20 years ago. He has spent a lot of his research on an alternative for BGP called SCION[1], as the adaption of BGPSec is not very straight forward and rather an ugly fix.
I think it is pretty interesting that the problems of BGP are not discussed more widely and often.
I worked for a big European network vendor and ended up on a project trying to sort out the utter mess that is legacy SS7.
SS7 networks are basically wide open, with no auth and anyone can get an SS7 hub for cheap and start sending nefarious commands to peoples handsets. They can forward or record calls and read SMS. They can track you or they could just be a jerk and keep rebooting your phone. Worse still it can be used to intercept 2FA codes over SMS, which is the approach a lot of banks are taking for personal account security. intelligence agencies are without a doubt using it for intercepting and tracking.
The Telcos are lost with how to address the issues combined with cost considerations, so most are taking the approach of hoping it stays out of the news and waiting for it to eventually be deprecated from the network.
Ah Adrian! Yes his SCION is quite impressive and has plenty of cool features, but if it will ever outgrow the “future internet” technology phase remains to be seen.
I (other account) once submitted their work to HN to see what real smart people thought about it, but it got 0 traction.
I'm not sure what you mean because it basically is the same thing just without cryptographic surety.
And the "peering problem" is absolutely solved with proper route filtering...
It would be interesting to read more about the problems with RPKI. The set of organizations that need to implement RPKI to make it effective is pretty small, and yet it's been a long slog to get it even to this point. It's not like network engineers at Google, Comcast, and Verizon are unfamiliar with it. What's going wrong?
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.
The same thing that's going wrong with IPv6 adoption.
Edit: It's true. RPKI works, it's just harder to use than not using it, and network engineers have been doing bgp without rpki since forever. Managing PKI is outside the scope of a Cisco flat file and so it's not getting done. Route maps are easier to write than managing PKI. In the same vein IPv4 networks work and have been done since forever and as long as it's easier to shim over your v4 core and do carrier NAT and memorize dotted quads v6 will not get done with haste.
The excuse used to be there wasn’t adequate tooling. That’s changed over the last 18 months. See, for example, the open source GoRTR tool our team released:
There's a few challenges with the adoption/deployment of RPKI.
Remember, there are two parts here:
-Signing your IP address space (generating ROAs to reference your Origin ASN and Max Prefix Length).
-Implementing Origin Validation in your network (getting an RPKI validator, grabbing ROAs, talking RTR to routers).
There's also another aspect here worth calling out. Which is that RPKI at the moment doesn't address path validation. Basically, stopping routing leaks or addressing as-path spoofing. AS Path Authorization is still in the early days at the IETF, but the idea is people can piggyback off the existing RPKI infrastructure to implement it without making any major changes. Some folks will say because there is no ASPA - that Origin Validation isn't worth the effort, but I disagree with that - any bit helps to stop hijacks.
Going back to ROA generation, there are two ways to sign announcements. You can go to your RIR and use their APIs or website to do it. Some of the RIRs have okay APIs, some are not so great (which is a pain if you are into automation). You can run in delegated RPKI mode and do your own CA, but that is a fair amount of work and only a few people on the planet do it (but props to those people who have open sourced the s/w and making this easier). The other two challenges with ROA generation are that if you screw it up, it's real painful to unwind. Revoking the ROA can take hours to take effect, or publishing a new/corrected ROA can take hours. If you screw up and specify the wrong ASNs (or lets say you migrate ASNs over), or screw up the max prefix length, you can invalidate your address space on the Internet and blackhole yourself. The other issue is with ARIN - specifically the fact that people running RPKI validators have to deliberately accept the ARIN Trust Anchor for legal reasons (ARIN indemnification). There is evidence that some people are installing the validators and not adding ARINs trust anchor, resulting in not accepting any ROAs that went through ARIN - which is a big chunk of the Internet.
As for Origin Validation, there have been some great open source efforts in the last few years to make this easier to adopt (and big thanks to those whove lowered the bar here). That said, it still means building/deploying this in a robust way, enabling RTR on all your routers and writing policy to reject invalids. It's just a bunch of work and for some networks, it takes time to roll that out globally. Then there is the question of which routes do you apply validation on? What if your have customers who screwed up ROAs? Now you have to coordinate and get them to clean up their game before you turn on the switch or poke holes (nasty). Finally, you have to agree that you are going to essentially drop invalid prefixes for destinations on the Internet. That means if someone on the other side of the world screws up a ROA, you're not routing to them. You've got to be prepared to tell a customer why they can't reach their destination on your network, but another network without origin validation can (like a competitor).
that said, there is no reason to not sign your address space today and start rolling origin validation. there are a number of network operators in the right spots (irc, mailing lists) who are there to help you and give you guidance if you need it.
ps - hi tom. i still have your enteract card from years ago and recall meeting you a few times at the third coast cafe.
IRRs already solves this problem. RPKI just adds crypto because hand waving reasons.
Providers won't implement RPKI for the same reason they haven't implemented IRR filtering or BCP38 for the last 10 years. It adds operational overhead, adds another thing that might go wrong, and there is no financial incentive.
IRR has data issues. RIRs put some control around this (tying prefix to org), but plenty of trash in the other IRRs (people claiming they own /12s they don't, etc). Also the chain of people using as-sets to mark who their customers are is busted. People are being way too broad by putting peers in their set for networks that aren't their transit customers - and prefixes get permitted.
The BCP38 war is lost. Credit to those who try to do better but it's the hosting shops who are the biggest offenders. Most broadband and cloud providers do this proper. I chase down tcp syn reflection attacks and they always come from the same types of hosters.
I have been a huge fan of Hurricane Electric (he.net) for over ten years and have done a lot of evangelizing ... rsync.net uses he.net pops all over the world (except for Zurich, where we use init7...).
They have been very progressive, clueful and efficient in all of our dealings with them.
So I am surprised to see them marked unsafe. I have emailed my point of contact there and asked for some explanation - perhaps I can update this comment in a bit ...
A startup company that several of my friends worked at many years ago had boxes that continuously monitored routing around that would and would flag and delay BGP updates that caused a significant topological change. They could be added manually immediately, or would be implemented with a delay after they had enough data that the route was legitimate.
My ISP had one of these boxes and was quite proud of it. It worked really well against BGP idiocy. It might not have worked against a concerted attack, but it did stop several of the "Ooops. All the routes are belong to us." problems that seem to be the "normal" BGP "attacks".
I am surprised that these big players don't already have something that does something similar.
Of course they do have such equipment, which makes you wonder how sophisticated the attacks are and now flimsy the security is. It’s obvious that this equipment exists. How else would the equipment in the same or likely next room over [0] know the state of packets that need further routing adjustments?
Maybe the relevant parties didn’t get the message because the call was coming from inside the building. [1]
The internet community (I.e. routing guys/Nanog/ietf etc) is fairly open. I’ve not heard much of such approaches being used. It is a very interesting idea.... I guess you gotta weight delaying inserting an update with potentially blackholing a destination until you do.
For an quick dragnet to get an IP in a sea of noise, it would work. In any case, you just have someone else do it, accidentally of course. The more accidental and and wide reaching and quickly reverted the outage is, the more plausibly deniable it is.
I agree that this approach isn’t really suitable for much else because it’s much too overt and likely to notify the target. Modern engagements use BGP hijacks as a critical tool with a lot of capabilities but also extreme visibility and publicity. So it’s not good for most jobs as other better suited tools for those jobs already exist. [0] [1]
Hurricane Electric doesn't implement RPKI Origin Validation as most people understand it. They try to do some route filtering that is RPKI like, but it's not the same.
Looks like there may be problems with the mirror sites, a generated tarball is on the official portable github, but it may be worth waiting for an official announcement as github can re-roll these (it's not an uploaded release asset): https://github.com/rpki-client/rpki-client-portable/releases
the most promising replacement is the SCION[1] project. See section "Authentication and PKI"[2]. It's already used by SwissCom and another CH based ISP. It can do path selection, geo-fencing, and traffic shaping. Really cool DDoS mitigation[3] as well. It has been previously discussed on HN[4].
I love the way they basically say they are gonna do their own assessment and won’t roll in behind the consensus on RPKI. Like the trend-setting industry leaders they are.
They deserve to be called out for this. It’s not hard to implement RPKI. Only valid excuse is if your routers don’t support it.
Signing ROAs is trivially easy in the RIPE region. Why haven’t they done so before the pandemic???
Wasting time with this response instead isn’t maybe the best use of their time.
The trick is to get something VPs / "Decision Makers" can use to make decisions that's easy for them to digest especially if they are not technically sophisticated. This meets that criteria.
They should add microsoft azure to this list.
This could absolutely become an RFP requirement / preference point for a lot of compliance focused / not only tech focused buyers (govt / large agencies and companies)
They are visually appealing and are technically implemented nicely. I think, however, that they are not very insightful to the matter. It is easy to visualize the result of a BGP hijack: packets are routed to the wrong/malicious destination; so is visualizing the result of RPKI: packets aren't routed to the wrong destination.
What, to me, would have provided a little more value would have been to diagram how BGP hijack happens (visualize a router announcing the wrong route), and how RPKI solves the issue. Of course, those 2 things are probably much harder to diagram.
(Designer of the site) This is such a great point, and something I’d definitely like to tackle in a future iteration. Thanks for the push in that direction!
Yes, they look really great and responsive, too. I'd actually like to know how they were done... Are they just basically coded by hand or is there a visual tool you can use to design interactive graphical stuff like this in what I guess is HTML5/CSS/maybe JavaScript, similar to (dare I mention the word) Flash in the olden days? (Sorry, haven't done any web development in decades, obviously :-)).
Nitpick but the terms are useful: they are not responsive, they are interactive. Responsive (in modern front-end parlance) means they would adapt to different screen sizes. Some mainstream publications have been publishing responsive diagrams and I love it (here's an outstanding example: [1]). But this is not the case here.
It’s really just using CSS to animate regular HTML elements. SVG is used for the icons (the laptop, server, cloud), but the grid lines, connection lines, and packet animation are all just plain `<div/>`s :P
But you’re totally correct about the JS only toggling between path="happy" and path="sad"
Hallmark of a PR department. Cloudflare seems to have an interest in pushing this, and while I'm not quite clear on why my assumption is that they get to control the signing when ISPs sign up with them.
It seems to me that trust is not a global thing. If A trusts B then that does not mean that C would also trust B. Does the protocol capture that principle?
A PKI provides us with a globally trusted answer about identity only. If there is no global consensus about identity then you don't actually have a network.
If you don't agree that this is news.ycombinator.com and believe instead it's 4chan or Reddit, then the Web PKI can't help you, and "improving" the Web PKI to some people decide this is Apple and others that it's PornHub is pointless. If you want other names, go build your own network.
In RPKI the identities aren't DNS names like in the Web PKI they're number resources - IP addresses and Autonomous System numbers. Again though, if you can't agree with everybody else about global identity you can't participate in the network.
If you believe maybe 1.1.1.1 is the IP address of your PC and everybody else thinks it's a distributed DNS service run by Cloudflare, there's no purpose to trying to allow us to "agree to disagree". We're right, and you're wrong, go away.
Having global agreement about identity doesn't magically mean we all agree on who to trust, just because I agree with you that Reddit is Reddit, doesn't mean I agree about how much faith to put in a post you saw there.
I remember the first time i setup a rack of servers in a cage in a datacenter for a company i founded. We bought a block of IPs in bulk and then we bought an interconnect from a provider within the datacenter. To get those IPs pointing to our server we had our severs announce ownership over BGP. It's that easy.
Usually BGP messages are filtered out by routers. Otherwise home users would announce ownership of the Google addresses and have all those messages come to them for example. But if you have access to an interconnect in a datacenter you can state you own whatever IP addresses you want. There's really nothing at all stopping it right now.
While RPKI is great, saying BGP will be “secure” once it’s deployed is not true.
It’ll be more secure, sure. But RPKI only addresses origin validation, not path validation. It won’t stop me announcing your space spuriously provided it has your AS as the origin. Path-validation a la BGPSEC would be needed to stop that. But that’s an extremely difficult problem to solve given the amount of churn in the global routing table. The amount of crypto validation routers would need to do is prohibitive. And Moore’s law doesn’t help because as CPU power goes up so do the key sizes we need to use.
Either way people should implement RPKI, or at least sign ROAs for their space. It’s easy to do and makes a bit improvement.
I would argue that for BGP to be safe, all ~68,000 autonomous systems will need to embrace RPKI, not just a handful of ISPs/telcos/CDNs. Akamai is announcing ~2,300 prefixes, shouldn’t they use RPKI?
Yes, though it’s a bit like if every airline implemented an accurate COVID-19 health check. You’d still have local problems, but the infection would keep from spreading worldwide. In the case of BGP, if the major transit providers properly filter routes, hijacks do much less damage to the broad network.
How are you verifying compliance? It looks like to pass the test all I need to do is implement filtering on my interconnects with Cloudflare (or just drop 103.21.244.0/24 entirely).
To your example, airlines could screen passengers flying out of Eastdakota Regional Airport but nowhere else.
We can always change up the bad IP range announced.
But, more generally, I think the network engineers at ISPs want to implement RPKI. It’s the managers who haven’t prioritized. Hopefully this helps escalate it as a priority.
I really appreciate this kind of meta-commentary on the recent trend of single purpose sites. It would be easy to dismiss them, but they’re as much a part of the web as any other content a browser can render. It’s a sign of a mature platform when you have trends and norms while also admitting outliers and oddities.
going on a tangent here... I looked at the stylesheet (https://isbgpsafeyet.com/index.css?v=24) and saw things like `border-top-color: currentColor;` and other variables used in plain CSS that I didn't even know you could do.
I would discourage this approach. Internet spam-generating campaigns aren't really an effective way of creating change, and the poor employee required to read the emails at that contact address is probably not responsible for the decisions holding up implementation.
Which is to say: Please don't advocate for behaviors that harass line employees at corps you don't like.
As for whats stopping the announcement of bad routes? Mostly just the ISPs, the big transit providers, and the IX's.
The problem isn't the small users. You, as a nefarious individual, are unlikely to be able to cause much real damage. In datacenters where you don't bring your own dedicated transit (expensive), you have to tell them your ASN and IP information so it gets whitelisted.
The problem is large players. If China Telecom wants to claim Google's IPs... well the entire world's transit providers may not acknowledge that - but enough will to cause a real problem. More examples: https://en.wikipedia.org/wiki/BGP_hijacking#Public_incidents
Another RPKI tool: https://rtrlib.rpki.net/ allows to fetch RPKI data from a cache server. using the rtrclient, which is part of the package, you can export ROAs to any format.
I was playing around with this, and it seems the entire section "What's a BGP hijack?" totally disappears on smaller screens. Is this intended? Seems like a pretty important section!
Does this solution apply to private networks? I learned first hand how dangerous it can be when I brought down our datacenter with an accidental BGP announcement.
You can do this. I know a few large well know networks which have suffered from internal BGP hijacks within their data centers from different business units stepping on each other. You can either try to implement via strict route policies or try to do RPKI.
I remember doing an IP range scan with nmap from an EC2 instance in the early days, and finding a bunch of exposed BGP routers. I wonder how vulnerable they were.
[1] https://www.scion-architecture.net/