The following text is copyright 2004 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.
Resetting the Internet?
By Scott Bradner
I guess it was too good a story to get right. It was widely reported in the press that security geek Paul Watson had 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 the peering connection between Internet service providers (ISPs) by sending as few as 4 packets. While the story was a good one the reality turned out to be a lot more mundane.
The furor started when the English National Infrastructure Security Co-ordination Centre published a "Vulnerability Advisory" that described how an attacker could terminate established TCP connections between two Internet hosts. (http://www.uniras.gov.uk/vuls/2004/236929/index.htm) The attack can be used against any longish-lived TCP sessions but the most interesting long-lived TCP sessions are those supporting the inter-ISP BGP routing protocol. If a BGP session gets terminated all of the Internet destinations that one ISP had learned from another ISP 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 of the session a TCP packet containing a reset (called RST) flag on when a TCP 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 other end of a TCP session. This would cause the first host to terminate the TCP session. The original TCP specification does limit the ease of this attack by requiring that the TCP packet containing the RST to include a sequence number within a specific range (called a "window"). Wilson figured out that guessing a sequence number that would be within the window was a lot easier than previously thought. Under some widely unrealistic scenarios it could take as little as 4 guesses to hit upon a sequence number within the window. 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 4-guesses number because it made a better story. The attack and some quite easy ways to tweak the 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. (http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt) Many vendors have already released software updates to deal with the issue.
There are a number of network design and filtering ways to limit the possibility of an attacker being able to get packets to the ISP routers. (See Cisco's report http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml) In addition, most routers used in ISPs have been able to support the use cryptographic protection on their BGP links for a number of years. (See RFC 2385 http://www.ietf.org/rfc/rfc2385.txt) Far too few ISPs have been using such protection even though its use was pushed heavily a few years ago by the federal cybersecurity folks. By the time you read this many more will be.
This turned out to not be the Internet-killer bug and I do not 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.