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.