Maybe it's just my impression, but this article tries to make it sound like they should have addressed this from the beginning.
Looking back, it's doubtful that a secure version up front would have worked. Routers were pretty feeble back then, and getting them to verify crypto signatures for advertisements would have been a non-starter.
This is especially true since there are still many issues with the secure replacements when it comes to key distribution issues, manipulating path costs, etc. With all of the modern crypto we have now, it's still a non-trivial problem to solve.
And misses the point (not to be a circuit switched bigot) that there where existing networks based on OSI that where technically superior.
But they cost a lot more and required more technical rigor to implement (yes I am looking at you Sprint/ Microsoft) and some times Good enough for jazz is the way to go.
It's not a crypto problem. It's not about who you're talking to. It's what they tell you, and where they got the info they're telling you. Mutually mistrustful routing is very hard.
- and tell you about views of the Internet passed on from other neighbors
You can arrange to absolutely trust a given neighbor to be that neighbor, but until every BGP speaker in the world has that relationship, you can't trust the data that they pass on.
And every BGP speaker in the world has both direct controls (advertise this AS, don't advertise that AS) and influential controls (pretend that this AS is farther away than it is, prefer this AS here and not there because it's cheaper for us) that are both necessary and desirable, because money constrains what engineering can do.
Well stated. Cisco's docs go into great detail on this - they've spent a lot of time thinking about how to address the issues in plain ol' BGP with SoBGP (Secure Origin BGP), and they concluded that determining a BGP speaker is authorized to announce a particular route is impossible in a functioning internetwork.
End-to-end ecryption doesn't defend against misrouting, although it does mitigate the damages of it. However, with our current CA system, nation level adversaries could easily MITM an encrypted connection that they have rerouted through their servers.
Because your client (generally a browser) is configured to implicitly trust a group of companies called "root Certificate Authorities" (root CAs). Now, consider one such company head-quartered in China, or the US. The governments of both countries have the power to secretly demand such a company's keys, then use them to make your client trust whichever endpoint they chose.
The security model is broken, just like BGP's is. Root CAs plainly can't be trusted. It's not just that they'll cooperate with governments. See "Security Collapse in the HTTPS Market".[0]
Why should I need to trust some vague certificate authority? I'd rather trust DANE/TLSA and DNSSEC. Or something similar.
Solving the trust problem in routing would require ISPs to manually whitelist which AS advertisements are valid on any given interconnect - you know something is wrong if Comcast advertises some Virgin Media network, or whatever.
Encryption by itself can't solve trust. It can only protect against MITM.
Looking back, it's doubtful that a secure version up front would have worked. Routers were pretty feeble back then, and getting them to verify crypto signatures for advertisements would have been a non-starter.
This is especially true since there are still many issues with the secure replacements when it comes to key distribution issues, manipulating path costs, etc. With all of the modern crypto we have now, it's still a non-trivial problem to solve.