Resetting the Internet?

I guess it was too good a story to get right. The press widely reported recently that security geek Paul Watson discovered a previously unknown way to cause catastrophic disruptions of the Internet with only a few seconds of effort. …

I guess it was too good a story to get right. The press widely reported recently that security geek Paul Watson discovered a previously unknown way to cause catastrophic disruptions of the Internet with only a few seconds of effort.

According to some reports, an attacker could bring down a peering connection between ISPs by sending as few as four packets. While the story was a good one, the reality turned out to be more mundane.

The furor started when the English National Infrastructure Security Co-ordination Centre published a Vulnerability Advisory describing how an attacker could terminate established TCP connections between two Internet hosts. The attack can be used against any longish-lived TCP sessions but the most interesting are those supporting the inter-ISP Border Gateway Protocol (BGP). If a BGP session gets terminated, all of the Internet destinations that one ISP had learned from another could become unreachable. If determined attackers went after the major ISPs, large chunks of the Internet could just disappear.

The basic problem had been known for a very long time. Under normal circumstances the host on one end of a TCP session sends the host on the other end a TCP packet containing a reset (called RST) flag when a session is to be terminated. An attacker could send the host at one end of a TCP session such a packet with the forged source address of the host at the other end, which would cause the first host to terminate the session. The original TCP specification limits the ease of this attack by requiring that the TCP packet containing the RST include a sequence number within a specific range, called a window.

Wilson figured out that guessing a sequence number within the window was a lot easier than previously thought. Under some widely unrealistic scenarios it could take as little as four guesses. Under more realistic scenarios, such as those present in BGP sessions between ISPs, it takes up to 260,000 guesses. Of course, some in the press used the four-guess number because it made a better story.

The attack and some quite easy ways to tweak TCP software to reduce the attack possibility to almost zero can be found in an IETF Internet-Draft published a few days before the Vulnerability Advisory was published.

Many vendors already have released software updates to deal with the issue. There are a number of network design and filtering methods to limit the possibility of an attacker being able to get packets to the ISP routers (see Cisco’s report). In addition, most routers used in ISPs have been able to support cryptographic protection on their BGP links for a number of years (see RFC 2385). Far too few ISPs have been using such protection even though the federal cybersecurity folks pushed heavily for it a few years ago.

By the time you read this many more ISPs will be using it.

This turned out not to be the Internet-killer bug and I don’t expect to see any easy-to-exploit way to take down the whole ‘Net. But it’s still a good idea to be paranoid in network design and be ready to react quickly to new exploitable vulnerabilities.

Disclaimer: Most people at Harvard are about as far from paranoid as one could be, so the above request for paranoia is mine and not the university’s.