Quick fix for an early Internet problem lives on a quarter-century later | Hacker News Reader

Quick fix for an early Internet problem lives on a quarter-century later

washingtonpost.com

77 pointsRockyMcNuts18 comments

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.

Yup. By definition, your BGP neighbors are:

- not controlled by you

- tell you about their own view of the Internet

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

http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...

and

https://web.eecs.umich.edu/~zmao/eecs589/papers/draft-white-...

provide more detail on this.

In which Richard Clarke alerted John Chambers, who said he had never heard of BGP.

This is of course a serious problem. But I'm surprised that there's no mention of end-to-end encryption as a defense against misrouting.

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.

Right, "mitigate" is what I ought to have written.

And yes, HTTPS is rather a joke. But what about properly implemented SSH, IPSec or OpenVPN?

Why is HTTPS "rather a joke"? Genuinely curious...

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.

That's still considerably better than sending unencrypted HTTP over the wire in pretty much every way.

Better, but not good enough.

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]

[0] http://queue.acm.org/detail.cfm?id=2673311

If you can't trust your cert authorities, you are already rather fucked, routing errors or no.

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.

This is a good presentation on the development of BGP by Yakov Rekhter [0]:

https://www.youtube.com/watch?v=_Mn4kKVBdaM BGP at 18: Lessons In Protocol Design

[0] https://en.wikipedia.org/wiki/Yakov_Rekhter

This article has the most polite comments I've ever seen on the Washington Post website.

Reply on news.ycombinator.com