Hijacking the Internet is trivial today
Update – Clarifying the China Internet hijacking incident
National Defense Magazine has a story about an incident in April of 2010 where China hijacked a significant portion of the Internet including many networks in the United States. One would think that such a significant incident would have garnered a lot more attention, but it has largely been ignored by the press because of the obscurity of the inner workings of the Internet. I’ll try to explain it in as simple terms as possible so bear with me.
The Internet uses Internet Protocol (IP) addresses to identify the location of networks and the machines that attach to them. These “IP addresses” are like phone numbers and when you want to communicate with another device over the Internet, you reach out to an IP address rather than a phone number had you been trying to reach a phone. To route traffic between these IP addresses, the Internet has a routing mechanism called Border Gate Protocol (BGP) that maps out the Internet and lets routers know where to send traffic.
The BGP mechanism is a fundamental building block of the Internet. Like most other fundamental building blocks of the Internet, it was initially implemented with no security in mind and it continues to live without security because changes on the Internet are so difficult on a living system that doesn’t tolerate outages. Here are examples of key Internet systems that started off insecure and largely remain insecure today.
- Border Gate Protocol (BGP) – The routing system of the Internet. There are proposals for secure versions of BGP but the fear is that routers on the Internet can’t handle the additional workload. But the rapidly growing number of networks is also putting a strain on the Internet routers so a world wide upgrade might handle both of these problems. Yet that’s so far off in the future that it’s difficult to imagine when it would be done.
- Domain Name System (DNS) – Gives human recognizable names lie “ebay.com” to an unfriendly IP addresses. The system is very exploitable and it will hopefully be replaced with a secure DNS protocol called DNSSEC soon (measured in several years on Internet scale). If DNS is hijacked, it’s as if someone edited the phone book and gave you bogus phone numbers for people you were trying to reach. This is different from a BGP route hijack in the sense that a route hijack doesn’t involve bogus phone numbers but actually hijacking the legitimate phone number.
- Simple Mail Transfer Protocol (SMTP) – The Internet’s system responsible for handling email is completely exploitable. Anyone can send email as anyone else because there is no verification mechanism for the “from” address. Secure updates like DKIM can address the problem, but it’s hard to get anyone to care about mail security.
- X.509 – The Certificate Authority (CA) and Public Key Infrastructure (PKI) standard of the Internet. X.509 is unfortunately corrupted to the core. X.509 can’t scale because its authority delegation system (called name constraints) was crippled from the start to give Certificate Authority companies the ability to operate a key signing racket, and these CA companies charge companies hundreds of dollars for a few milliseconds of compute power needed to sign a few bits. X.509 security is easily abused because anyone can become a CA for roughly $40,000 and create any certificate they want including North Korea. DNSSEC (also an upgrade to DNS) can also replace X.509 with a secure solution that scales.
The current BGP routing mechanism is based almost entirely on the “honor system” between large network operators. But we’ve had incidents where network operators in Pakistan hijacked all of YouTube for many hours because they didn’t like a single video clip on YouTube. Many other BGP diversion accidents occur every year but not on the scale of the April 2010 “accident” in China. That “accident” happens to have siphoned off 15% of the Internet but it was largely a massive outage that instantly stopped the flow of traffic for most hijacked routes. Some of the specific routes could have been patched through for data theft and the massive outage was merely a cover, but it’s difficult to know for sure what really happened.
US government officials claim that their traffic was encrypted so they have nothing to fear. The National Defense article alluded to the weakness of the PKI system but the US government doesn’t use the commercial PKI system for lack of trust reasons. That doesn’t help commercial entities because they do rely on the commercial PKI system for public commerce and that’s where an upgrade to the DNSSEC based PKI system would be immensely helpful.
It’s actually been covered by the technical press in depth. What we have works good ’nuff, hence nobody cares.
See: wired/register/etc articles on route hijacks, dnssec, etc. Also: renesys blog.
@Dave
“What we have works good ’nuff, hence nobody cares.”
What you mean is what we have today hasn’t been disrupted enough yet for people to care. That doesn’t mean the fundamental security problem doesn’t exist. If we went by that logic, then nothing should ever improve on the Internet.
Having an honor based routing system, PKI system, DNS system, and mail system is clearly too easy to exploit. That’s not “good ’nuff” and it’s just lazy and irresponsible to say that it is.
George, ask some of your big telecom clients what research/development they’ve contributed towards s[o]BGP, and when they expect to deploy it on their production networks. Or are they all in the wrong too, and should be caring more?
@Mike Hunt
1. I don’t have “telecom clients”.
2. We don’t really need more research on crypto and secure protocols because we already have them. We know how to do make secure protocols but the question is whether or not we can get the entire Internet to adopt a new secure routing protocol.
3. Why are you singling out the telecoms? The large companies (including the telecoms) are probably the least resistant to upgrading to a new protocol and new hardware simply because they can afford it. Furthermore, the big carrier routers can already handle the work of a secure BGP protocol. It’s the small companies with smaller minimum sized routers that might have a problem with secure BGP.
[...] [...]
Don’t you lobby for/get funding from AT&T, Comcast, and the like?
Why don’t they have these protocols deployed internally, and supported on customer-facing connections, if it’s really so easy and figured out? No third-party coordination required there.
@Dave,
We don’t lobby Dave and we’re forbidden by law under our 503(c)3 non profit status to lobby. We get our funding from Arts+Labs which gets some donations from Telecoms and other companies (I don’t think Comcast was one of them last time I checked).
These protocols (I’m assuming you’re referring to secure versions of BGP) don’t get deployed internally. BGP routing in general rarely get deployed internally if at all because it is an outward facing protocol. It’s not primarily a problem of the carriers supporting this because even if they did, and even if they manually blacklisted IP ranges from the US from being diverted to China or Pakistan, the businesses and organizations connecting to the Internet can still get poisoned routes. These end points and businesses won’t deploy a secure alternative because it’s not supported by the other end points on the Internet so it’s kind of a self fulfilling prophesy. What is needed is a global effort to fix this.
We have lots of examples where good protocols exist like SSL/TLS yet we can’t get Facebook and Twitter to use it to secure our authentication cookies. Another example is the more efficient and almost universally supported ECN congestion management protocol which has been ratified as an Internet standard for almost a decade, but we can’t enable it by default for the fear that a small percentage of consumer routers will freak out. The problem is that when we’re talking about an Internet with billions of devices, it’s like trying to turn a massive ship.
“These protocols (I’m assuming you’re referring to secure versions of BGP) don’t get deployed internally. BGP routing in general rarely get deployed internally if at all because it is an outward facing protocol. ”
Sounds like somebody needs to take a step back and read up before continuing in their argument. :-)
Also nothing prevents AT&T and the like from supporting soBGP as an optional knob on the customer edge today, other than a lack of caring.
@Jack Moves
“Also nothing prevents AT&T and the like from supporting soBGP as an optional knob on the customer edge today, other than a lack of caring.”
Only if you believe that AT&T is responsible for deploying SSL for Facebook and Twitter correctly when Facebook and Twitter clearly don’t. http://www.digitalsociety.org/2010/11/online-services-security-report-card/
The businesses and organizations own their own edge routers that run BGP and they’re responsible for managing those routers. They don’t depend on the carrier to manage BGP for them although they can pay them to do that. But you don’t want to hear that because you just want to get a quick cheap shot in on the carriers when it has nothing to do with this issue.
The problem isn’t the network carriers who could probably deploy a secure form of BGP today without upgrading any new hardware. The problem is that many of the businesses and organizations may have to upgrade to new routers (at their own expense) and that is where the resistance would come from.
@Jack Moves
“Sounds like somebody needs to take a step back and read up before continuing in their argument. :-)”
I’ve designed, built and run very large networks so you don’t need to lecture me on what I need to read up on. I can assure you that few companies deploy BGP internally even though many of them (with multiple Internet connections) run it on their Internet facing edge routers. Most of those companies run Cisco EIGRP routing or open standards routing protocol called OSPF internally. I’ve only had one situation where I deployed BGP internally, but security wasn’t an issue there because the network routes could be easily locked down and because the company controls all the participating BGP routers.
If you worked on a network with more than one or two full-table-carrying devices you’d understand the role of *i*BGP being run in conjunction with an IGP. (Sorry to make you consult Wikipedia on the term.)
Nothing prevents AT&T from deploying soBGP internally, or more importantly as an optional knob on is customer-facing edge, the latter of which would provide some degree of route validation even pending a wider and multi-provider deployment. But they won’t, because they don’t recognize the need, nor do they have an ability to innovate.
Also, don’t you think the claims that you’re “not a lobbyist” are at least a little bit offensive to, and misleading of, your readers? Okay, so you don’t technically go banging on doors on Capitol Hill. Rather, big telco pays your employer money, and you in turn write articles and publish research supporting of their positions. If you were to stop supporting their positions, chances are the donations would stop, and you’d all be out of a job.
How is it that we cannot simply point to any specific evidence to prove China’s connection to this IP hijacking incident? Surely, everything done online leaves a “footprint”, can’t we simply say “A-HA!” and point to a data cache somewhere or a IP reroute address and say there is the proof? China Telecom/China’s Govt. definitely seems hesitant to admit ANY wrong doing, and there must be “proof” in that pudding somewhere.
@Jack Moves
Seems like you didn’t read what I said. I said I have run internal BGP on rare occasions and that security on an internal network wasn’t that important because you control all your own routers. You don’t need to worry about someone in Pakistan or China Telecom inserting bogus routes. You keep trying to turn this into a carrier issue (specifically the telecoms) when it is not.
The reason one particular network ran BGP internally had nothing to do with the network’s size but the adoption of an MPLS WAN which broke the other routing protocols.
It also seems like you’re going to be hell bent on calling me something I’m not since you obviously can’t criticize any of the substance I’ve put forth. I’ve been writing the same opinions as a journalist for ZDNet since 2006 before I ever joined a think tank in 2008. We like any other think tank or nonprofit or academic take donations to fund our continued existence. The difference is that we fully disclose who our contributors are. You friends at Free Press don’t disclose the vast majority of their funding.
@Klatu Berata Nicto
We know for a fact that China Telecom poisoned 15% the routes on the Internet thereby breaking 15% of the Internet. That much is undeniable because everyone witnessed the route hijacking and it’s in the router logs.
What we don’t know is how much if any of those networks they intercepted. That’s the part that is scary.
What China Telecom is saying is that they didn’t hijack traffic. They didn’t deny the route hijacking.
It’s often desirable to run iBGP *and* and IGP (like OSPF, IS-IS, or on your case probably EIGRP) in concert, on full-table-speaking routers. This was a small component of my larger point though, nothing technical is stopping AT&T et al from deploying soBGP on customer connections today. This does not require widespread buy-in, it just requires a phone company committed to solving today’s problems today. I think we’ll see more adaptation among smaller, nimbler, “tier 2″ providers though, at least initially.
These updates actually wouldn’t be found in “router logs” necessarily.
Renesys has a good blog entry on what went down and how they verified it:
http://www.renesys.com/blog/2010/11/chinas-18-minute-mystery.shtml
Hi,
After reading your article, I thought, why so gloomy ?
First of all DNSSEC is not a replacement of DNS, it’s an enhancement.
Yes, their are problems, but atleast people are working on them.
For example DNSSEC can solve the problems with DNS (potentially it can add some as well, but everything has their downsides). DNSSEC is already deployed at the root and many of the TLD’s, even more will be added next year. For example .com and .net are planned to be ready next year. Which will mean that by then, most of the important TLD’s have been signed.
But DNSSEC can also help solve some of the problems with SSL/X.509, because you can put a DNSSEC-verified public key in DNS. So you can verifiy that the SSL-certificate of this domain has been verified by this CA, which means only those CA’s which are in DNS are trusted. This solves the many-CA’s problem, it could also solve the domain-verification-process-at-CA’s-is-just-a-joke-problem and self-signed-certificates-are-stupid-problem ( https://startssl.com/ already solves that, as it is just as free ! ).
I know it does not solve the ASN.1-is-a-stupid-protocol-problem, I guess we should start working on an extension for that (to use XML or something like that). First deploy it on the client, so the server can answer with the new format. And when all the old clients have been removed we can even change the initial requests to the server, if we want.
DNSSEC can also help solve the problems with SMTP, for example you can put a key in DNS which is used to verify your GPG-key that you used for signing. So that you know, something from Paypal, actually came from paypal.com. We already have domainkeys, which can now be verified by DNSSEC.
Some thought we could even use DNSSEC to solve the problems we have with BGP, but bootstrapping was just to much of a pain. When you can’t verify your routing, because you can’t do DNS, because you can’t do routing. Then you have a dependency and a big potential for a problem.
But people are working on cleaning up the RIR-databases (RIPE, ARIN, AFRINIC, LACNIC, APNIC) and the protocols are being worked on at this moment. Their is are I think 2 reference implementations which are being tested.
And I would like to add, you can’t deploy a BGP-protocol-origin-validation-extension internally only. Because it exists to verify what you get from the outside world. When the outside world hasn’t started deploying yet, you have nothing to verify.
This is the ‘current’ status:
http://www.nanog.org/meetings/nanog49/abstracts.php?pt=MTYxMyZuYW5vZzQ5&nm=nanog49
And:
http://rosie-arch.ncc.ripe.net/webcast/ripe-60/mp3/Randy%20Bush%20-%20The%20RPKI%20&%20Origin%20Validation.mp3
http://ripe.net/ripe/meetings/ripe-60/flash-video.php?day=Monday&pres=Randy%20Bush%20-%20The%20RPKI%20and%20Origin%20Validation.flv
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The_RPKI_Origin_Validation.pdf
http://www.ripe.net/ripe/meetings/ripe-60/steno-transcripts.php?steno=Main-100503-PM2
http://www.ripe.net/ripe/meetings/ripe-60/archives.php
Yes, I’m not very happy with all the choices, for example ASN.1 remains a problem, with all the solutions I mentioned.
But that doesn’t mean think aren’t improving.
I actually think, thinks are improving much faster then in the past. Take for example DNSSEC.
“nothing technical is stopping AT&T et al from deploying soBGP on customer connections today”
And that does nothing to solve or hinder a solution to the problem of the overall Internet routing system and you keep bringing up this irrelevant topic like a broken record.
It would actually be a good first step to preventing route hijacking by their customers. But you won’t see them doing it, because they’ve stopped innovating a while back.
@Jack Moves
“It would actually be a good first step to preventing route hijacking by their customers. But you won’t see them doing it, because they’ve stopped innovating a while back.”
Carriers already do this today by only allowing their customers to advertise routes for IP networks they own/control. They’re doing that today via simple BGP route filtering. They can do this without a secure BGP protocol.
@Lennie
“And I would like to add, you can’t deploy a BGP-protocol-origin-validation-extension internally only. Because it exists to verify what you get from the outside world. When the outside world hasn’t started deploying yet, you have nothing to verify.”
Thank you for setting Jack Moves straight.
Today I can announce any prefix I want, so long as a) I register it in a routing registry (see RADB) as belonging to me or b) I open up a ticket with my upstream transit provider asking that they allow it. More often than not, providers do NOT, in fact, practice any prefix filtering. RPKI/soBGP speaks to the issue of validating *origin*.
George’s lack of knowledge on interdomain routing is pretty staggering, and he’s really doing a disservice to the cause. He’d be well served to stick to what he knows: end user operating systems and PC troubleshooting.
Jack said it right. It’s easy to CLAIM a prefix belongs to you, or have a lax provider not practicing any prefix filtering, and thus announce it. RPKI/soBGP prevents that by helping to verify ownership of a route.
And yes, you’re not going to find AT&T or any large ISP as the first to support technologies like this on the edge. Bellheads are incapable of moving quickly. You’re going to see the tier 2s of the world supporting this first, and over time, slowly demanding that their transit providers (the tier 2s) get with the show.
*the tier 1s
Leave your response!
Twitter Feed
About Us
Digital Society is a digital think tank that believes culture and commerce are inseparable, that the digital economy flourishes when people are free and rights are secure, and that free markets free people.
Digital Society is an independent 501(c)3 non-profit organization, funded by donations from Jon Henke and from Arts+Labs. We advocate for a pro-culture, pro-commerce digital society through research, analysis and debate on emerging technology issues.
Reply Comments
Transparency and interactivity are trademarks of the Internet era, and we aim to foster them here at Digital Society. It is inevitable that some people will disagree with the technology policy positions we take. We want to have that constructive debate.
The Reply Comments feature gives our critics a chance to respond to our viewpoints and the Digital Society audience convenient access to competing arguments. Any time we directly challenge the views of an individual or a group on this site, the party in question may substantively respond in a guest post.
Please contact executive director Jon Henke by e-mail.
Subscribe
Daily Digest Email
Recent Posts
Recent Posts
Most Commented
Most Viewed