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