RE: Revealed: The Internet's well known BGP behavior
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living. 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where. 3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops. 4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack. And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch. John (ISDN) Lee :) ________________________________________ From: Frank [fsmendoza@gmail.com] Sent: Wednesday, August 27, 2008 8:47 PM To: NANOG list Subject: Revealed: The Internet's Biggest Security Hole http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed<http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html>a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. "It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail." The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel<http://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html>) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data <http://www.5ninesdata.com/>, and Alex Pilosov, CEO of Pilosoft <http://www.pilosoft.com/>, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. "We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working." The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic. Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic. The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one. To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network. The attack is called an IP hijack and, on its face, isn't new. But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertently<http://news.bbc.co.uk/1/hi/technology/7262071.stm>hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss. Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs. Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients. "Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?" Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago. Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data. A handful of academic groups <http://www.routeviews.org/> collect BGP routing information <http://bgpmon.netsec.colostate.edu/index.html> from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400." Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said. "Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive." Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors. Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it. Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so. The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop. For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop. "That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said. The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers. Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP. "We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did." ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it." "The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said.
On Aug 27, 2008, at 11:07 PM, John Lee wrote:
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?)
2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where.
No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops.
3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops.
The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought?
4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack.
Would that network operators were so diligent.
And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch.
Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point. Why use ISDN (ATM) when you can do something useful? -- TTFN, patrick
Patrick, VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen. Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited. John (ISDN) Lee ________________________________________ From: Patrick W. Gilmore [patrick@ianai.net] Sent: Wednesday, August 27, 2008 11:18 PM To: NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Aug 27, 2008, at 11:07 PM, John Lee wrote:
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?)
2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where.
No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops.
3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops.
The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought?
4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack.
Would that network operators were so diligent.
And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch.
Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point. Why use ISDN (ATM) when you can do something useful? -- TTFN, patrick
On Wed, Aug 27, 2008, John Lee wrote:
Patrick,
VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen.
Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited.
No, traceroute shows the hops which returned "time to live exceeded." This only maps to "the hops the packet has transited" if the TTL is setup and decremented correctly. Adrian
Adrian, The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing. When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list. John (ISDN) Lee ________________________________________ From: Adrian Chadd [adrian@creative.net.au] Sent: Wednesday, August 27, 2008 11:32 PM To: John Lee Cc: Patrick W. Gilmore; NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Wed, Aug 27, 2008, John Lee wrote:
Patrick,
VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen.
Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited.
No, traceroute shows the hops which returned "time to live exceeded." This only maps to "the hops the packet has transited" if the TTL is setup and decremented correctly. Adrian
On Aug 27, 2008, at 11:47 PM, John Lee wrote:
The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing.
You are very confused how traceroute works. Being confused is fine. Lots of people are confused & ignorant. In fact, everyone is ignorant about more things than they are educated about. However, when people like Adrian, who are clearly more versed in the technology than you are, try to educate you, ignoring his kind help and repeating your confusion to 10s of 1000s of your not-so-close friends is not fine. Please read Adrian's post again, read about traceroute, and try not to post until you have understood them. (To be clear, if you come to the conclusion you are right and Adrian is wrong it means you have _not_ understood them.)
When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list.
The fact you do not understand how traceroute works makes it obvious why you misunderstand how to diagnosis something from that lack of understanding.
VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen.
"VPNs" do no such thing. To prove this to yourself, realize that IPsec and SSL are both types of "VPNs". Encrypting the data is very useful. Hell, Anthony & Alex say so themselves. But that wasn't the point of the presentation. (And we'll ignore the fact that the size, speed, and even existence of a data stream - encrypted or not - might be useful information to a miscreant.) Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r. -- TTFN, patrick
Thanks guys, going back to my Comer one more time. My issue, question was whether the organization doing the hijacking controlled all of the routers in the new modified path or only some of them? John (ISDN) Lee ________________________________________ From: Patrick W. Gilmore [patrick@ianai.net] Sent: Thursday, August 28, 2008 12:10 AM To: NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Aug 27, 2008, at 11:47 PM, John Lee wrote:
The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing.
You are very confused how traceroute works. Being confused is fine. Lots of people are confused & ignorant. In fact, everyone is ignorant about more things than they are educated about. However, when people like Adrian, who are clearly more versed in the technology than you are, try to educate you, ignoring his kind help and repeating your confusion to 10s of 1000s of your not-so-close friends is not fine. Please read Adrian's post again, read about traceroute, and try not to post until you have understood them. (To be clear, if you come to the conclusion you are right and Adrian is wrong it means you have _not_ understood them.)
When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list.
The fact you do not understand how traceroute works makes it obvious why you misunderstand how to diagnosis something from that lack of understanding.
VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen.
"VPNs" do no such thing. To prove this to yourself, realize that IPsec and SSL are both types of "VPNs". Encrypting the data is very useful. Hell, Anthony & Alex say so themselves. But that wasn't the point of the presentation. (And we'll ignore the fact that the size, speed, and even existence of a data stream - encrypted or not - might be useful information to a miscreant.) Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r. -- TTFN, patrick
On Aug 28, 2008, at 12:32 AM, John Lee wrote:
Thanks guys, going back to my Comer one more time. My issue, question was whether the organization doing the hijacking controlled all of the routers in the new modified path or only some of them?
That is correct. However, once a packet hits the miscreant's device, the traceroute is defeated. Assuming their device is in the right place, you will not be able to see the difference. Assuming it is in the "wrong" place, you may be able to detect the intrusion. But most people do not run traceroutes all day and watch for it to change. If you run the traceroute after the attack starts, well, how are you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02-$BLAH-$BAR is right? -- TTFN, patrick
On Thu, Aug 28, 2008 at 1:22 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
Assuming it is in the "wrong" place, you may be able to detect the intrusion. But most people do not run traceroutes all day and watch for it to change. If you run the traceroute after the attack starts, well, how are you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02-$BLAH-$BAR is right?
Uhhh... network monitoring with traceroute and topology tools. There are several off-the-shelf varieties to choose from, and I know of several providers that use them. -Jim P.
On Aug 28, 2008, at 1:40 AM, Jim Popovitch wrote:
On Thu, Aug 28, 2008 at 1:22 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
Assuming it is in the "wrong" place, you may be able to detect the intrusion. But most people do not run traceroutes all day and watch for it to change. If you run the traceroute after the attack starts, well, how are you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02- $BLAH-$BAR is right?
Uhhh... network monitoring with traceroute and topology tools. There are several off-the-shelf varieties to choose from, and I know of several providers that use them.
I stand by my assertion that most people do not run traceroutes all day and watch for it to change. That some people are diligent does not change the fact the overwhelming majority of people are not. Or the fact that with the right placement of equipment (read "luck") and cooperation of networks involved (read "laziness"), even a traceroute won't show any change besides additional latency. -- TTFN, patrick
I stand by my assertion that most people do not run traceroutes all day and watch for it to change.
That some people are diligent does not change the fact the overwhelming majority of people are not.
Or the fact that with the right placement of equipment (read "luck") and cooperation of networks involved (read "laziness"), even a traceroute won't show any change besides additional latency.
Bingo! Latency is the magic word and that *IS* measured by a lot more people than do traceroutes. Unless the attackers are lucky enough or smart enough to do their dirty work from a server that is reasonably closely colocated to the router that they exploit, you *WILL* see latency changes. It would be wise to change the process for investigating latency increases to include examining routers for this BGP rerouting exploit. --Michael Dillon
Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r.
Just some quick googling found this <http://www.xchangemag.com/hotnews/64h27164418.html> from back in 2006. "Sprint has expanded its global MPLS network capabilities with network-to-network interface (NNI) partnerships and has introduced the industry's first standard end-to-end MPLS VPN SLA as part of its global network."
John Lee wrote:
Adrian,
The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing.
But if I can control your traffic I could change everything, couldn't I? I mean, with the ability to inject whatever I wanted, I could spoof traceroute, yes? I could filter for that traffic and return whatever I wanted. I could manufacture a series of packets showing that NYC and London were only 10ms apart in such a case. --Patrick
On Wed, 27 Aug 2008, Patrick W. Gilmore wrote:
On Aug 27, 2008, at 11:07 PM, John Lee wrote:
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?)
People (especially spammers) have been hijacking networks for a while now, maybe now that we have a presentation to whore around, operators can pressure vendors and bosses. Gadi.
2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where.
No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops.
3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops.
The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought?
4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack.
Would that network operators were so diligent.
And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch.
Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point.
Why use ISDN (ATM) when you can do something useful?
-- TTFN, patrick
Most of the spammer acquired /16s have been 1. pre arin 2. caused by buying up assets of long defunct companies .. assets that just happen to include a /16 nobody knew about Not exactly hijacks this lot .. just like those "barely legal" teen mags. srs On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while now, maybe now that we have a presentation to whore around, operators can pressure vendors and bosses.
On Aug 28, 2008, at 6:25 AM, Suresh Ramasubramanian wrote:
Most of the spammer acquired /16s have been
1. pre arin
2. caused by buying up assets of long defunct companies .. assets that just happen to include a /16 nobody knew about
Not exactly hijacks this lot .. just like those "barely legal" teen mags.
There have been tons of spam runs I have seen from "hijacked" blocks were simply announcing an unused block or a de-agg of a used block, sending spam for a few minutes / hours / days, and stopping the announcement. This does not require special techniques, just an upstream willing to accept & propagate your announcement. Alex & Anthony's preso is about intercepting legit traffic, not sending illegitimate traffic. -- TTFN, patrick
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while now, maybe now that we have a presentation to whore around, operators can pressure vendors and bosses.
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet.
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while
I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes. We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target. That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential. Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting. -Tk
On Thu, 28 Aug 2008 10:16:16 -0500 "Anton Kapela" <tkapela@gmail.com> wrote:
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet.
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while
I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes.
We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target.
That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential.
Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting.
Indeed, and I thank you for it. As noted, I and others have been warning about the problem for a long time. You've shown that it isn't just an ivory tower exercise; maybe people will now get serious about deploying a solution. To quote Bruce Schneier quoting an NSA maxim, attacks only get better; they never get worse. We now have running code of one way to do this. I think most NANOG readers can see many more ways to do it. A real solution will take years to deploy, but it will never happen if we don't start. And we want to have the solution out there *before* we see serious attacks on BGP. Again, thank you -- it was really nice work. --Steve Bellovin, http://www.cs.columbia.edu/~smb
To quote Bruce Schneier quoting an NSA maxim, attacks only get better; they never get worse. We now have running code of one way to do this. I think most NANOG readers can see many more ways to do it. A real solution will take years to deploy, but it will never happen if we don't start. And we want to have the solution out there *before* we see serious attacks on BGP.
Again, thank you -- it was really nice work.
Seems like we *could* get a large part of the way there if people were only checking the information in question. While not the long-term fix of being able to prove authorization to advertise space, simply requiring a LOA at the edge, and requiring IRR further in, and keeping records of what was advertised, would seem to be a worthwhile improvement on the current state of affairs. Total prevention is a very rough goal, so making it more difficult, combined with being able to identify when someone did something bad, really ought to be a worthwhile interim goal, and I've wondered for a long time why this isn't being done. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Steven M. Bellovin wrote:
On Thu, 28 Aug 2008 10:16:16 -0500 "Anton Kapela" <tkapela@gmail.com> wrote:
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet.
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes.
We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target.
That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential.
Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting.
Indeed, and I thank you for it. As noted, I and others have been warning about the problem for a long time. You've shown that it isn't just an ivory tower exercise; maybe people will now get serious about deploying a solution.
To quote Bruce Schneier quoting an NSA maxim, attacks only get better; they never get worse. We now have running code of one way to do this. I think most NANOG readers can see many more ways to do it. A real solution will take years to deploy, but it will never happen if we don't start. And we want to have the solution out there *before* we see serious attacks on BGP.
Again, thank you -- it was really nice work.
<aol>
Thank you for making your presentation. Gadi. On Thu, 28 Aug 2008, Anton Kapela wrote:
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet.
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while
I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes.
We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target.
That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential.
Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting.
-Tk
I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet.
On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron <ge@linuxbox.org> wrote:
People (especially spammers) have been hijacking networks for a while
I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes.
We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target.
That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential.
Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting. Yep. While it was common knowledge that it is "easy" to jack space, it was really considered in terms of "denial of service" attack. It was known
On Thu, 28 Aug 2008, Anton Kapela wrote: that you could do traffic monitoring via manipulation of BGP communities and reinjecting traffic "closer" to the target via tunnels - however that technique is not generic. We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt I'd also like to draw attention that it didn't draw much attention when Tony has posted immediately after the conference to the nanog-list, which has an extensive reading list - and I highly recommend that before further posting on this, you read through it. http://www.gossamer-threads.com/lists/nanog/users/107423 Added attention to the issue after our public demonstration is good news - more attention to the problem is likely to get people do use best practices in filtering. I'd also like to point out that while presentation went over a lot of people's heads at defcon, it appears that unexpectedly, it did went over people's heads here as well. To clear up some misunderstandings: *) Yes, this is a real problem. *) Yes, it has been known for years. *) There is no currently deployable solution to this problem yet. *) Filtering your customers using IRR is a requirement, however, it is not a solution - in fact, in the demonstration, we registered the /24 prefix we hijacked in IRR. RIRs need to integrate the allocation data with their IRR data. -alex [your former moderator]
*) Filtering your customers using IRR is a requirement, however, it is not a solution - in fact, in the demonstration, we registered the /24 prefix we hijacked in IRR. RIRs need to integrate the allocation data with their IRR data.
further clarification... [if this is obvious, just skip over the message]. IRR filters helps prevent *accidental* hijacking and *accidental* route spillage. In that, they seem to do their job. I don't know why people think that would help prevent a deliberate hijacking job. I don't think there is enough "trust" in the IP allocation system from the RIRs yet (trust anchors being the word of the week) to even contemplate non-repudiation in advertisements yet. We can go into lots of reasons why the Internet runs this way. I think we can all agree 1) Its amazing it runs as well as it does, and 2) No one has clearly articulated a financial reason for any large organizations to significantly change their interconnection methodologies over the current BCP [that exceeds the costs of doing so]. Until either of those assertions change, the status quo will essentially remain. Alex et al, I apologize if you already covered this in your preso... One way to help mitigate the effects of this [as a user] is to keep all of your conversation end points on the same network -- especially if you run a VPN or similar -- and [rather than scan your traceroutes daily as someone suggested] scan the IRRs daily to make sure no changes have been entered for prefixes you care about. Just some thoughts, Deepak Jain
On Aug 28, 2008, at 3:47 PM, Deepak Jain wrote:
We can go into lots of reasons why the Internet runs this way. I think we can all agree 1) Its amazing it runs as well as it does, and 2) No one has clearly articulated a financial reason for any large organizations to significantly change their interconnection methodologies over the current BCP [that exceeds the costs of doing so].
Until either of those assertions change, the status quo will essentially remain.
Well, there's also been a bit of a chicken and egg problem here - as no formally verifiable authoritative source for who is authorized to originate what IP address space has ever existed, and until that happens, you can't secure the routing system. Fortunately, the RPKI work will address this, and some of the RIRs are working on RPKI implementations now. If there are ways the IRRs can be populated using this information and non-RPKI derived updates can be considered less preferable (whatever that means), then we can get to a better place with the IRRs as a stop gap until a secure routing protocol can actually be deployed. However, without that as a stepping stone, it's an awfully large leap from RPKI directly into a secure inter-domain routing protocol. -danny
* Alex Pilosov:
We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt
The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering.
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad. -jim On Fri, Aug 29, 2008 at 6:58 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
* Alex Pilosov:
We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt
The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering.
On Fri, Aug 29, 2008, jim deleskie wrote:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed." Adrian
I'm afraid of the answer to that question On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <adrian@creative.net.au> wrote:
On Fri, Aug 29, 2008, jim deleskie wrote:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed."
Adrian
On Aug 29, 2008, at 22:41, "jim deleskie" <deleskie@gmail.com> wrote:
I'm afraid of the answer to that question
No you are not, since you already know the answer. -- TTFN, patrick
On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <adrian@creative.net.au> wrote:
On Fri, Aug 29, 2008, jim deleskie wrote:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed."
Adrian
True but I can still believe in a warm and fuzzy internet if I try really hard.... Then my cell phone rings and back to the real world. -jim On Sat, Aug 30, 2008 at 12:01 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 29, 2008, at 22:41, "jim deleskie" <deleskie@gmail.com> wrote:
I'm afraid of the answer to that question
No you are not, since you already know the answer.
-- TTFN, patrick
On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <adrian@creative.net.au> wrote:
On Fri, Aug 29, 2008, jim deleskie wrote:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed."
Adrian
everyone seems to have their saying ....from leting you wonder on what is the problem to making assumptions to witty technical explanations and useless question rephrased. For some reading this some are just non-technical individuals posting messages. All can be done ..we all know the BGP selection path algoritm and its extentions ...maybe a costing exercice to some that rather have interface X down for a while or reroute traffic through a different path Is the problem still occuring? Who's being affected? PS: going back to the drawing board is also an interesting approach if this is geting too complex ...:-) --- On Sat, 8/30/08, Patrick W. Gilmore <patrick@ianai.net> wrote:
From: Patrick W. Gilmore <patrick@ianai.net> Subject: Re: Revealed: The Internet's well known BGP behavior To: "nanog@nanog.org" <nanog@nanog.org> Date: Saturday, August 30, 2008, 5:01 AM On Aug 29, 2008, at 22:41, "jim deleskie" <deleskie@gmail.com> wrote:
I'm afraid of the answer to that question
No you are not, since you already know the answer.
-- TTFN, patrick
On Fri, Aug 29, 2008, jim deleskie wrote:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
The question shouldn't really be "would
On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd <adrian@creative.net.au> wrote: people do this to others'
traffic"; the question should be "has it already happened and noone noticed."
Adrian
* jim deleskie:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
No, the idea would be to do this to your own prefixes/traffic. +------/AS 2/-----/AS 3/--------+ | | /AS 1/ /AS 4/ | | +----------/AS 5/---------------+ I'm AS 1, and the link to AS 2 has a bad metric from my POV. AS 4 uses local preference (or something else I can't override by prepending my own AS) to route traffic to me through AS 3 and AS 2. Now I prepend AS 4 to my announcement to AS 2, and voilà, the traffic flows through AS 5, as desired. No prefix hijacking has occurred (I would have received the traffic anyway, just over a different path), it's just traffic engineering. (But probably a variant that is generally frowned upon.)
The biggest issue with using a heavy hammer to effect traffic is that you don't always know why the other side is routing the way they are. Could be simple cost (peer vs transit) or a larger issue like congestion. Either way think before you route. I'm thinking Pandora's box hasn't just been opened but blown apart..... -jim On Sat, Aug 30, 2008 at 2:55 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
* jim deleskie:
Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad.
No, the idea would be to do this to your own prefixes/traffic.
+------/AS 2/-----/AS 3/--------+ | | /AS 1/ /AS 4/ | | +----------/AS 5/---------------+
I'm AS 1, and the link to AS 2 has a bad metric from my POV. AS 4 uses local preference (or something else I can't override by prepending my own AS) to route traffic to me through AS 3 and AS 2. Now I prepend AS 4 to my announcement to AS 2, and voilà, the traffic flows through AS 5, as desired.
No prefix hijacking has occurred (I would have received the traffic anyway, just over a different path), it's just traffic engineering. (But probably a variant that is generally frowned upon.)
On 30/08/2008, at 9:58 AM, Florian Weimer wrote:
* Alex Pilosov:
We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt
The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering.
The technique of path stuffing ASes who you do not want to receive an announcement is called AS PATH poisoning. It's a fairly well known trick. -- Nathan Ward
On 30/08/2008, at 9:58 AM, Florian Weimer wrote:
* Alex Pilosov:
We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt
The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering.
The technique of path stuffing ASes who you do not want to receive an announcement is called AS PATH poisoning. It's a fairly well known trick.
Not exactly specifically in reply to your note, but more generally: In the old days, Usenet spammers would sometimes preload the Path: line with names of NNTP transits that they might want to avoid for various reasons (usually the home sites of Usenet spam cancellers). In most ways, avoiding offering an article back to a server because it was already listed in the Path: was merely an optimization, to avoid extra traffic on a futile offer. However, simply removing the exclusion allowed the sending site to attempt the transmission, which would then succeed if the receiving site had not seen the article (etc). For purposes of detection, then, it seems reasonable to consider that there could be some way to leverage BGP to monitor for this sort of thing. There would seem to be at least two very interesting things that you could monitor for, which would be irregularities in the ASPATH, and irregularities in your announced prefixes. Since major networks would need to be involved for significant traffic redirection events, I'm wondering if it would be reasonable to have a looking glass/route server type service that would peer with a bunch of them, based on random 32-bit ASN's assigned from a preallocated range for the purpose, one per network (think: reducing effectiveness of AS PATH stuffing). You could then provide a configurable notification service, or for sites with the technical capabilities, a realtime BGP feed of all events involving their AS or prefixes (again over a randomly assigned 32-bit ASN, and obviously to some off-net IP where they run a monitoring box, so that a prefix hijack is ineffective). Such a service would seem like it would be generally useful for other purposes as well. There's almost certainly some fatal flaw in this idea, or maybe better yet, some obvious improvements that could be made, so for the BGP gurus out there, what are they? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
what do mpls, ipsec tunnels, ssl have anything to do with someone announcing your address space and hijacking youre prefixes?? i think we all know this is not new.. and these guys didnt claim it to be.. they're not presenting this to a 'xNOG' crowd, defcon has a different type of audience..im not saying they dont know about this kind of insecurity, but it is nice to see this material being presented, and exposing it to different 'groups' especially with a live demo... christian On Wed, Aug 27, 2008 at 11:07 PM, John Lee <john@internetassociatesllc.com> wrote:
1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living.
2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where.
3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops.
4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack.
And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch.
John (ISDN) Lee :)
________________________________________ From: Frank [fsmendoza@gmail.com] Sent: Wednesday, August 27, 2008 8:47 PM To: NANOG list Subject: Revealed: The Internet's Biggest Security Hole
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html
Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency.
The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination.
The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed<http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html>a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness.
"It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail."
The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network.
Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel<http://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html>) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another.
The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs.
BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data <http://www.5ninesdata.com/>, and Alex Pilosov, CEO of Pilosoft <http://www.pilosoft.com/>, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas.
The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works.
"We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working."
The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic.
Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic.
The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one.
To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network.
The attack is called an IP hijack and, on its face, isn't new.
But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertently<http://news.bbc.co.uk/1/hi/technology/7262071.stm>hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss.
Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs.
Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients.
"Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?"
Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago.
Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data.
A handful of academic groups <http://www.routeviews.org/> collect BGP routing information <http://bgpmon.netsec.colostate.edu/index.html> from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400."
Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said.
"Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive."
Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors.
Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it.
Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so.
The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop.
For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop.
"That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said.
The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers.
Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP.
"We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did."
ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it."
"The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said.
participants (20)
-
Adrian Chadd -
Alex Pilosov -
Anton Kapela -
Christian Koch -
Danny McPherson -
Deepak Jain -
Florian Weimer -
Gadi Evron -
isabel dias -
jim deleskie -
Jim Popovitch -
Joe Greco -
John Lee -
michael.dillon＠bt.com -
Nathan Ward -
Patrick Giagnocavo -
Patrick W. Gilmore -
Randy Bush -
Steven M. Bellovin -
Suresh Ramasubramanian