draft-ietf-tcpm-tcp-antispoof-01.txt   draft-ietf-tcpm-tcp-antispoof-02.txt 
IETF TCPM WG J. Touch IETF TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Expires: October 2005 April 26, 2005 Expires: April 2006 October 8, 2005
Defending TCP Against Spoofing Attacks Defending TCP Against Spoofing Attacks
draft-ietf-tcpm-tcp-antispoof-01.txt draft-ietf-tcpm-tcp-antispoof-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 26, 2005. This Internet-Draft will expire on April 8, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
Recent analysis of potential attacks on core Internet infrastructure Recent analysis of potential attacks on core Internet infrastructure
indicates an increased vulnerability of TCP connections to spurious indicates an increased vulnerability of TCP connections to spurious
resets (RSTs), sent with forged IP source addresses (spoofing). TCP resets (RSTs), sent with forged IP source addresses (spoofing). TCP
skipping to change at page 2, line 14 skipping to change at page 2, line 14
TCP endpoint and port numbers. For pairs of well-known endpoints TCP endpoint and port numbers. For pairs of well-known endpoints
often over predictable port pairs, such as BGP or between web servers often over predictable port pairs, such as BGP or between web servers
and well-known large-scale caches, increases in the path bandwidth- and well-known large-scale caches, increases in the path bandwidth-
delay product of a connection have sufficiently increased the receive delay product of a connection have sufficiently increased the receive
window space that off-path third parties can guess a viable RST window space that off-path third parties can guess a viable RST
sequence number. The susceptibility to attack increases as the square sequence number. The susceptibility to attack increases as the square
of the bandwidth, thus presents a significant vulnerability for of the bandwidth, thus presents a significant vulnerability for
recent high-speed networks. This document addresses this recent high-speed networks. This document addresses this
vulnerability, discussing proposed solutions at the transport level vulnerability, discussing proposed solutions at the transport level
and their inherent challenges, as well as existing network level and their inherent challenges, as well as existing network level
solutions and the feasibility of their deployment. solutions and the feasibility of their deployment. This document
focuses on vulnerabilities due to spoofed TCP segments, and includes
a discussion of related ICMP spoofing attacks on TCP connections.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Background.....................................................4 2. Background.....................................................4
2.1. Recent BGP Attacks Using TCP RSTs.........................4 2.1. Review of TCP Windows.....................................5
2.2. TCP RST Vulnerability.....................................5 2.2. Recent BGP Attacks Using TCP RSTs.........................5
2.3. What Changed -- the Ever Opening Receiver Window..........6 2.3. TCP RST Vulnerability.....................................6
3. Proposed solutions.............................................8 2.4. What Changed - the Ever Opening Advertised Receive Window.7
3.1. Transport Layer Solutions.................................8 3. Proposed Solutions and Mitigations.............................9
3.1.1. TCP MD5 Authentication...............................9 3.1. Transport Layer Solutions................................10
3.1.2. TCP RST Window Attenuation...........................9 3.1.1. TCP MD5 Authentication..............................10
3.1.3. TCP Timestamp Authentication........................10 3.1.2. TCP RST Window Attenuation..........................10
3.1.4. Other TCP Cookies...................................10 3.1.3. TCP Timestamp Authentication........................11
3.1.5. Other TCP Considerations............................11 3.1.4. Other TCP Cookies...................................12
3.1.6. Other Transport Protocol Solutions..................11 3.1.5. Other TCP Considerations............................12
3.2. Network Layer (IP) Solutions.............................12 3.1.6. Other Transport Protocol Solutions..................13
3.2.1. Ingress filtering...................................12 3.2. Network Layer (IP) Solutions.............................13
3.2.2. IPsec...............................................13 3.2.1. Address filtering...................................13
4. Issues........................................................13 3.2.2. IPsec...............................................14
4.1. Transport Layer (e.g., TCP)..............................13 4. ICMP..........................................................15
4.2. Network Layer (IP).......................................14 5. Issues........................................................16
4.3. Application Layer........................................15 5.1. Transport Layer (e.g., TCP)..............................16
4.4. Shim Transport/Application Layer.........................16 5.2. Network Layer (IP).......................................17
4.5. Link Layer...............................................16 5.3. Application Layer........................................18
4.6. Issues Discussion........................................16 5.4. Shim Transport/Application Layer.........................19
5. Security Considerations.......................................17 5.5. Link Layer...............................................19
6. Conclusions...................................................17 5.6. Issues Discussion........................................19
7. Acknowledgments...............................................17 6. Security Considerations.......................................20
8. References....................................................18 7. IANA Considerations...........................................20
8.1. Normative References.....................................18 8. Conclusions...................................................20
8.2. Informative References...................................18 9. Acknowledgments...............................................21
Author's Addresses...............................................21 10. References...................................................21
Intellectual Property Statement..................................21 10.1. Normative References....................................21
Disclaimer of Validity...........................................21 10.2. Informative References..................................21
Copyright Statement..............................................22 Author's Addresses...............................................24
Acknowledgment...................................................22 Intellectual Property Statement..................................24
Disclaimer of Validity...........................................25
Copyright Statement..............................................25
Acknowledgment...................................................25
1. Introduction 1. Introduction
Analysis of the Internet infrastructure has been recently Analysis of the Internet infrastructure has been recently
demonstrated new version of a vulnerability in BGP connections demonstrated new version of a vulnerability in BGP connections
between core routers using an attack known for nearly six years between core routers using an attack known for nearly six years
[6][7][15][35]. These connections, typically using TCP, can be [8][9][18][40]. These connections, typically using TCP, can be
susceptible to off-path (non man-in-the-middle) third-party reset susceptible to off-path third-party reset (RST) segments with forged
(RST) segments with forged source addresses (spoofed), which source addresses (spoofed), which terminate the TCP connection. BGP
terminate the TCP connection. BGP routers react to a terminated TCP routers react to a terminated TCP connection in various ways which
connection in various ways which can amplify the impact of an attack, can amplify the impact of an attack, ranging from restarting the
ranging from restarting the connection to deciding that the other connection to deciding that the other router is unreachable and thus
router is unreachable and thus flushing the BGP routes [29]. This flushing the BGP routes [32]. This sort of attack affects other
sort of attack affects other protocols besides BGP, involving any protocols besides BGP, involving any long-lived connection between
long-lived connection between well-known endpoints. The impact on well-known endpoints. The impact on Internet infrastructure can be
Internet infrastructure can be substantial (esp. for the BGP case), substantial (esp. for the BGP case), and warrants immediate
and warrants immediate attention. attention.
TCP, like many other protocols, can be susceptible to these off-path TCP, like many other protocols, can be susceptible to these off-path
third-party spoofing attacks. Such attacks rely on the increase of third-party spoofing attacks. Such attacks rely on the increase of
commodity platforms supporting public access to previously privileged commodity platforms supporting public access to previously privileged
resources, such as root-level access. Given such access, it is resources, such as root-level access. Given such access, it is
trivial for anyone to generate a packet with any header desired. trivial for anyone to generate a packet with any header desired.
This, coupled with the lack of sufficient ingress filtering to drop This, coupled with the lack of sufficient address filtering to drop
such spoofed traffic, can increase the potential for off-path third- such spoofed traffic, can increase the potential for off-path third-
party spoofing attacks. Proposed solutions include the deployment of party spoofing attacks. Proposed solutions include the deployment of
existing Internet network and transport security as well as existing Internet network and transport security as well as
modifications to transport protocols that reduce its vulnerability to modifications to transport protocols that reduce its vulnerability to
generated attacks. generated attacks.
One way to defeat spoofing is to validate the segments of a One way to defeat spoofing is to validate the segments of a
connection, either at the transport level or the network level. TCP connection, either at the transport level or the network level. TCP
with MD5 extensions provides this authentication at the transport with MD5 extensions provides this authentication at the transport
level, and IPsec provides authentication at the network level. In level, and IPsec provides authentication at the network level. In
skipping to change at page 4, line 9 skipping to change at page 4, line 12
numbers of peers (for IPsec using IKE), or shared secrets (for IPsec numbers of peers (for IPsec using IKE), or shared secrets (for IPsec
in shared-secret mode, or TCP/MD5), because many clients may need to in shared-secret mode, or TCP/MD5), because many clients may need to
be configured rapidly without external assistance. Services from be configured rapidly without external assistance. Services from
public web servers connecting to large-scale caches to BGP with public web servers connecting to large-scale caches to BGP with
larger numbers of peers can experience this challenge. larger numbers of peers can experience this challenge.
The remainder of this document outlines the recent attack scenario in The remainder of this document outlines the recent attack scenario in
detail and describes and compares a variety of solutions, including detail and describes and compares a variety of solutions, including
existing solutions based on TCP/MD5 and IPsec, as well as recently existing solutions based on TCP/MD5 and IPsec, as well as recently
proposed solutions, including modifications to TCP's RST processing proposed solutions, including modifications to TCP's RST processing
[8], modifications to TCP's timestamp processing [27], and [10], modifications to TCP's timestamp processing [30], and
modifications to IPsec and TCP/MD5 keying [34]. modifications to IPsec and TCP/MD5 keying [38]. This document focuses
on spoofing of TCP segments, although a discussion of related
spoofing of ICMP packets based on spoofed TCP contents is also
discussed.
Note that the description of these attacks is not new; attacks using Note that the description of these attacks is not new; attacks using
RSTs on BGP have been known since 1998, and were the reason for the RSTs on BGP have been known since 1998, and were the reason for the
development of TCP/MD5 [15]. The recent attack scenario was first development of TCP/MD5 [18]. The recent attack scenario was first
documented by Convery at a NANOG meeting in 2003, but that analysis documented by Convery at a NANOG meeting in 2003, but that analysis
assumed the entire sequence space (2^32 packets) needed to be covered assumed the entire sequence space (2^32 packets) needed to be covered
for an attack to succeed [7]. Watson's more detailed analysis for an attack to succeed [9]. Watson's more detailed analysis
discovered that a single packet anywhere in the current window could discovered that a single packet anywhere in the current window could
succeed at an attack [35]. This document adds the observation that succeed at an attack [40]. This document adds the observation that
susceptibility to attack goes as the square of bandwidth, due to the susceptibility to attack goes as the square of bandwidth, due to the
coupling between the linear decrease in window size and linear coupling between the linear increase in receive window size and
increase in rate an attacker, as well as comparing the variety of linear increase in rate an attacker, as well as comparing the variety
more recent proposals, including modifications to TCP, use of IPsec, of more recent proposals, including modifications to TCP, use of
and use of TCP/MD5 to resist such attacks. IPsec, and use of TCP/MD5 to resist such attacks.
2. Background 2. Background
The recent analysis of potential attacks on BGP has again raised the The recent analysis of potential attacks on BGP has again raised the
issue of TCP's vulnerability to off-path third-party spoofing attacks issue of TCP's vulnerability to off-path third-party spoofing attacks
[6][7][35]. A variety of such attacks have been known for several [8][9][40]. A variety of such attacks have been known for several
years, including sending RSTs, SYNs, and even ACKs in an attempt to years, including sending RSTs, SYNs, and even ACKs in an attempt to
affect an existing connection or to load down servers. Overall, such affect an existing connection or to load down servers. Overall, such
attacks are countered by the use of some form of authentication at attacks are countered by the use of some form of authentication at
the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or
other layers. TCP already includes a weak form of such other layers. TCP already includes a weak form of such
authentication in its check of segment sequence numbers against the authentication in its check of segment sequence numbers against the
current receiver window. Increases in the bandwidth-delay product current receiver window. Increases in the bandwidth-delay product
for certain long connections have sufficiently weakened this type of for certain long connections have sufficiently weakened this type of
weak authentication in recent weeks, rendering it moot. weak authentication in recent weeks, rendering it moot.
2.1. Recent BGP Attacks Using TCP RSTs 2.1. Review of TCP Windows
Before proceeding, it is useful to review the terminology and
components of TCP's windowing algorithm. TCP connections have three
kinds of windows [1][31]:
o Send window (SND.WND): the latest advertised send window size.
o Receive window (RCV.WND): the latest advertised receive window
size.
o Congestion window (CWND): the window determined by congestion
feedback that limits how much of RCV.WND can be in-flight in a
round trip time.
For most modern TCP connections, SND.WND and RCV.WND are the size of
the corresponding send and receive socket buffers, and are
configurable using socket buffer resizing commands.
CWND determines how much data can be in transit in a round trip time,
SND.WND determines how much data the sender is willing to store on
its side for possible retransmission due to loss, and RCV.WND
determines the ability of the receiver to accommodate that loss and
reorder received packets. CWND never grows beyond RCV.WND.
High bandwidth-delay product networks need CWND to be sufficiently
large to accommodate as much data would be in transit in a round trip
time, otherwise their performance will suffer. As a result, it is
recommended that users and various automatic programs increase
RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay
product) [19][33].
As the bandwidth-delay product of the network increases, however,
such increases in the advertised receive window can cause increased
susceptibility to spoofing attacks, as the remainder of this document
shows. This assumes, however, that the receive window size (e.g., via
increased receive socket buffer configuration) is increased with the
increased bandwidth-delay product; if not, then connection
performance will degrade, but susceptibility to spoofing attacks will
increase only linearly (with the rate of the attacker to send spoofed
packets), not as the square of the bandwidth.
2.2. Recent BGP Attacks Using TCP RSTs
BGP represents a particular vulnerability to spoofing attacks because BGP represents a particular vulnerability to spoofing attacks because
it uses TCP connectivity to infer routability, so losing a TCP it uses TCP connectivity to infer routability, so losing a TCP
connection with a BGP peer can result in the flushing of routes to connection with a BGP peer can result in the flushing of routes to
that peer [29]. that peer [32].
Until six years ago, such connections were assumed difficult to Until six years ago, such connections were assumed difficult to
attack because they were described by a few comparatively obscure attack because they were described by a few comparatively obscure
parameters [15]. Most TCP connections are protected by multiple parameters [18]. Most TCP connections are protected by multiple
levels of obfuscation except at the endpoints of the connection: levels of obfuscation except at the endpoints of the connection:
o Both endpoint addresses are usually not well-known; although server o Both endpoint addresses are usually not well-known; although server
addresses are advertised, clients are somewhat anonymous. addresses are advertised, clients are somewhat anonymous.
o Both port numbers are usually not well-known; the server's usually o Both port numbers are usually not well-known; the server's usually
is advertised (representing the service), but the client's is is advertised (representing the service), but the client's is
typically sufficiently unpredictable to an off-path third-party. typically sufficiently unpredictable to an off-path third-party.
o Valid sequence number space is not well-known. o Valid sequence number space is not well-known.
o Connections are relatively short-lived and valid sequence space o Connections are relatively short-lived and valid sequence space
changes, so any guess of the above information is unlikely to be changes, so any guess of the above information is unlikely to be
useful. useful.
BGP represents an exception to the above criteria (though not the BGP represents an exception to the above criteria (though not the
only case). Both endpoints are well-known, notably as part of an AS only case). Both endpoints can be well-known, using hints from part
path. The destination port is typically fixed to indicate the BGP of an AS path. The destination port is typically fixed to indicate
service. The source port used by a BGP router is sometimes fixed and the BGP service. The source port used by a BGP router is sometimes
advertised to enable firewall configuration; even when not fixed, fixed and advertised to enable firewall configuration; even when not
there are only 65,384 valid source ports which may be exhaustively fixed, there are only 65,384 valid source ports which may be
attacked. Connections are long-lived, and as noted before some BGP exhaustively attacked. Connections are long-lived, and as noted
implementations interpret successive TCP connection failures as before some BGP implementations interpret successive TCP connection
routing failures, discarding the corresponding routing information. failures as routing failures, discarding the corresponding routing
As importantly and as will be shown below, the valid sequence number information. As importantly and as will be shown below, the valid
space once thought to provide some protection has been rendered sequence number space once thought to provide some protection has
useless by increasing advertised receive window sizes. been rendered useless by increasing advertised receive window sizes.
2.2. TCP RST Vulnerability 2.3. TCP RST Vulnerability
TCP has a known vulnerability to third-party spoofed segments. SYN TCP has a known vulnerability to third-party spoofed segments. SYN
flooding consumes server resources in half-open connections, flooding consumes server resources in half-open connections,
affecting the server's ability to open new connections. ACK spoofing affecting the server's ability to open new connections. ACK spoofing
can cause connections to transmit too much data too quickly, creating can cause connections to transmit too much data too quickly, creating
network congestion and segment loss, causing connections to slow to a network congestion and segment loss, causing connections to slow to a
crawl. In the most recent attacks on BGP, RSTs cause connections to crawl. In the most recent attacks on BGP, RSTs cause connections to
be dropped. As noted earlier, some BGP implementations interpret TCP be dropped. As noted earlier, some BGP implementations interpret TCP
connection termination, or a series of such failures, as a network connection termination, or a series of such failures, as a network
failure [29]. This causes routers to drop the BGP routing failure [32]. This causes routers to drop the BGP routing
information already exchanged, in addition to inhibiting their information already exchanged, in addition to inhibiting their
ongoing exchanges, thus amplifying the impact of the attack. The ongoing exchanges, thus amplifying the impact of the attack. The
result can affect routing paths throughout the Internet. result can affect routing paths throughout the Internet.
The dangerous effects of RSTs on TCP have been known for many years, The dangerous effects of RSTs on TCP have been known for many years,
even when used by the legitimate endpoints of a connection. TCP RSTs even when used by the legitimate endpoints of a connection. TCP RSTs
cause the receiver to drop all connection state; because the source cause the receiver to drop all connection state; because the source
is not required to maintain a TIME_WAIT state, such a RST can cause is not required to maintain a TIME_WAIT state, such a RST can cause
premature reuse of address/port pairs, potentially allowing segments premature reuse of address/port pairs, potentially allowing segments
from a previous connection to contaminate the data of a new from a previous connection to contaminate the data of a new
connection, known as TIME_WAIT assassination [5]. In this case, connection, known as TIME_WAIT assassination [7]. In this case,
assassination occurs inadvertently as the result of duplicate assassination occurs inadvertently as the result of duplicate
segments from a legitimate source, and can be avoided by blocking RST segments from a legitimate source, and can be avoided by blocking RST
processing while in TIME_WAIT. However, assassination can be useful processing while in TIME_WAIT. However, assassination can be useful
to deliberately reduce the state held at servers; this requires that to deliberately reduce the state held at servers; this requires that
the source of the RSTs go into TIME_WAIT state to avoid such hazards, the source of the RSTs go into TIME_WAIT state to avoid such hazards,
and that RSTs are not blocked in the TIME_WAIT state [9]. and that RSTs are not blocked in the TIME_WAIT state [11].
Firewalls and load balancers, so-called 'middleboxes', sometimes emit Firewalls and load balancers, so-called 'middleboxes', sometimes emit
RSTs on behalf of transited connections to optimize server RSTs on behalf of transited connections to optimize server
performance [11]. This is effectively a 'man in the middle' RST performance [13]. This is effectively an on-path RST attack in which
attack in which the RSTs are sent for benign or beneficial intent. the RSTs are sent for benign or beneficial intent. There are
There are numerous hazards with such use of RSTs, outlined in that numerous hazards with such use of RSTs, outlined in that RFC.
RFC.
2.3. What Changed -- the Ever Opening Receiver Window 2.4. What Changed - the Ever Opening Advertised Receive Window
RSTs represent a hazard to TCP, especially when completely unchecked. RSTs represent a hazard to TCP, especially when completely unchecked.
Fortunately, there are a number of obfuscation mechanisms that make Fortunately, there are a number of obfuscation mechanisms that make
it difficult for off-path third parties to forge (spoof) valid RSTs, it difficult for off-path third parties to forge (spoof) valid RSTs,
as noted earlier. We have already shown it is easy to learn both as noted earlier. We have already shown it is easy to learn both
endpoint addresses and ports for some protocols, notably BGP. The endpoint addresses and ports for some protocols, notably BGP. The
final obfuscation is the segment sequence number. final obfuscation is the segment sequence number.
TCP segments include a sequence number which enables out-of-order TCP segments include a sequence number which enables out-of-order
receiver processing as well as duplicate detection. The sequence receiver processing as well as duplicate detection. The sequence
skipping to change at page 6, line 41 skipping to change at page 7, line 49
index of the next byte to be transmitted or received. For RSTs, this index of the next byte to be transmitted or received. For RSTs, this
is relevant because legitimate RSTs use the next sequence number in is relevant because legitimate RSTs use the next sequence number in
the transmitter window, and the receiver checks that incoming RSTs the transmitter window, and the receiver checks that incoming RSTs
have a sequence number in the expected receive window. Such have a sequence number in the expected receive window. Such
processing is intended to eliminate duplicate segments (somewhat moot processing is intended to eliminate duplicate segments (somewhat moot
for RSTs, though), and to drop RSTs which were part of previous for RSTs, though), and to drop RSTs which were part of previous
connections. connections.
TCP uses two window mechanisms, a primary mechanism which uses a TCP uses two window mechanisms, a primary mechanism which uses a
space of 32 bits, and a secondary mechanism which scales this window space of 32 bits, and a secondary mechanism which scales this window
[28][16]. The valid advertised receive window is a fraction, not to [19][31]. The valid advertised receive window is a fraction, not to
exceed approximately half, of this space, or ~2,000,000,000. Under exceed approximately half, of this space, or ~2 billion (2E9, i.e.,
typical use, the majority of TCP connections open to a very small U.S. billion). Under typical configurations, the majority of TCP
fraction of this space, e.g., 10,000-60,000(approximately 5-100 connections open to a very small fraction of this space, e.g.,
segments). On a low-loss path, the advertised receive window should 10,000-60,000(approximately 5-100 segments). This is because the
open to around the path bandwidth-delay product, including buffering advertised receive window typically matches the receive socket buffer
delays (assume 1 packet/hop). Many paths in the Internet have end- size. It is recommended that this buffer be tuned to match the needs
to-end bandwidths of under 1 Mbps, latencies under 100ms, and are of the connection, either manually or by automatic external means
under 15 hops, resulting in fairly small windows as above (under [33].
35,000 bytes). Under these conditions, and further assuming that the
initial sequence number is suitably (pseudo-randomly) chosen, a valid On a low-loss path, the advertised receive window should be
guessed sequence number would have odds of 1 in 57,000 of falling configured to match the path bandwidth-delay product, including
within the advertised receive window. Put differently, a blind (non buffering delays (assume 1 packet/hop) [33]. Many paths in the
man-in-the-middle) attacker would need to send 57,000 RSTs with Internet have end-to-end bandwidths of under 1 Mbps, latencies under
suitably spaced sequence number guesses to successfully reset a 100ms, and are under 15 hops, resulting in fairly small advertised
connection. At 1 Mbps, 57,000 (40 byte) RSTs would take over 50 receive windows as above (under 35,000 bytes). Under these
minutes to transmit, and, as noted earlier, most current connections conditions, and further assuming that the initial sequence number is
are fairly brief by comparison. suitably (pseudo-randomly) chosen, a valid guessed sequence number
would have odds of 1 in 57,000 of falling within the advertised
receive window. Put differently, a blind (i.e., off-path) attacker
would need to send 57,000 RSTs with suitably spaced sequence number
guesses to successfully reset a connection. At 1 Mbps, 57,000 (40
byte) RSTs would take over 50 minutes to transmit, and, as noted
earlier, most current connections are fairly brief by comparison.
Recent use of high bandwidth paths of 10 Gbps and higher result in Recent use of high bandwidth paths of 10 Gbps and higher result in
bandwidth-delay products over 125 MB - approximately 1/10 of TCP's bandwidth-delay products over 125 MB - approximately 1/10 of TCP's
overall maximum advertised receive window size excluding scale, overall maximum advertised receive window size (i.e., assuming the
assuming the receiver allocates sufficient buffering (to be discussed receive socket buffers are increased as much as possible) excluding
later). Even under networks that are ten times slower (1 Gbps), the scale, assuming the receiver allocates sufficient buffering (as
active advertised receiver window covers 1/100th of the overall discussed in Sec. 2. ). Even under networks that are ten times
window size. At these speeds, it takes only 10-100 packets, or under slower (1 Gbps), the active advertised receive window covers 1/100th
32 microseconds, to correctly guess a valid sequence number and kill of the overall window size. At these speeds, it takes only 10-100
a connection. A table of corresponding exposure to various amounts packets, or less than 32 microseconds, to correctly guess a valid
of RSTs is shown below, for various line rates, assuming the more sequence number and kill a connection. A table of corresponding
conventional 100ms latencies (though even 100ms is large for BGP exposure to various amounts of RSTs is shown below, for various line
cases): rates, assuming the more conventional 100ms latencies (though even
100ms is large for BGP cases):
BW BW*delay RSTs needed Time needed BW BW*delay RSTs needed Time needed
------------------------------------------------------------ ------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond) 10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us 1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond) 100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second 10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes 1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours 100 Kbps 0.00125 MB 3,435,974 3 hours
skipping to change at page 7, line 36 skipping to change at page 9, line 4
BW BW*delay RSTs needed Time needed BW BW*delay RSTs needed Time needed
------------------------------------------------------------ ------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond) 10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us 1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond) 100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second 10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes 1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours 100 Kbps 0.00125 MB 3,435,974 3 hours
Figure 1 Time needed to kill a connection Figure 1 Time needed to kill a connection
This table demonstrates that the effect of bandwidth on the This table demonstrates that the effect of bandwidth on the
vulnerability is squared; for every increase in bandwidth, there is a vulnerability is squared; for every increase in bandwidth, there is a
linear decrease in the number of sequence number guesses needed, as linear decrease in the number of sequence number guesses needed, as
well as a linear decrease in the time needed to send a set of well as a linear decrease in the time needed to send a set of
guesses. Notably, as inter-router link bandwidths approach 1 Mbps, guesses. Notably, as inter-router link bandwidths approach 1 Mbps,
an 'exhaustive' attack becomes practical. Checking that the RST an 'exhaustive' attack becomes practical. Checking that the RST
sequence number is somewhere in the valid window (bw*delay) out of sequence number is somewhere in the advertised receive window out of
the overall advertised receive window (2^32) is an insufficient the overall maximum receive window (2^32) is an insufficient
obfuscation. obfuscation.
Note that this table makes a number of assumptions: Note that this table makes a number of assumptions:
1. the overall bandwidth-delay product is relatively fixed 1. the overall bandwidth-delay product is relatively fixed
2. traffic losses are negligible (insufficient to affect the 2. traffic losses are negligible (insufficient to affect the
congestion window over the duration of most of the connection) congestion window over the duration of most of the connection)
3. the receive socket buffers do not limiting the receive window 3. the advertised receive window is a large fraction of the overall
maximum receive window size, e.g., because the receive socket
buffers are set to match a large bandwidth-delay product
4. the attack bandwidth is similar to the end-to-end path bandwidth 4. the attack bandwidth is similar to the end-to-end path bandwidth
Of these assumptions, the last two are more notable. The issue of Of these assumptions, the last two are more notable. The issue of
receive socket buffers will be addressed later. The issue of the receive socket buffers was discussed in Sec. 2. The issue of the
attack bandwidth is considered reasonable as follows: attack bandwidth is considered reasonable as follows:
1. RSTs are substantially easier to send than data; they can be 1. RSTs are substantially easier to send than data; they can be
precomputed and they are smaller than data packets (40 bytes). precomputed and they are smaller than data packets (40 bytes).
2. although susceptible connections use somewhat less ubiquitous 2. although susceptible connections use somewhat less ubiquitous
high-bandwidth paths, the attack may be distributed, at which high-bandwidth paths, the attack may be distributed, at which
point only the ingress link of the attack is the primary point only the ingress link of the attack is the primary
limitation limitation
3. for the purposes of the above table, we assume that the ingress at 3. for the purposes of the above table, we assume that the ingress at
the attack has the same bandwidth as the path, as an approximation the attack has the same bandwidth as the path, as an approximation
The previous sections discussed the nature of the recent attacks on The previous sections discussed the nature of the recent attacks on
BGP due to the vulnerability of TCP to RST spoofing attacks, due BGP due to the vulnerability of TCP to RST spoofing attacks, due
largely to recent increases in the fraction of the TCP advertised largely to recent increases in the fraction of the TCP advertised
receive window space in use for a single, long-lived connection. receive window space in use for a single, long-lived connection.
3. Proposed solutions 3. Proposed Solutions and Mitigations
TCP currently authenticates received RSTs using the address and port TCP currently authenticates received RSTs using the address and port
pair numbers, and checks that the sequence number is inside the valid pair numbers, and checks that the sequence number is inside the valid
receiver window. The previous section demonstrated how TCP has receiver window. The previous section demonstrated how TCP has
become more vulnerable to RST spoofing attacks due to the increases become more vulnerable to RST spoofing attacks due to the increases
in the receive window size. There are a number of current and in the receive window size. There are a number of current and
proposed solutions to this vulnerability, all attempting to increase proposed solutions to this vulnerability, all attempting to provide
the authentication of received RSTs. evidence that a received RST is legitimate.
3.1. Transport Layer Solutions 3.1. Transport Layer Solutions
The transport layer represents the last place that segments can be The transport layer represents the last place that segments can be
authenticated before they affect connection management. TCP has a authenticated before they affect connection management. TCP has a
variety of current and proposed mechanisms to increase the variety of current and proposed mechanisms to increase the
authentication of segments, protecting against both off-path third- authentication of segments, protecting against both off-path and on-
party spoofs and man-in-the-middle attacks. SCTP also has mechanisms path third-party spoofing attacks. SCTP also has mechanisms to
to authenticate segments. authenticate segments.
3.1.1. TCP MD5 Authentication 3.1.1. TCP MD5 Authentication
An extension to TCP supporting MD5 authentication was developed An extension to TCP supporting MD5 authentication was developed in
around six years ago specifically to authenticate BGP connections 1998 specifically to authenticate BGP connections (although it can be
(although it can be used for any TCP connection) [15]. The extension used for any TCP connection) [18]. The extension relies on a pre-
relies on a pre-shared secret key to authenticate the entire TCP shared secret key to authenticate the entire TCP segment, including
segment, including the data, TCP header, and TCP pseudo-header the data, TCP header, and TCP pseudo-header (certain fields of the IP
(certain fields of the IP header). All segments are protected, header). All segments are protected, including RSTs, to be accepted
including RSTs, to be accepted only when their signature matches. only when their signature matches. This option, although widely
This option, although widely deployed in Internet routers, is deployed in Internet routers, is considered undeployable for
considered undeployable for widespread use because the need for pre- widespread use because the need for pre-shared keys [3][27]. It
shared keys [2][24]. It further is considered computationally further is considered computationally expensive for either hosts or
expensive for either hosts or routers due to the overhead of MD5 routers due to the overhead of MD5 [36][37].
[32][33].
3.1.2. TCP RST Window Attenuation 3.1.2. TCP RST Window Attenuation
A recent proposal extends TCP to further constrain received RST to A recent proposal extends TCP to further constrain received RST to
match the expected next sequence number [8]. This restores TCP's match the expected next sequence number [10]. This restores TCP's
resistance to spurious RSTs, effectively limiting the receive window resistance to spurious RSTs, effectively limiting the receive window
for RSTs to a single number. As a result, an attacker would need to for RSTs to a single number. As a result, an attacker would need to
send 2^32 different packets to correctly guess the sequence number. send 2^32 different packets to correctly guess the sequence number.
The extension further modifies the RST receiver to react to The extension further modifies the RST receiver to react to
incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST
source is legitimate, upon receipt of an ACK the closed source would source is legitimate, upon receipt of an ACK the closed source would
presumably emit a RST with the sequence number matching the ACK, presumably emit a RST with the sequence number matching the ACK,
correctly resetting the intended recipient. This modification adds correctly resetting the intended recipient. This modification
arcs to the TCP state diagram, adding to its complexity and thus changes TCP's control processing, adding to its complexity and thus
potentially affecting its correctness (in contrast to adding MD5 potentially affecting its correctness (in contrast to adding MD5
signatures, which is orthogonal to the state machine altogether). signatures, which is orthogonal to TCP control processing
For example, there may be complications between RSTs of different altogether). For example, there may be complications between RSTs of
connections between the same pair of endpoints because RSTs flush the different connections between the same pair of endpoints because RSTs
TIME-WAIT (as mentioned earlier). Further, this modifies TCP so that flush the TIME-WAIT (as mentioned earlier). Further, this proposal
under some circumstances a RST causes a reply, in violation of modifies TCP so that under some circumstances a RST causes a reply
generally accepted practice, if not gentle recommendation. The (an ACK), in violation of generally accepted practice, if not gentle
advantage to this proposal is that it can be deployed incrementally recommendation - although this can be omitted, allowing timeouts to
and has benefit to the endpoint on which it is deployed. suffice. The advantage to this proposal is that it can be deployed
incrementally and has benefit to the endpoint on which it is
deployed.
A variant of this proposal uses a different value to attenuate the A variant of this proposal uses a different value to attenuate the
window of viable RSTs. It requires RSTs to carry the initial window of viable RSTs. It requires RSTs to carry the initial
sequence number rather than the next expected sequence number, i.e., sequence number rather than the next expected sequence number, i.e.,
the value negotiated on connection establishment [31]. This proposal the value negotiated on connection establishment [35][41]. This
has the advantage of using an explicitly negotiated value, but at the proposal has the advantage of using an explicitly negotiated value,
cost of changing the behavior of an unmodified endpoint to a but at the cost of changing the behavior of an unmodified endpoint to
currently valid RST. It would thus be more difficult, without a currently valid RST. It would thus be more difficult, without
additional mechanism, to deploy incrementally. additional mechanism, to deploy incrementally.
The most obvious other variant of this proposal involves increasing Another variant of this proposal involves increasing TCP's window
TCP's window space, rather than decreasing the valid range for RSTs, space, rather than decreasing the valid range for RSTs, i.e.,
i.e., increasing the sequence space from 32 bits to 64 bits. This increasing the sequence space from 32 bits to 64 bits. This has the
has the equivalent effect - the ratio of the valid sequence numbers equivalent effect - the ratio of the valid sequence numbers for any
for any segment to the overall sequence number space is significantly segment to the overall sequence number space is significantly
reduced. The use of the larger space, as with current schemes to reduced. The use of the larger space, as with current schemes to
establish weak authentication using initial sequence numbers (ISNs), establish weak authentication using initial sequence numbers (ISNs),
is contingent on using suitably random values for the ISN. Such is contingent on using suitably random values for the ISN. Such
randomness adds additional complexity to TCP both in specification randomness adds additional complexity to TCP both in specification
and implementation, and provides only very weak authentication. Such and implementation, and provides only very weak authentication. Such
a modification is not obviously backward compatible, and would be a modification is not obviously backward compatible, and would be
thus difficult to deploy. thus difficult to deploy.
A converse variant of increasing TCP's window space is to decrease
the receive window, which would further reduce the effectiveness of
spoofed RSTs with random sequence numbers. This alternative may
reduce the throughput of the connection, if the advertised receive
window is smaller than the bandwidth-delay product of the connection.
3.1.3. TCP Timestamp Authentication 3.1.3. TCP Timestamp Authentication
Another way to authenticate TCP segments is to utilize its timestamp Another way to authenticate TCP segments is to utilize its timestamp
option, using the value as a sort of authentication [27]. This option, using the value as a sort of authentication [30]. This
requires that the receiver TCP discard values whose timestamp is requires that the receiver TCP discard values whose timestamp is
outside the accepted window, which is derived from the timestamps of outside the accepted window, which is derived from the timestamps of
other packets from the same connection. This technique uses an other packets from the same connection. This technique uses an
existing TCP option, but also requires modified RST processing and existing TCP option, but also requires modified TCP control
may be difficult to deploy incrementally without further processing (with the same caveats) and may be difficult to deploy
modifications. Additionally, the timestamp value may be easier to incrementally without further modifications. Additionally, the
guess because it is derived from a predictable value. timestamp value may be easier to guess because it is derived from a
predictable value.
3.1.4. Other TCP Cookies 3.1.4. Other TCP Cookies
All of the above techniques are variants of cookies, otherwise All of the above techniques are variants of cookies, otherwise
meaningless data whose value is used to validate the packet. In the meaningless data whose value is used to validate the packet. In the
case of MD5 checksums, the cookie is computed based on a shared case of MD5 checksums, the cookie is computed based on a shared
secret. Note that even a signature can be guessed, and presents a 1 secret. Note that even a signature can be guessed, and presents a 1
in 2^(signature length) probability of attack. The primary in 2^(signature length) probability of attack. The primary
difference is that MD5 signatures are effectively one-time cookies, difference is that MD5 signatures are effectively one-time cookies,
not predictable based on man-in-the-middle snooping, because they are not predictable based on on-path snooping, because they are dependent
dependent on packet data and thus do not repeat. Window attenuation on packet data and thus do not repeat. Window attenuation sequence
sequence numbers can be guessed by snooping the sequence number of numbers can be guessed by snooping the sequence number of current
current packets, and timestamps can be guessed even more remotely. packets, and timestamps can be guessed even more remotely. These
These variants of cookies are similar in spirit to TCP SYN cookies, variants of cookies are similar in spirit to TCP SYN cookies, again
again patching a vulnerability to off-path third-party spoofing patching a vulnerability to off-path third-party spoofing attacks
attacks based on a (fairly weak, excepting MD5) form of based on a (fairly weak, excepting MD5) form of authentication.
authentication. Another form of cookie is the source port itself, Another form of cookie is the source port itself, which can be
which can be randomized but provides only 16 bits of protection randomized but provides only 16 bits of protection (65,000
(65,000 combinations), which may be exhaustively attacked. This can combinations), which may be exhaustively attacked. This can be
be combined with destination port randomization as well, but that combined with destination port randomization as well, but that would
would require a separate coordination mechanism (so both parties know require a separate coordination mechanism (so both parties know which
which ports to use), which is equivalent to (and as infeasible for ports to use), which is equivalent to (and as infeasible for large-
large-scale deployments as) exchanging a shared secret. scale deployments as) exchanging a shared secret.
3.1.5. Other TCP Considerations 3.1.5. Other TCP Considerations
The analysis of the potential for RST spoofing above assumes that the The analysis of the potential for RST spoofing above assumes that the
receive window opens to the maximum extent suggested by the advertised receive window is opened to the maximum extent suggested
bandwidth-delay product of the end-to-end path, and that the window by the bandwidth-delay product of the end-to-end path, and that the
opens to an appreciable fraction of the overall sequence number window is opened to an appreciable fraction of the overall sequence
space. As noted earlier, for most common cases, connections are too number space. As noted earlier, for most common cases, connections
brief or over bandwidths too low for such a large window to occur. are too brief or over bandwidths too low for such a large window to
Expanding TCP's sequence number space is a direct way to further be useful. Expanding TCP's sequence number space is a direct way to
avoid such vulnerability, even for long connections over emerging further avoid such vulnerability, even for long connections over
bandwidths. emerging bandwidths. If either manual tuning or automatic tuning of
the advertised receive window (via receive buffer tuning) is not
provided, this is not an issue (although connection performance will
suffer) [33].
Finally, it is often sufficient for the endpoint to limit the receive It is may be sufficient for the endpoint to limit the advertised
window in other ways, notably using 'socket options'. If the receive receive window by deliberately leaving it small. If the receive
socket buffer is limited, e.g., to the ubiquitous default of 65KB, socket buffer is limited, e.g., to the ubiquitous default of 64KB,
the receive window cannot grow to vulnerable sizes even for very long the advertised receive window will not be as vulnerable even for very
connections over very high bandwidths. The consequence is lower long connections over very high bandwidths. The vulnerability will
sustained throughput, where only one window's worth of data per round grow linearly with the increased network speed, but not as the
trip time (RTT) is exchanged. Although this will keep the connection square. The consequence is lower sustained throughput, where only
open longer, it also reduces the receive window; for long-lived one window's worth of data per round trip time (RTT) is exchanged.
connections with continuous sourced data, this may continue to This will keep the connection open longer; for long-lived connections
present an attack opportunity, albeit a sparse and slow-moving with continuous sourced data, this may continue to present an attack
target. For the most recent case where BGP data is being exchanged opportunity, albeit a sparse and slow-moving target. For the most
between Internet routers, the data is bursty and the aggregate recent case where BGP data is being exchanged between Internet
traffic is small (i.e., unlikely to cover a substantial portion of routers, the data is bursty and the aggregate traffic may be small
the sequence space, even if long-lived), so is difficult to consider (i.e., unlikely to cover a substantial portion of the sequence space,
where smaller receive buffers would not sufficiently address the even if long-lived), so is smaller advertised receive windows (via
immediate problem. small receiver buffers) may, in some cases, sufficiently address the
immediate problem. This assumes that the routing tables can be
exchanged quickly enough with bandwidth reduced due to the smaller
buffers, or perhaps that the advertised receive window is opened only
during a large burst exchange (e.g., via some other signal between
the two routers).
3.1.6. Other Transport Protocol Solutions 3.1.6. Other Transport Protocol Solutions
Segment authentication has been addressed at the transport layer in Segment authentication has been addressed at the transport layer in
other protocols. Both SCTP and DCCP* include cookies for connection other protocols. Both SCTP and DCCP include cookies for connection
establishment and uses them to authenticate a variety of other establishment and use them to authenticate a variety of other control
control messages [30][23]. The inclusion of such mechanism at the messages [26][34]. The inclusion of such mechanism at the transport
transport protocol, although emerging as standard practice, protocol, although emerging as standard practice, unnecessarily
unnecessarily complicates the design and implementation of new complicates the design and implementation of new protocols [28] As
protocols [25] As new attacks are discovered (SYN floods, RSTs, new attacks are discovered (SYN floods, RSTs, etc.), each protocol
etc.), each protocol must be modified individually to compensate. A must be modified individually to compensate. A network solution may
network solution may be more appropriate and efficient. be more appropriate and efficient.
*[AUTH - DCCP may be removing cookies from the spec for the
redundancies discussed above, because the use of cookies at the
transport layer primarily supports dynamic multihoming (a design goal
of SCTP, but not DCCP) rather than security.]
3.2. Network Layer (IP) Solutions 3.2. Network Layer (IP) Solutions
There are two primary variants of network layer solutions to There are two primary variants of network layer solutions to
spoofing: ingress filtering and IPsec. Ingress filtering is an spoofing: address filtering and IPsec. Address filtering is an
indirect system which relies on other parties to filter packets sent indirect system which relies on other parties to filter packets sent
upstream of an attack, but does not necessarily require participation upstream of an attack, but does not necessarily require participation
of the packet source. IPsec requires cooperation between the of the packet source. IPsec requires cooperation between the
endpoints wanting to avoid attack on their connection, which endpoints wanting to avoid attack on their connection, which
currently involves pre-existing shared knowledge of either a shared currently involves pre-existing shared knowledge of either a shared
key or shared certificate authority. key or shared certificate authority.
3.2.1. Ingress filtering 3.2.1. Address filtering
Ingress filtering is often proposed as an alternative to protocol Address filtering is often proposed as an alternative to protocol
mechanisms to defeat IP source address spoofing [1][10]. Ingress mechanisms to defeat IP source address spoofing [2][12]. Address
filtering restricts traffic from downstream sources across transit filtering restricts traffic from downstream sources across transit
networks based on the IP source address. It cannot restrict traffic networks based on the IP source address. It cannot restrict traffic
from the core to edges, i.e., from upstream sources. As a result, from the core to edges, i.e., from upstream sources. As a result,
each ingress must perform the appropriate filtering for overall each border router must perform the appropriate filtering for overall
protection to result; failure of any ingress to filter defeats the protection to result; failure of any border router to filter defeats
protection of all network participants, ultimately. the protection of all participants inside the border, ultimately.
Address filtering at the border can protect those inside the border
from some kinds of spoofing, because only interior addresses should
originate inside the border. It cannot, however, protect connections
originating outside the border except to restrict where the traffic
enters from, e.g., if it expected from one AS and not another.
As a result, ingress filtering is not a local solution that can be As a result, address filtering is not a local solution that can be
deployed to protect communicating pairs, but rather relies on a deployed to protect communicating pairs, but rather relies on a
distributed infrastructure of trusted gateways filtering forged distributed infrastructure of trusted gateways filtering forged
traffic where it enters the network. It is not feasible for local, traffic where it enters the network. It is not feasible for local,
incremental deployment, and relies too heavily on distributed incremental deployment, and relies too heavily on distributed
cooperation. Although useful to reduce the load of spoofed traffic, cooperation. Although useful to reduce the load of spoofed traffic,
it is insufficient to protect particular connections from attack. it is insufficient to protect particular connections from attack.
A more recent variant of ingress filtering checks the IP TTL field, A more recent variant of address filtering checks the IP TTL field,
relying on the TTL set by the other end of the connection [12]. This relying on the TTL set by the other end of the connection [14]. This
technique has been used to provide filtering for BGP. It assumes the technique has been used to provide filtering for BGP. It assumes the
connection source TTL is set to 255; packets at the receiver are connection source TTL is set to 255; packets at the receiver are
checked for TTL=255, and others are dropped. This restricts traffic checked for TTL=255, and others are dropped. This restricts traffic
to one hop upstream of the receiver, but those hops could include to one hop upstream of the receiver (i.e., a BGP router), but those
other user programs at those nodes or any traffic those nodes accept hops could include other user programs at those nodes (e.g., the BGP
via tunnels - because tunnels need not decrement TTLs [26]. This router's peer) or any traffic those nodes accept via tunnels -
method of filtering works best where traffic originates one hop away, because tunnels need not decrement TTLs [29] (see Sec. 5.1 of [14]).
so that the ingress filtering is based on the trust of only directly- This method of filtering works best where traffic originates one hop
connected (tunneled or otherwise) nodes. Like conventional ingress away, so that the address filtering is based on the trust of only
filtering, this reduces spoofing traffic in general, but is not directly-connected (tunneled or otherwise) nodes. Like conventional
considered a reliable security mechanism because it relies on address filtering, this reduces spoofing traffic in general, but is
distributed filtering (that upstream nodes do not terminate tunnels not considered a reliable security mechanism because it relies on
arbitrarily, e.g.). distributed filtering (e.g., the fact that upstream nodes do not
terminate tunnels arbitrarily).
3.2.2. IPsec 3.2.2. IPsec
TCP is susceptible to RSTs, but also to other spoofing and man-in- TCP is susceptible to RSTs, but also to other off-path and on-path
the-middle attacks, including SYN attacks. Other transport spoofing attacks, including SYN attacks. Other transport protocols,
protocols, such as UDP and RTP are equally susceptible. Although such as UDP and RTP are equally susceptible. Although emerging
emerging transport protocols attempt to defeat such attacks at the transport protocols attempt to defeat such attacks at the transport
transport layer, such attacks take advantage of network layer layer, such attacks take advantage of network layer identity
identity spoofing. The packet is coming from an endpoint who is spoofing. The packet is coming from an endpoint who is spoofing
spoofing another endpoint, either upstream or somewhere else in the another endpoint, either upstream or somewhere else in the Internet.
Internet. IPsec was designed specifically to establish and enforce IPsec was designed specifically to establish and enforce
authentication of a packet's source and contents, to most directly authentication of a packet's source and contents, to most directly
and explicitly addresses this security vulnerability. and explicitly addresses this security vulnerability.
The larger problem with IPsec is that of CA key distribution and use. The larger problem with IPsec is that of key distribution and use.
IPsec is often cumbersome, and has only recently been supported in IPsec is often cumbersome, and has only recently been supported in
many end-system operating systems. More importantly, it relies on many end-system operating systems. More importantly, it relies on
signed X.509 certificates to establish and exchange keying preshared keys, signed X.509 certificates, or a third-party (e.g.,
Kerberos) public key infrastructure to establish and exchange keying
information (e.g., via IKE). These present challenges when using information (e.g., via IKE). These present challenges when using
IPsec to secure traffic to a well-known server, whose clients may not IPsec to secure traffic to a well-known server, whose clients may not
support IPsec or may not have registered with a previously-known support IPsec or may not have registered with a previously-known
certificate authority (CA). certificate authority (CA).
4. Issues These keying challenges are being addressed in the IETF in ways that
will enable servers secure associations with other parties without
advance coordination [38][39]. This can be especially useful for
publicly-available servers, or for protecting connections to servers
that - for whatever reason - have not, or will not deploy
conventional IPsec certificates (i.e., core Internet BGP routers).
4. ICMP
Just as spoofed TCP packets can kill a connection, so too can spoofed
ICMP packets. TCP headers can occur inside certain ICMP messages [6].
There have been recent suggestions to validate the sequence number of
TCP headers when they occur inside ICMP messages [16]. This sequence
checking is similar to checks that would occur for conventional data
packets in TCP, but is being proposed in the spirit of the RST window
attenuation described in Section 3.1.2.
Some such checks may be reasonable, especially where they parallel
the validations already performed by TCP processing, notably where
they emulate the semantics of such processing. For example, the TCP
checksum should be validated (if the entire TCP segment is contained
in the ICMP message) before any fields of the TCP header are
examined, to avoid reacting to corrupted packets. Similarly, if the
TCP MD5 option is present, its signature should probably be validated
before considering the contents of the message.
Such validation can ensure that the packet was not corrupted prior to
the ICMP generation (checksum), that the packet was one sent by the
source (IPsec or TCP/MD5 authenticated), or that the packet was not
in the network for an excess of 2*MSL (valid sequence number).
ICMP presents a particular challenge because some messages can reset
a connection more easily - with less validation - than even some
spoofed TCP segments. However, fixing such messages to be 'in window'
is insufficient protection, as this document shows for spoofed data.
In addition, many networks filter all ICMP packets because validation
may not be possible, especially because they can be injected from any
point on a path, and so cannot be selectively address filtered. As a
result, they are not addressed separately in the issues or security
considerations of this document further.
5. Issues
There are a number of existing and proposed solutions addressing the There are a number of existing and proposed solutions addressing the
vulnerability of transport protocols in general, and TCP in specific, vulnerability of transport protocols in general, and TCP in specific,
to off-path third-party spoofing attacks. As shown, these operate at to off-path third-party spoofing attacks. As shown, these operate at
the transport or network layer. Transport solutions require separate the transport or network layer. Transport solutions require separate
modification of each transport protocol, addressing network identity modification of each transport protocol, addressing network identity
spoofing separately in the context of each transport association. spoofing separately in the context of each transport association.
Network solutions are computationally intensive and require pervasive Network solutions are computationally intensive and require pervasive
registration of certificate authorities with every possible endpoint. registration of certificate authorities with every possible endpoint.
This section explains these observations further. This section explains these observations further.
4.1. Transport Layer (e.g., TCP) 5.1. Transport Layer (e.g., TCP)
Transport solutions rely on shared cookies to authenticate segments, Transport solutions rely on shared cookies to authenticate segments,
including data, transport header, and even pseudo-header (e.g., fixed including data, transport header, and even pseudo-header (e.g., fixed
portions of the outer IP header in TCP). Because the Internet relies portions of the outer IP header in TCP). Because the Internet relies
on stateless network protocols, it makes sense to rely on state on stateless network protocols, it makes sense to rely on state
establishment and maintenance available in some transport layers not establishment and maintenance available in some transport layers not
only for the connection but for authentication state. Three-way only for the connection but for authentication state. Three-way
handshakes and heartbeats can be used to negotiate authentication handshakes and heartbeats can be used to negotiate authentication
state in conjunction with connection parameters, which can be stored state in conjunction with connection parameters, which can be stored
with connection state easily. with connection state easily.
As noted earlier, transport layer solutions require separate As noted earlier, transport layer solutions require separate
modification of all transport protocols to include authentication. modification of all transport protocols to include authentication.
Not all transport layers support negotiated endpoint state (e.g., Not all transport layers support negotiated endpoint state (e.g.,
UDP), and legacy protocols have been notoriously difficult to safely UDP), and legacy protocols have been notoriously difficult to safely
augment. Not all authentication solutions are created equal either, augment. Not all authentication solutions are created equal either,
and relying on a variety of transport solutions exposes end-systems and relying on a variety of transport solutions exposes end-systems
to increased potential for incorrectly specified or implemented to increased potential for incorrectly specified or implemented
solutions. Transport authentication has often been developed piece- solutions. Transport authentication has often been developed piece-
wise, in response to specific attacks, e.g., SYN cookies and RST wise, in response to specific attacks, e.g., SYN cookies and RST
window attenuation [3][8]. window attenuation [4][10].
Transport layer solutions are not only per-protocol, but often per- Transport layer solutions are not only per-protocol, but often per-
connection. Each connection needs to negotiate and maintain connection. Each connection needs to negotiate and maintain
authentication state separately. Overhead is not amortized over authentication state separately. Some overhead is not amortized over
multiple connections - this includes overheads in packet exchanges, multiple connections, e.g., overheads in packet exchanges, whereas
design complexity, and implementation complexity. Finally, because other overheads are not amortized over different transport protocols,
the authentication happens later in packet processing than is e.g., design and implementation complexity - both as would be the
required, additional endpoint resources may be needlessly consumed, case in a network layer solution. Finally, because the
e.g., in demultiplexing received packets, indexing connection authentication happens later in packet processing than is required,
identifiers, etc., only to be dropped later at the transport layer. additional endpoint resources may be needlessly consumed, e.g., in
demultiplexing received packets, indexing connection identifiers,
etc., only to be dropped later at the transport layer.
4.2. Network Layer (IP) 5.2. Network Layer (IP)
A network layer solution avoids the hazards of multiple transport A network layer solution avoids the hazards of multiple transport
variants, using a single shared endpoint authentication mechanism variants, using a single shared endpoint authentication mechanism
early in receiver packet processing to discard unauthenticated early in receiver packet processing to discard unauthenticated
packets quickly. Network solutions protect all transport protocols, packets at the network layer instead. This defeats spoofing entirely
including both legacy and emerging protocols, and reduce the because spoofing involves masquerading as another endpoint, and
complexity of these protocols as well. A shared solution also network layer security validates the endpoint as the source of the
reduces protocol overhead, and decouples the management (and packets it emits. Such a network level solution protects all
refreshing) of authentication state from that of individual transport transport protocols as a result, including both legacy and emerging
connections. Finally, a network layer solution protects not only the protocols, and reduces the complexity of these protocols as well. A
transport layer but the network layer as well, e.g., from ICMP, IGMP, shared solution also reduces protocol overhead, and decouples the
etc., spoofing attacks. management (and refreshing) of authentication state from that of
individual transport connections. Finally, a network layer solution
protects not only the transport layer but the network layer as well,
e.g., from ICMP, IGMP, etc., spoofing attacks.
The ubiquitous protocol for network layer authentication is IPsec The ubiquitous protocol for network layer authentication is IPsec
[19][22]. IPsec specifies the overall architecture, including header [22][25]. IPsec specifies the overall architecture, including header
authentication (AH) [20][18] and encapsulation (ESP) modes [21]. AH authentication (AH) [21][23] and encapsulation (ESP) modes [24]. AH
authenticates both the IP header and IP data, whereas ESP authenticates both the IP header and IP data, whereas ESP
authenticates only the IP data (e.g., transport header and payload). authenticates only the IP data (e.g., transport header and payload).
AH is deprecated since ESP is more efficient and the SPI includes AH is deprecated since ESP is more efficient and the SPI includes
sufficient information to verify the IP header anyway. These two sufficient information to verify the IP header anyway. These two
modes describe the security applied to individual packets within the modes describe the security applied to individual packets within the
IPsec system; key exchange and management is performed either out-of- IPsec system; key exchange and management is performed either out-of-
band (via pre-shared keys) or by an automated key exchange protocol band (via pre-shared keys) or by an automated key exchange protocol
IKE [14][17]. IKE [17][20].
IPsec already provides authentication of an IP header and its data IPsec already provides authentication of an IP header and its data
contents sufficient to defeat both man-in-the-middle and off-path contents sufficient to defeat both on-path and off-path third-party
third-party spoofing attacks. IKE can configure authentication spoofing attacks. IKE can configure authentication between two
between two endpoints on a per-endpoint, per-protocol, or per- endpoints on a per-endpoint, per-protocol, or per-connection basis,
connection basis, as desired. IKE also can perform automatic as desired. IKE also can perform automatic periodic re-keying,
periodic re-keying, further defeating crypto-analysis based on further defeating crypto-analysis based on snooping (clandestine data
snooping (clandestine data collection). The use of IPsec is already collection). The use of IPsec is already commonly strongly
commonly strongly recommended for protected infrastructure. recommended for protected infrastructure.
IPsec is not appropriate for many deployments. It is computationally Existing IPsec is not appropriate for many deployments. It is
intensive both in key management and individual packet authentication computationally intensive both in key management and individual
[32]. As importantly, IKE is not anonymous; keys can be exchanged packet authentication [36]. As importantly, IKE is not anonymous;
between parties only if they trust each others' X.509 certificates or keys can be exchanged between parties only if they trust each others'
pre-share a key. These certificates provide identification (the X.509 certificates, trust some other third-party to help with key
other party knows who you are) only where the certificates themselves generation (e.g., Kerberos), or pre-share a key. These certificates
are signed by certificate authorities (CAs) that both parties already provide identification (the other party knows who you are) only where
trust. To a large extent, the CAs themselves are the pre-shared keys the certificates themselves are signed by certificate authorities
which help IKE establish security association keys, which are then (CAs) that both parties already trust. To a large extent, the CAs
used in the authentication algorithms. themselves are the pre-shared keys which help IKE establish security
association keys, which are then used in the authentication
algorithms.
Alternative mechanisms are under development to address this
limitation, to allow publicly-accessible servers to secure
connections to clients not known in advance, or to allow unilateral
relaxation of identity validation so that the remaining protections
of IPsec to be available [38][39]. In particular, these mechanisms
can prevent a client (but without knowing who that client is) from
being affected by spoofing from other clients, even when the
attackers are on the communications path.
IPsec, although widely available both in commercial routers and IPsec, although widely available both in commercial routers and
commodity end-systems, is not often utilized except between parties commodity end-systems, is not often utilized except between parties
that already have a preexisting relationship (employee/employer, that already have a preexisting relationship (employee/employer,
between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ between two ISPs, etc.) Servers to anonymous clients (e.g., customer/
business) or more open services (e.g., BGP, where routers may large business) or more open services (e.g., BGP, where routers may have
numbers of peers) are unmanageable, due to the breadth and flux of large numbers of peers) are unmanageable, due to the breadth and flux
CAs. New endpoints cannot establish IPsec associations with such of CAs. New endpoints cannot establish IPsec associations with such
servers unless their certificate is signed by a CA already trusted by servers unless their own certificate is signed by a CA already
the server. Different servers - even within the same overall system trusted by the server. Different servers - even within the same
(e.g., BGP) - often cannot or will not trust overlapping subsets of overall system (e.g., BGP) - often cannot or will not trust
CAs in general. overlapping subsets of CAs in general.
4.3. Application Layer 5.3. Application Layer
There are a number of application layer authentication mechanisms, There are a number of application layer authentication mechanisms,
often implicit within end-to-end encryption. Application-layer often implicit within end-to-end encryption. Application-layer
security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) security (e.g., TLS, SSH, or MD5 checksums within a BGP stream)
provides the ultimate protection of application data from all provides the ultimate protection of application data from all
intermediaries, including network routers as well as exposure at intermediaries, including network routers as well as exposure at
other layers in the end-systems. This is the only way to ultimately other layers in the end-systems. This is the only way to ultimately
protect the application data. protect the application data.
Application authentication cannot protect either the network or Application authentication cannot protect either the network or
transport protocols from spoofing attacks, however. Spoofed packets transport protocols from spoofing attacks, however. Spoofed packets
interfere with network processing or reset transport connections interfere with network processing or reset transport connections
before the application checks the data. Authentication needs to before the application checks the data. Authentication needs to
winnow these packets and drop them before they interfere at these winnow these packets and drop them before they interfere at these
lower layers. lower layers.
4.4. Shim Transport/Application Layer An alternate application layer solution would involve resilience to
reset connections. If the application can recover from such
connection interruptions, then such attacks have less impact.
Unfortunately, attackers still affect the application, e.g., in the
cost of restarting connections, delays until connections are
restarted, or increased connection establishment messages on the
network. Some applications - notably BGP - even interpret TCP
connection reliability as an indicator of route path stability, which
is why attacks on BGP have such substantial consequences.
5.4. Shim Transport/Application Layer
Security can also be provided over the transport layer but below the Security can also be provided over the transport layer but below the
application layer, in a kind of 'shim' protocol, such as SSL or TLS. application layer, in a kind of 'shim' protocol, such as SSL or TLS.
These protocols provide data protection for a variety of applications These protocols provide data protection for a variety of applications
over a single, legacy transport protocol, such as SSL/TCP for HTTPS. over a single, legacy transport protocol, such as SSL/TCP for HTTPS.
Unfortunately, as with application authentication, they do not Unfortunately, as with application authentication, they do not
protect the transport layer against spoofing attacks. protect the transport layer against spoofing attacks.
4.5. Link Layer 5.5. Link Layer
Link layer security operates separately on each hop of an Internet. Link layer security operates separately on each hop of an Internet.
Such security can be critical in protecting link resources, such as Such security can be critical in protecting link resources, such as
bandwidth and link management protocols. Protection at this layer bandwidth and link management protocols. Protection at this layer
cannot suffice for network or transport layers, because it cannot cannot suffice for network or transport layers, because it cannot
authenticate the endpoint source of a packet. Link authentication authenticate the endpoint source of a packet. Link authentication
ensures only the source of the current link hop where it is examined. ensures only the source of the current link hop where it is examined.
4.6. Issues Discussion 5.6. Issues Discussion
The issues raised in this section suggest that there are challenges The issues raised in this section suggest that there are challenges
with all solutions to transport protection from spoofing attacks. with all solutions to transport protection from spoofing attacks.
This raises the potential need for alternate security levels. While This raises the potential need for alternate security levels. While
it is already widely recognized that security needs to occur it is already widely recognized that security needs to occur
simultaneously at many protocol layers, the also may be utility in simultaneously at many protocol layers, there also may be utility in
supporting a variety of strengths at a single layer. For example, supporting a variety of strengths at a single layer. For example,
IPsec already supports a variety of algorithms (MD5, SHA, etc. for IPsec already supports a variety of algorithms (MD5, SHA1, etc. for
authentication), but always assumes that: authentication), but always assumes that:
4. the entire body of the packet is secured 4. the entire body of the packet is secured
5. security associations are established only where identity is 5. security associations are established only where identity is
authenticated by a know certificate authority or other pre-shared authenticated by a know certificate authority or other pre-shared
key key
6. both man-in-the-middle and off-path third-party spoofing attacks 6. both on-path and off-path third-party spoofing attacks must be
must be defeated defeated
These assumptions are prohibitive, especially in many cases of These assumptions are prohibitive, especially in many cases of
spoofing attacks. For spoofing, the primary issue is whether packets spoofing attacks. For spoofing, the primary issue is whether packets
are coming from the same party the server can reach. Only the IP are coming from the same party the server can reach. Only the IP
header is fundamentally in question, so securing the entire packet header is fundamentally in question, so securing the entire packet
(1) is computational overkill. It is sufficient to authenticate the (1) is computational overkill. It is sufficient to authenticate the
other party as "a party you have exchanged packets with", rather than other party as "a party you have exchanged packets with", rather than
establishing their trusted identity ("Bill" vs. "Bob") as in (2). establishing their trusted identity ("Bill" vs. "Bob") as in (2).
Finally, many cookie systems use clear-text (unencrypted), fixed Finally, many cookie systems use clear-text (unencrypted), fixed
cookie values, providing reasonable (1 in 2^{cookie-size}) protection cookie values, providing reasonable (1 in 2^{cookie-size}) protection
against off-path third-party spoofs, but not addressing man-in-the- against off-path third-party spoof attacks, but not addressing on-
middle at all. Such potential solutions are discussed in the ANONsec path attacks at all. Such potential solutions are discussed in the
document, in the BTNS (Better Than Nothing Security) BOF [4][34]. ANONsec document, in the BTNS (Better Than Nothing Security) BOF
Note also that NULL Encryption in IPsec applies a variant of this [5][38][39]. Note also that NULL Encryption in IPsec applies a
cookie, where the SPI is the cookie, and no further encryption is variant of this cookie, where the SPI is the cookie, and no further
applied [13]. encryption is applied [15].
5. Security Considerations 6. Security Considerations
This entire document focuses on increasing the security of transport This entire document focuses on increasing the security of transport
protocols and their resistance to spoofing attacks. Security is protocols and their resistance to spoofing attacks. Security is
addressed throughout. addressed throughout.
This document describes a number of techniques for defeating spoofing This document describes a number of techniques for defeating spoofing
attacks. Those relying on clear-text cookies, either explicit or attacks. Those relying on clear-text cookies, either explicit or
implicit (e.g., window sequence attenuation) do not protect from man- implicit (e.g., window sequence attenuation) do not protect from on-
in-the-middle spoofing attacks, since valid values can be learned path spoofing attacks, since valid values can be learned from prior
from prior traffic. Those relying on true authentication algorithms traffic. Those relying on true authentication algorithms are
are stronger, protecting even from man-in-the-middle, because the stronger, protecting even from on-path attacks, because the
authentication hash in a single packet approaches the behavior of authentication hash in a single packet approaches the behavior of
"one time" cookies. "one time" cookies.
The security of various levels of the protocol stack is addressed. The security of various levels of the protocol stack is addressed.
Spoofing attacks are fundamentally identity masquerading, so we Spoofing attacks are fundamentally identity masquerading, so we
believe the most appropriate solutions defeat these at the network believe the most appropriate solutions defeat these at the network
layer, where end-to-end identity lies. Some transport protocols layer, where end-to-end identity lies. Some transport protocols
subsume endpoint identity information from the network layer (e.g., subsume endpoint identity information from the network layer (e.g.,
TCP pseudo-headers), whereas others establish per-connection identity TCP pseudo-headers), whereas others establish per-connection identity
based on exchanged nonces (e.g., SCTP). It is reasonable, if not based on exchanged nonces (e.g., SCTP). It is reasonable, if not
recommended, to address security at all layers of the protocol stack. recommended, to address security at all layers of the protocol stack.
6. Conclusions 7. IANA Considerations
There are no IANA considerations in this document.
This section should be removed by the RFC-Editor upon publication as
an RFC.
8. Conclusions
This document describes the details of the recent BGP spoofing This document describes the details of the recent BGP spoofing
attacks involving spurious RSTs which could be used to shutdown TCP attacks involving spurious RSTs which could be used to shutdown TCP
connections. It summarizes and discusses a variety of current and connections. It summarizes and discusses a variety of current and
proposed solutions at various protocol layers. proposed solutions at various protocol layers.
7. Acknowledgments 9. Acknowledgments
This document was inspired by discussions on the This document was inspired by discussions on the
<http://www.ietf.org/html.charters/tcpm-charter.html> about the <http://www.ietf.org/html.charters/tcpm-charter.html> about the
recent spoofed RST attacks on BGP routers, including R. Stewart's recent spoofed RST attacks on BGP routers, including R. Stewart's
draft (which is now edited by M. Dalal) [31][8]. The analysis of the draft (which is now edited by M. Dalal) [10][35]. The analysis of
attack issues, alternate solutions, and the anonymous security the attack issues, alternate solutions, and the anonymous security
proposed solutions were the result of discussions on that list as proposed solutions were the result of discussions on that list as
well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. Ran well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. Ran
Atkinson suggested the UDP variant of TCP/MD5, and Paul Goyette Atkinson suggested the UDP variant of TCP/MD5, Paul Goyette suggested
suggested using the ISN to seed TCP/MD5. Other improvements are due using the ISN to seed TCP/MD5, and Lloyd Wood suggested using the ISN
to the input of various members of the IETF's TCPM WG. to validate RSTs. Other improvements are due to the input of various
members of the IETF's TCPM WG, notably detailed feedback from Pekka
Savola.
8. References 10. References
8.1. Normative References 10.1. Normative References
As this is not a standards document, this section has no meaning. None.
8.2. Informative References 10.2. Informative References
[1] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [1] Allman, M., V. Paxson, W. Stephens, "TCP Congestion Control,"
RFC 2581, Apr. 1999.
[2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks," RFC 2827 / BCP 84, March 2004. Networks," RFC 2827 / BCP 84, March 2004.
[2] Bellovin, S. and A. Zinin, "Standards Maturity Variance [3] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4
Specification," (work in progress), Specification," (work in progress),
draft-iesg-tcpmd5app-01.txt, Sept. 2004. draft-iesg-tcpmd5app-01.txt, Sept. 2004.
[3] Bernstein, D., "SYN cookies - http://cr.yp.to/syncookies.html", [4] Bernstein, D., "SYN cookies - http://cr.yp.to/syncookies.html",
1997. 1997.
[4] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC., [5] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC.,
http://www.ietf.org/ietf/04nov/btns.txt http://www.ietf.org/ietf/04nov/btns.txt
[5] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, [6] Braden, R., "Requirements for Internet Hosts -- Communication
Layers," RFC 1122, Oct. 1989.
[7] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337,
May 1992. May 1992.
[6] CERT alert: "Technical Cyber Security Alert TA04-111A: [8] CERT alert: "Technical Cyber Security Alert TA04-111A:
Vulnerabilities in TCP -- Vulnerabilities in TCP --
http://www.us-cert.gov/cas/techalerts/TA04-111A.html", April 20 http://www.us-cert.gov/cas/techalerts/TA04-111A.html", April 20
2004. 2004.
[7] Convery, S. and M. Franz, "BGP Vulnerability Testing: [9] Convery, S. and M. Franz, "BGP Vulnerability Testing:
Separating Fact from FUD", 2003, Separating Fact from FUD", 2003,
http://www.nanog.org/mtg-0306/pdf/franz.pdf http://www.nanog.org/mtg-0306/pdf/franz.pdf
[8] Dalal, M., (ed.), "Transmission Control Protocol security [10] Dalal, M., (ed.), "Transmission Control Protocol security
considerations", draft-ietf-tcpm-tcpsecure-02 (work in considerations", draft-ietf-tcpm-tcpsecure-02 (work in
progress), Nov. 2004. progress), Nov. 2004.
[9] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP [11] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583, March 1999. 1583, March 1999.
[10] Ferguson, P. and D. Senie, Network Ingress Ingress Filtering: [12] Ferguson, P. and D. Senie, Network Ingress Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Address Defeating Denial of Service Attacks which employ IP Address
Spoofing," RFC 2267 / BCP 38, May 2000. Spoofing," RFC 2267 / BCP 38, May 2000.
[11] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP [13] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
60, RFC 3360, August 2002. 60, RFC 3360, August 2002.
[12] Gill, V., J. Heasley, and D. Meyer, "The Generalized TTL [14] Gill, V., J. Heasley, and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)," RFC 3682 (Experimental), Feb. 2004. Security Mechanism (GTSM)," RFC 3682 (Experimental), Feb. 2004.
[13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its [15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410 (Standards Track), November 1998. Use With IPsec", RFC 2410 (Standards Track), November 1998.
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [16] Gont, F., "ICMP attacks against TCP," (work in progress), Sept.
2005.
[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409 (Standards Track), November 1998. RFC 2409 (Standards Track), November 1998.
[15] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [18] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385 (Standards Track), August 1998. Signature Option", RFC 2385 (Standards Track), August 1998.
[16] Jacobson, V., B. Braden, and D. Borman, "TCP Extensions for [19] Jacobson, V., B. Braden, and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [20] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.
[18] Kent, S., "IP Authentication Header", [21] Kent, S., "IP Authentication Header",
draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004. draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004.
[19] Kent, S. and R. Atkinson, "Security Architecture for the [22] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401 (Standards Track), November 1998. Internet Protocol", RFC 2401 (Standards Track), November 1998.
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402 [23] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402
(Standards Track), November 1998. (Standards Track), November 1998.
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406 (Standards Track), November 1998. (ESP)", RFC 2406 (Standards Track), November 1998.
[22] Kent, S. and K. Seo, "Security Architecture for the Internet [25] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
April 2005. April 2005.
[23] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion [26] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", draft-ietf-dccp-spec-11 (work in Control Protocol (DCCP)", draft-ietf-dccp-spec-11 (work in
progress), March 2005. progress), March 2005.
[24] Leech, M., "Key Management Considerations for the TCP MD5 [27] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option," RFC 3562 (Informational), July 2003. Signature Option," RFC 3562 (Informational), July 2003.
[25] O'Malley, S. and L. Peterson, "TCP Extensions Considered [28] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991. Harmful", RFC 1263, October 1991.
[26] Perkins, C., "IP Encapsulation within IP," RFC 2003 (Standards [29] Perkins, C., "IP Encapsulation within IP," RFC 2003 (Standards
Track), Oct. 1996. Track), Oct. 1996.
[27] Poon, K., "Use of TCP timestamp option to defend against blind [30] Poon, K., "Use of TCP timestamp option to defend against blind
spoofing attack," draft-poon-tcp-tstamp-mod-01 (work in spoofing attack," draft-poon-tcp-tstamp-mod-01 (work in
progress), Oct. 2004. progress), Oct. 2004.
[28] Postel, J., "Transmission Control Protocol," RFC 793 / STD 7, [31] Postel, J., "Transmission Control Protocol," RFC 793 / STD 7,
September 1981. September 1981.
[29] Rekhter, Y. and T. Li, (eds.), "A Border Gateway Protocol 4 [32] Rekhter, Y. and T. Li, (eds.), "A Border Gateway Protocol 4
(BGP-4)," RFC 1771 (Standards Track), March 1995. (BGP-4)," RFC 1771 (Standards Track), March 1995.
[30] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, [33] Semke, J., J. Mahdavi, M. Mathis, "Automatic TCP Buffer
Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume
28, number 4, October 1998
[34] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson,
"Stream Control Transmission Protocol," RFC 2960 (Standards "Stream Control Transmission Protocol," RFC 2960 (Standards
Track), October 2000. Track), October 2000.
[31] TCPM: IETF TCPM Working Group and mailing list- [35] TCPM: IETF TCPM Working Group and mailing list-
http://www.ietf.org/html.charters/tcpm-charter.html. http://www.ietf.org/html.charters/tcpm-charter.html.
[32] Touch, J., "Report on MD5 Performance," RFC 1810 [36] Touch, J., "Report on MD5 Performance," RFC 1810
(Informational), June 1995. (Informational), June 1995.
[33] Touch, J., "Performance Analysis of MD5," Proc. Sigcomm 1995 [37] Touch, J., "Performance Analysis of MD5," Proc. Sigcomm 1995
77-86., March 1999. 77-86., March 1999.
[34] Touch, J., "ANONsec: Anonymous Security to Defend Against [38] Touch, J., "ANONsec: Anonymous Security to Defend Against
Spoofing Attacks," draft-touch-anonsec-00 (work in progress), Spoofing Attacks," draft-touch-anonsec-00 (work in progress),
May 2004. May 2004.
[35] Watson, P., "Slipping in the Window: TCP Reset attacks," [39] Touch, J., D. Black, and Y. Wang, "Problem and Applicability
Statement for Better Than Nothing Security (BTNS)," draft-ietf-
btns-prob-and-applic-01 (work in progress), Sept. 2005.
[40] Watson, P., "Slipping in the Window: TCP Reset attacks,"
Presentation at 2004 CanSecWest. Presentation at 2004 CanSecWest.
http://www.cansecwest.com/archives.html http://www.cansecwest.com/archives.html
[41] Wood, L., Post to TCPM mailing list regarding use of ISN in
RSTs, ID=Pine.GSO.4.50.0404232249570.5889-
100000@argos.ee.surrey.ac.uk, Apr. 23, 2004.
http://www1.ietf.org/mail-
archive/web/tcpm/current/msg00213.html
Author's Addresses Author's Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300 Fax: +1 (310) 448-9300
skipping to change at page 21, line 40 skipping to change at page 25, line 20
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 123 change blocks. 
350 lines changed or deleted 526 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/