Plumbers of the interwebs vow to kill IP hijacking
Task force to send 'Rover' out to wild web galaxy
Agentless Backup is Not a Myth
The Internet Engineering Task Force (IETF) aims to strengthen the basic protocols of the internet, with a way to stop route, or IP, hijacking. IETF experts say the proposed fix is simpler to implement than previous suggestions.
IP hijacking exploits a fundamental weakness of the internet, Data and messages sent across the internet are transmitted via routers, and those routers are blindly trusted. No measures are in place to verify if they have been tampered with to re-direct or intercept traffic.
In 2008, Pakistan Telecom took advantage of this blind trust to send YouTube briefly into a global blackhole. CNET's Declan McCullagh wrote at the time:
By accident or design, the company broadcast instructions worldwide claiming to be the legitimate destination for anyone trying to reach YouTube's range of Internet addresses.
The security weakness lies in why those false instructions, which took YouTube offline for two hours on Sunday, were believed by routers around the globe. That's because Hong Kong-based PCCW, which provides the Internet link to Pakistan Telecom, did not stop the misleading broadcast - which is what most large providers in the United States and Europe do.
Traffic mismanagement
The same fundamental weakness in BGP (Border Gateway Protocol), a core routing protocol that maps preferred paths for traffic to flow over the internet, was used to hijack the network at the Defcon hacker conference in Las Vegas in 2008. Everything looked the same to delegates after the hijack, but all unencrypted traffic sent over the network was open to wiretapping.
In 2010, China Telecom rerouted up to 15 per cent of the world's internet destinations on two brief occasions, using false BGP route information to direct traffic through its own networks.
The hijackings sparked a security scare in the US. Even without the China dimension, America's dismay is understandable:
The [April 8] hijacking, which lasted 18 minutes, affected email and web traffic traveling to and from .gov and .mil domains, including those for the US Senate, four branches of the military, the office of the secretary of defense, and NASA, among other US governmental agencies, according to the report. It also affected traffic for large businesses, including Dell, IBM, Microsoft and Yahoo.
Similar tricks might be used to steal corporate communications, without leaving a trace or even, at least theoretically, making entire countries unreachable via IP communications. BGP has no built-in security. Routers might accept bogus routes from peers, internet exchanges or transit suppliers. Dodgy routers, however accepted, can have local, regional or global effects.
"Someone can advertise your address space and a route to get there and routers don't know any better," explained Joe Gersch of Secure64, a Domain Name System vendor. "They are just looking for the shortest path."
"It doesn't necessarily have to be malicious for something to go wrong. It could be accidental. Admins could type something wrong into router and this information would still propagate."
The issue has been known for about 10 years but previous attempts to find a fix floundered because proposed solutions were too complex or too expensive, Gersch says. More recently, governments have taken greater interest in the issue, increasing the pressure to find a fix.
Look it up
At an IETF meeting in Paris last month, a working group proposed a solution that seeks to safeguard the integrity of networking kit.
The proposal involves publishing preferred routes to sites in DNS records before applying a second step, using utilities to verify that the instructions are trustworthy.
This latter step would use DNSSEC, or DNS Security Extensions, a separate security mechanism which is gradually rolling out as a defence against cache-poisoning attacks.
The whole scheme is called ROVER, or BGP Route Origin Verification (via DNS).
Rover calls for the use of reverse DNS records to periodically publish route announcements, a process that would be done by sites themselves, before carrying out real-time verifications of BGP route announcements.
Rover uses "best effort" data retrieval with worldwide data distribution, redundancy and local caching. If the data is unreachable, the default is that routing would proceed as normal but without any checks.
Gersch said the working group (the Secure Inter-domain Routing Group, of which he is a member) believes the proposed approach has the potential to succeed because of its simplicity, in contrast with other ideas such as BGPSec or RPKI.
"Rover is a simpler method to publish your authoritative data," Gersch explained. "I own it, and you can look it up. The process can be automated."
Gersch described Rover as an "enabling technology". Preliminary discussions have already been held with members of Cisco's secure networking group on how to interface the technology with routers.
Several early adopter telcos and ISPs are in the process of publishing route origins in their reverse DNS and signing with DNSSEC. In addition, Secure64 has established a Rover Testbed available at "rover.secure64.com" (registration required).
Deployment of Rover is simple, as no changes need be made to existing routers, IOS or policies, according to backers of the technology. The system builds on DNSSEC, which firms ought to be deploying anyway – although in practice roll-out have been slow.
The Secure Inter-domain Routing Group at the IETF has worked on alternatives to Rover such as BGPSec and RPKI for at least six years.
"Rover uses something that's already there, DNSSEC crypto keys, rather than having to build out a new system," Gersch explained.
"All the ideas for preventing IP hijacking are proceeding forward. The systems can co-exist but I still expect there will be a fierce debate over which is best," he added. ®
COMMENTS
ROVER
Orange Alert! Orange Alert!
(Large white weather balloon bounces across the interwebs...)
Not sure this would make that much of a difference
I've seen said CN hijack, from the point of view of a engineer on call. They don't happen that often, but I suppose it's a road bump on the way to insanity for some people. The issue with the solution is that for the really big issues, we are relying on the network (in the form of DNS and VA's) to secure...the network, which has the odd flaw. The other way of looking at the issue is to make the point that since diverting Youtube your way will probably fill your pipes instantly anyway, hijacks are usually going to be smaller rather than larger.
I'm more convinced by a solution that holds Tier1 transit providers to account. Jitter analysis of AS latency from test points, as well as route update frequency available from RIPE and others could be used to update BGP damping.
>"BGP has no built-in security."
That's an over-simplification to the point where it's verging on falsehood. You try opening a BGP connection from your home or office (i.e. ISP end-user) computer to any random router out there on the internet; it won't accept anything from you.
BGP routers are configured by the network admins to know who their peers are and only accept updates from them, and most of them use shared-secret MD5-based signatures as a form of (admittedly weak) authentication. Faking a BGP update would require both knowing the particular shared secret for a particular peer-peer link *and* blind IP spoofing as one of the peers; it's only valid authorised peers who can inject (whether by accident or design) bad data into the BGP routing tables.
It would be a bit more accurate to say that BGP has no data validation rather than no security at all, as the problems arise when someone emits routing updates for routes they don't have the right to originate. This becomes a particular problem as some enterprise-level ISPs sell a service where the customer can supply their own BGP router and originate routes from it; the ISPs should be filtering these routes rather than blindly passing them on, but that's still basically a data validation/GIGO issue.

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud