draft-ietf-tcpm-tcp-antispoof-03.txt   draft-ietf-tcpm-tcp-antispoof-04.txt 
IETF TCPM WG J. Touch IETF TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Expires: August 2006 February 18, 2006 Expires: November 2006 May 15, 2006
Defending TCP Against Spoofing Attacks Defending TCP Against Spoofing Attacks
draft-ietf-tcpm-tcp-antispoof-03.txt draft-ietf-tcpm-tcp-antispoof-04.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 August 18, 2006. This Internet-Draft will expire on November 15, 2006.
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
has always been susceptible to such RST spoofing attacks, which were has always been susceptible to such RST spoofing attacks, which were
indirectly protected by checking that the RST sequence number was indirectly protected by checking that the RST sequence number was
inside the current receive window, as well as via the obfuscation of inside the current receive window, as well as via the obfuscation of
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 brute-force generate a
sequence number. The susceptibility to attack increases as the viable RST sequence number. The susceptibility to attack increases
square of the bandwidth, thus presents a significant vulnerability as the square of the bandwidth, thus presents a significant
for recent high-speed networks. This document addresses this vulnerability for recent high-speed networks. This document
vulnerability, discussing proposed solutions at the transport level addresses this vulnerability, discussing proposed solutions at the
and their inherent challenges, as well as existing network level transport level and their inherent challenges, as well as existing
solutions and the feasibility of their deployment. This document network level solutions and the feasibility of their deployment.
focuses on vulnerabilities due to spoofed TCP segments, and includes This document focuses on vulnerabilities due to spoofed TCP segments,
a discussion of related ICMP spoofing attacks on TCP connections. 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. Review of TCP Windows.....................................4 2.1. Review of TCP Windows.....................................5
2.2. Recent BGP Attacks Using TCP RSTs.........................5 2.2. Recent BGP Attacks Using TCP RSTs.........................6
2.3. TCP RST Vulnerability.....................................6 2.3. TCP RST Vulnerability.....................................6
2.4. What Changed - the Ever Opening Advertised Receive Window.7 2.4. What Changed - the Ever Opening Advertised Receive Window.7
3. Proposed Solutions and Mitigations............................10 3. Proposed Solutions and Mitigations............................10
3.1. Transport Layer Solutions................................10 3.1. Transport Layer Solutions................................10
3.1.1. TCP MD5 Authentication..............................10 3.1.1. TCP MD5 Authentication..............................11
3.1.2. TCP RST Window Attenuation..........................11 3.1.2. TCP RST Window Attenuation..........................11
3.1.3. TCP Timestamp Authentication........................12 3.1.3. TCP Timestamp Authentication........................12
3.1.4. Other TCP Cookies...................................12 3.1.4. Other TCP Cookies...................................13
3.1.5. Other TCP Considerations............................13 3.1.5. Other TCP Considerations............................13
3.1.6. Other Transport Protocol Solutions..................13 3.1.6. Other Transport Protocol Solutions..................14
3.2. Network Layer (IP) Solutions.............................14 3.2. Network Layer (IP) Solutions.............................14
3.2.1. Address filtering...................................14 3.2.1. Address filtering...................................15
3.2.2. IPsec...............................................15 3.2.2. IPsec...............................................16
4. ICMP..........................................................16 4. ICMP..........................................................16
5. Issues........................................................16 5. Issues........................................................17
5.1. Transport Layer (e.g., TCP)..............................17 5.1. Transport Layer (e.g., TCP)..............................18
5.2. Network Layer (IP).......................................18 5.2. Network Layer (IP).......................................19
5.3. Application Layer........................................19 5.3. Application Layer........................................20
5.4. Shim Transport/Application Layer.........................20 5.4. Link Layer...............................................21
5.5. Link Layer...............................................20 5.5. Issues Discussion........................................21
5.6. Issues Discussion........................................20 6. Security Considerations.......................................22
6. Security Considerations.......................................21
7. IANA Considerations...........................................22 7. IANA Considerations...........................................22
8. Conclusions...................................................22 8. Conclusions...................................................22
9. Acknowledgments...............................................22 9. Acknowledgments...............................................23
10. References...................................................22 10. References...................................................23
10.1. Normative References....................................22 10.1. Normative References....................................23
10.2. Informative References..................................22 10.2. Informative References..................................23
Author's Addresses...............................................26 Author's Addresses...............................................27
Intellectual Property Statement..................................26 Intellectual Property Statement..................................27
Disclaimer of Validity...........................................26 Disclaimer of Validity...........................................27
Copyright Statement..............................................27 Copyright Statement..............................................28
Acknowledgment...................................................27 Acknowledgment...................................................28
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 based on RST spoofing from off- between core routers using an attack based on RST spoofing from off-
path attackers [9][10][40]. This attack has been known for nearly path attackers [9][10][43]. This attack has been known for nearly
six years [18]. Such connections, typically using TCP, can be six years [19]. Such connections, typically using TCP, can be
susceptible to off-path third-party reset (RST) segments with forged susceptible to off-path third-party reset (RST) segments with forged
source addresses (spoofed), which terminate the TCP connection. BGP source addresses (spoofed), which terminate the TCP connection. BGP
routers react to a terminated TCP connection in various ways which routers react to a terminated TCP connection in various ways which
can amplify the impact of an attack, ranging from restarting the can amplify the impact of an attack, ranging from restarting the
connection to deciding that the other router is unreachable and thus connection to deciding that the other router is unreachable and thus
flushing the BGP routes [31]. This sort of attack affects other flushing the BGP routes [33]. This sort of attack affects other
protocols besides BGP, involving any long-lived connection between protocols besides BGP, involving any long-lived connection between
well-known endpoints. The impact on Internet infrastructure can be well-known endpoints. The impact on Internet infrastructure can be
substantial (esp. for the BGP case), and warrants immediate substantial (esp. for the BGP case), 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 system-level (i.e., root) access. Given such
trivial for anyone to generate a packet with any header desired. access, it is trivial for anyone to generate a packet with any header
desired.
This, coupled with the lack of sufficient address 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 [9][10][40]. Proposed solutions include the party spoofing attacks [9][10][43]. Proposed solutions include the
deployment of existing Internet network and transport security as deployment of existing Internet network and transport security as
well as modifications to transport protocols that reduce its well as modifications to transport protocols that reduce its
vulnerability to generated attacks [12][14][18][33][39]. vulnerability to generated attacks [13][15][19][36][42].
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 level, and IPsec provides authentication at the network level
[17][18][21][24]. In both cases their deployment overhead may be [18][19][22][25]. In both cases their deployment overhead may be
prohibitive, e.g., it may not feasible for public services, such as prohibitive, e.g., it may not feasible for public services, such as
web servers, to be configured with the appropriate certificate web servers, to be configured with the appropriate certificate
authorities of large numbers of peers (for IPsec using IKE), or authorities of large numbers of peers (for IPsec using IKE), or
shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because
many clients may need to be configured rapidly without external many clients may need to be configured rapidly without external
assistance. Services from public web servers connecting to large- assistance. Services from public web servers connecting to large-
scale caches to BGP with larger numbers of peers can fall into this scale caches to BGP with larger numbers of peers can fall into this
category. category.
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
[33], modifications to TCP's timestamp processing [29], and [36], modifications to TCP's timestamp processing [31], and
modifications to IPsec and TCP/MD5 keying [38]. This document modifications to IPsec and TCP/MD5 keying [41]. This document
focuses on spoofing of TCP segments, although a discussion of related focuses on spoofing of TCP segments, although a discussion of related
spoofing of ICMP packets based on spoofed TCP contents is also spoofing of ICMP packets based on spoofed TCP contents is also
discussed. 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 [18]. The recent attack scenario was first development of TCP/MD5 [19]. 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 [10]. Watson's more detailed analysis for an attack to succeed [10]. 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 [40]. This document adds the observation that succeed at an attack [43]. 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 increase in receive window size and coupling between the linear increase in receive window size and
linear increase in rate an attacker, as well as comparing the variety linear increase in rate an attacker, as well as comparing the variety
of more recent proposals, including modifications to TCP, use of of more recent proposals, including modifications to TCP, use of
IPsec, 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
[9][10][40]. A variety of such attacks have been known for several [9][10][43]. 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. These attacks
attacks are countered by the use of some form of authentication at often combine external knowledge (e.g., to indicate the IP addresses
the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or to attack, the destination port number, and sometimes the ISN) with
other layers. TCP already includes a weak form of such brute-force capabilities enabled by modern computers and network
authentication in its check of segment sequence numbers against the bandwidths (e.g., to scan all source ports or an entire window
current receiver window. Increases in the bandwidth-delay product space). Overall, such attacks are countered by the use of some form
for certain long connections have sufficiently weakened this type of of authentication at the network (e.g., IPsec), transport (e.g., SYN
weak authentication to make reliance on it inadvisable. cookies, TCP/MD5), or other layers. TCP already includes a weak form
of such authentication in its check of segment sequence numbers
against the current receiver window. Increases in the bandwidth-
delay product for certain long connections have sufficiently weakened
this type of weak authentication to make reliance on it inadvisable.
2.1. Review of TCP Windows 2.1. Review of TCP Windows
Before proceeding, it is useful to review the terminology and Before proceeding, it is useful to review the terminology and
components of TCP's windowing algorithm. TCP connections have three components of TCP's windowing algorithm. TCP connections have three
kinds of windows [1][30]: kinds of windows [1][32]:
o Send window (SND.WND): the latest advertised send window size. o Send window (SND.WND): the latest send window size.
o Receive window (RCV.WND): the latest advertised receive window o Receive window (RCV.WND): the latest advertised receive window
size. size.
o Congestion window (CWND): the window determined by congestion o Congestion window (CWND): the window determined by congestion
feedback that limits how much of RCV.WND can be in-flight in a feedback that limits how much of RCV.WND can be in-flight in a
round trip time. round trip time.
For most modern TCP connections, SND.WND and RCV.WND are the size of For most modern TCP connections, SND.WND and RCV.WND are the size of
the corresponding send and receive socket buffers, and are the corresponding send and receive socket buffers, and are
skipping to change at page 5, line 29 skipping to change at page 5, line 35
SND.WND determines how much data the sender is willing to store on SND.WND determines how much data the sender is willing to store on
its side for possible retransmission due to loss, and RCV.WND its side for possible retransmission due to loss, and RCV.WND
determines the ability of the receiver to accommodate that loss and determines the ability of the receiver to accommodate that loss and
reorder received packets. CWND never grows beyond RCV.WND. reorder received packets. CWND never grows beyond RCV.WND.
High bandwidth-delay product networks need CWND to be sufficiently High bandwidth-delay product networks need CWND to be sufficiently
large to accommodate as much data would be in transit in a round trip 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 time, otherwise their performance will suffer. As a result, it is
recommended that users and various automatic programs increase recommended that users and various automatic programs increase
RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay
product) [20][32]. product) [21][34].
As the bandwidth-delay product of the network increases, however, As the bandwidth-delay product of the network increases, however,
such increases in the advertised receive window can cause increased such increases in the advertised receive window can cause increased
susceptibility to spoofing attacks, as the remainder of this document susceptibility to spoofing attacks, as the remainder of this document
shows. This assumes, however, that the receive window size (e.g., shows. This assumes, however, that the receive window size (e.g.,
via increased receive socket buffer configuration) is increased with via increased receive socket buffer configuration) is increased with
the increased bandwidth-delay product; if not, then connection the increased bandwidth-delay product; if not, then connection
performance will degrade, but susceptibility to spoofing attacks will performance will degrade, but susceptibility to spoofing attacks will
increase only linearly (with the rate of the attacker to send spoofed increase only linearly (with the rate at which the attacker can send
packets), not as the square of the bandwidth. Note that either spoofed packets), not as the square of the bandwidth. Note that
increase depends on the receive window itself, and is independent of either increase depends on the receive window itself, and is
the congestion state or amount of data transmitted. independent of the congestion state or amount of data transmitted.
2.2. Recent BGP Attacks Using TCP RSTs 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 [31]. that peer [33].
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 [18]. Most TCP connections are protected by multiple parameters [19]. 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 attempt to guess (e.g., by external knowledge or
useful. brute force) the above information is unlikely to be 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 can be well-known, or guessable using only case). Both endpoints can be well-known, or guessed using hints
hints from part of an AS path. The destination port is typically from part of an AS path. The destination port is typically fixed to
fixed to indicate the BGP service. The source port used by a BGP indicate the BGP service. The source port used by a BGP router is
router is sometimes fixed and advertised to enable firewall sometimes fixed and advertised to enable firewall configuration; even
configuration; even when not fixed, there are only approximately when not fixed, there are only approximately 65,000 valid source
65,000 valid source ports which may be exhaustively attacked. ports which may be exhaustively attacked. Connections are long-
Connections are long-lived, and as noted before some BGP lived, and as noted before some BGP implementations interpret
implementations interpret successive TCP connection failures as successive TCP connection failures as routing failures, discarding
routing failures, discarding the corresponding routing information. the corresponding routing information. In addition, the valid
In addition, the valid sequence number space once thought to provide sequence number space once thought to provide some protection has
some protection has been rendered useless by increasing advertised been significantly weakened by increasing advertised receive window
receive window sizes. sizes.
2.3. 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 [4][11]. ACK
can cause connections to transmit too much data too quickly, creating spoofing can cause connections to transmit too much data too quickly,
network congestion and segment loss, causing connections to slow to a creating network congestion and segment loss, causing connections to
crawl. In the most recent attacks on BGP, RSTs cause connections to slow to a crawl. In the most recent attacks on BGP, RSTs cause
be dropped. As noted earlier, some BGP implementations interpret TCP connections to be dropped. As noted earlier, some BGP
connection termination, or a series of such failures, as a network implementations interpret TCP connection termination, or a series of
failure [31]. This causes routers to drop the BGP routing such failures, as a network failure [33]. This causes routers to
information already exchanged, in addition to inhibiting their drop the BGP routing information already exchanged, in addition to
ongoing exchanges, thus amplifying the impact of the attack. The inhibiting their ongoing exchanges, thus amplifying the impact of the
result can affect routing paths throughout the Internet. attack. The 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 [8]. In this case, connection, known as TIME_WAIT assassination [8]. 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 [11]. and that RSTs are not blocked in the TIME_WAIT state [12].
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 [13]. This is effectively an on-path RST attack in which performance, as noted in RFC 3360 [14]. This is effectively an on-
the RSTs are sent for benign or beneficial intent. There are path RST attack in which the RSTs are sent for benign or beneficial
numerous hazards with such use of RSTs, outlined in that RFC. intent. There are numerous hazards with such use of RSTs, outlined
in that RFC.
2.4. What Changed - the Ever Opening Advertised Receive Window 2.4. What Changed - the Ever Opening Advertised Receive Window
RSTs represent a hazard to TCP, especially when completely RSTs represent a hazard to TCP, especially when completely
unvalidated. Fortunately, there are a number of obfuscation unvalidated. Fortunately, there are a number of obfuscation
mechanisms that make it difficult for off-path third parties to forge mechanisms that make it difficult for off-path third parties to forge
(spoof) valid RSTs, as noted earlier. We have already shown it is (spoof) valid RSTs, as noted earlier. We have already shown it is
easy to learn both endpoint addresses and ports for some protocols, easy to learn both endpoint addresses and ports for some protocols,
notably BGP. The final obfuscation is the segment sequence number. notably BGP. The final obfuscation is the segment sequence number.
skipping to change at page 7, line 44 skipping to change at page 8, line 7
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
[20][30]. The valid advertised receive window is a fraction, not to [21][32]. The valid advertised receive window is a fraction, not to
exceed approximately half, of this space, or ~2 billion (2 * 10^9, exceed approximately half, of this space, or ~2 billion (2 * 10^9,
i.e., 2E9 or 2 U.S. billion). Under typical configurations, the i.e., 2E9 or 2 U.S. billion). Under typical configurations, the
majority of TCP connections open to a very small fraction of this majority of TCP connections open to a very small fraction of this
space, e.g., 10,000-60,000(approximately 5-100 segments). This is space, e.g., 10,000-60,000(approximately 5-100 segments). This is
because the advertised receive window typically matches the receive because the advertised receive window typically matches the receive
socket buffer size. It is recommended that this buffer be tuned to socket buffer size. It is recommended that this buffer be tuned to
match the needs of the connection, either manually or by automatic match the needs of the connection, either manually or by automatic
external means [32]. external means [34].
On a low-loss path, the advertised receive window should be On a low-loss path, the advertised receive window should be
configured to match the path bandwidth-delay product, including configured to match the path bandwidth-delay product, including
buffering delays (assume 1 packet/hop) [32]. Many paths in the buffering delays (assume 1 packet/hop) [34]. Many paths in the
Internet have end-to-end bandwidths of under 1 Mbps, latencies under Internet have end-to-end bandwidths of under 1 Mbps, latencies under
100ms, and are under 15 hops, resulting in fairly small advertised 100ms, and are under 15 hops, resulting in fairly small advertised
receive windows as above (under 35,000 bytes). Under these receive windows as above (under 35,000 bytes). Under these
conditions, and further assuming that the initial sequence number is conditions, and further assuming that the initial sequence number is
suitably (pseudo-randomly) chosen, a valid guessed sequence number suitably (pseudo-randomly) chosen, a valid guessed sequence number
would have odds of 1 in 57,000 of falling within the advertised would have odds of 1 in 57,000 of falling within the advertised
receive window. Put differently, a blind (i.e., off-path) attacker receive window. Put differently, a blind (i.e., off-path) attacker
would need to send 57,000 RSTs with suitably spaced sequence number would need to send 57,000 RSTs with suitably spaced sequence number
guesses to successfully reset a connection. At 1 Mbps, 57,000 (40 guesses to successfully reset a connection. At 1 Mbps, 57,000 (40
byte) RSTs would take over 50 minutes to transmit, and, as noted byte) RSTs would take over 50 minutes to transmit, and, as noted
skipping to change at page 9, line 44 skipping to change at page 10, line 16
------------------------------------------------------------ ------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second 10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds 3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour 300 Kbps 0.004 MB 1,073,742 1 hour
Figure 2 Time needed to kill a connection with limited buffers Figure 2 Time needed to kill a connection with limited buffers
The issue of the attack bandwidth is considered reasonable as The issue of the attack bandwidth is considered reasonable as
follows: follows:
5. 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)
6. 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
7. 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 and Mitigations 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
skipping to change at page 10, line 35 skipping to change at page 11, line 9
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 and on- authentication of segments, protecting against both off-path and on-
path third-party spoofing attacks. Other transport protocols, such path third-party spoofing attacks. Other transport protocols, such
as SCTP and DCCP, also have limited antispoofing mechanisms. as SCTP and DCCP, also have limited antispoofing mechanisms.
3.1.1. TCP MD5 Authentication 3.1.1. TCP MD5 Authentication
An extension to TCP supporting MD5 authentication was developed in An extension to TCP supporting MD5 authentication was developed in
1998 specifically to authenticate BGP connections (although it can be 1998 specifically to authenticate BGP connections (although it can be
used for any TCP connection) [18]. The extension relies on a pre- used for any TCP connection) [19]. The extension relies on a pre-
shared secret key to authenticate the entire TCP segment, including shared secret key to authenticate the entire TCP segment, including
the data, TCP header, and TCP pseudo-header (certain fields of the IP the data, TCP header, and TCP pseudo-header (certain fields of the IP
header). All segments are protected, including RSTs, to be accepted header). All segments are protected, including RSTs, to be accepted
only when their signature matches. This option, although widely only when their signature matches. This option, although widely
deployed in Internet routers, is considered undeployable for deployed in Internet routers, is considered undeployable for
widespread use because the need for pre-shared keys [3][26]. It widespread use because the need for pre-shared keys [3][27]. It
further is considered computationally expensive for either hosts or further is considered computationally expensive for either hosts or
routers due to the overhead of MD5 [36][37]. routers due to the overhead of MD5 [39][40].
There are also concerns about the use of MD5 due to recent collision- There are also concerns about the use of MD5 due to recent collision-
based attacks [19]. Similar concerns exist for SHA-1, and the IETF based attacks [20]. Similar concerns exist for SHA-1, and the IETF
is currently evaluating how these attacks impact the recommendation is currently evaluating how these attacks impact the recommendation
for using these hashes, both in TCP/MD5 and in the IPsec suite. For for using these hashes, both in TCP/MD5 and in the IPsec suite. For
the purposes of this discussion, the particular algorithm used in the purposes of this discussion, the particular algorithm used in
either protocol suite is not the focus, and there is ongoing work to either protocol suite is not the focus, and there is ongoing work to
allow TCP/MD5 to evolve to a more general TCP security option [6]. allow TCP/MD5 to evolve to a more general TCP security option [6].
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 [33]. This restores TCP's match the expected next sequence number [36]. 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 brute-force guess the sequence number
this makes TCP's vulnerability to attack independent of the size of (worst case, average would be half that); this makes TCP's
the receive window (RCV.WND). The extension further modifies the RST vulnerability to attack independent of the size of the receive window
receiver to react to incorrectly-numbered RSTs, by sending a zero- (RCV.WND). The extension further modifies the RST receiver to react
length ACK. If the RST source is legitimate, upon receipt of an ACK to incorrectly-numbered RSTs, by sending a zero-length ACK. If the
the closed source would presumably emit a RST with the sequence RST source is legitimate, upon receipt of an ACK the closed source
number matching the ACK, correctly resetting the intended recipient. would presumably emit a RST with the sequence number matching the
This modification changes TCP's control processing, adding to its ACK, correctly resetting the intended recipient. This modification
complexity and thus potentially affecting its correctness (in changes TCP's control processing, adding to its complexity and thus
contrast to adding MD5 signatures, which is orthogonal to TCP control potentially affecting its correctness (in contrast to adding MD5
processing altogether). For example, there may be complications signatures, which is orthogonal to TCP control processing
between RSTs of different connections between the same pair of altogether). For example, there may be complications between RSTs of
endpoints because RSTs flush the TIME-WAIT (as mentioned earlier). different connections between the same pair of endpoints because RSTs
Further, this proposal modifies TCP so that under some circumstances flush the TIME-WAIT (as mentioned earlier). Further, this proposal
a RST causes a reply (an ACK), in violation of generally accepted modifies TCP so that under some circumstances a RST causes a reply
practice, if not gentle recommendation - although this can be (an ACK), in violation of generally accepted practice, if not gentle
omitted, allowing timeouts to suffice. The advantage to this recommendation - although this can be omitted, allowing timeouts to
proposal is that it can be deployed incrementally and has benefit to suffice. The advantage to this proposal is that it can be deployed
the endpoint on which it is deployed. The other advantage to this incrementally and has benefit to the endpoint on which it is
proposal is that the window attenuation described here makes the deployed. The other advantage to this proposal is that the window
vulnerability to spoofed RST packets independent of the size of the attenuation described here makes the vulnerability to spoofed RST
receive window. packets independent of the size of the receive window.
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 [35][41]. This the value negotiated on connection establishment [38][44]. This
proposal has the advantage of using an explicitly negotiated value, proposal has the advantage of using an explicitly negotiated value,
but at the cost of changing the behavior of an unmodified endpoint to but at the cost of changing the behavior of an unmodified endpoint to
a 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.
Another variant of this proposal involves increasing TCP's window Another variant of this proposal involves increasing TCP's window
space, rather than decreasing the valid range for RSTs, i.e., space, rather than decreasing the valid range for RSTs, i.e.,
increasing the sequence space from 32 bits to 64 bits. This has the increasing the sequence space from 32 bits to 64 bits. This has the
equivalent effect - the ratio of the valid sequence numbers for any equivalent effect - the ratio of the valid sequence numbers for any
segment to the overall sequence number space is significantly segment to the overall sequence number space is significantly
skipping to change at page 12, line 21 skipping to change at page 12, line 40
A converse variant of increasing TCP's window space is to decrease A converse variant of increasing TCP's window space is to decrease
the receive window (RCV.WND) explicitly, which would further reduce the receive window (RCV.WND) explicitly, which would further reduce
the effectiveness of spoofed RSTs with random sequence numbers. This the effectiveness of spoofed RSTs with random sequence numbers. This
alternative may reduce the throughput of the connection, if the alternative may reduce the throughput of the connection, if the
advertised receive window is smaller than the bandwidth-delay product advertised receive window is smaller than the bandwidth-delay product
of the connection. of the connection.
3.1.3. TCP Timestamp Authentication 3.1.3. TCP Timestamp Authentication
Another way to authenticate TCP segments is via its timestamp option, Another way to authenticate TCP segments is via its timestamp option,
using the value as a sort of authentication [29]. This requires that using the value as a sort of authentication [31]. This requires that
the receiver TCP discard values whose timestamp is outside the the receiver TCP discard segments whose timestamp is outside the
accepted window, which is derived from the timestamps of other accepted window, which is derived from the timestamps of other
packets from the same connection. This technique uses an existing packets from the same connection. This technique uses an existing
TCP option, but also requires modified TCP control processing (with TCP option, but also requires modified TCP control processing (with
the same caveats) and may be difficult to deploy incrementally the same caveats) and may be difficult to deploy incrementally
without further modifications. Additionally, the timestamp value may without further modifications. Additionally, the timestamp value may
be easier to guess because if is derived predictably. be easier to guess because it can be derived predictably, either
assuming it represents actual time at the host, or by probing the
host using unrelated benign traffic.
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 on-path snooping, because they are dependent not predictable based on on-path snooping, because they are dependent
on packet data and thus do not repeat. Window attenuation sequence on packet data and thus do not repeat. Window attenuation sequence
numbers can be guessed by snooping the sequence number of current numbers can be guessed by snooping the sequence number of current
packets, and timestamps can be guessed even more remotely. These packets of an existing connection, and timestamps can be guessed even
variants of cookies are similar in spirit to TCP SYN cookies, again less directly, either by separate benign connections or by assuming
patching a vulnerability to off-path third-party spoofing attacks reasonably correlation to local time. These variants of cookies are
based on a (fairly weak, excepting MD5) form of authentication. similar in spirit to TCP SYN cookies, again patching a vulnerability
Another form of cookie is the source port itself, which can be to off-path third-party spoofing attacks based on a (fairly weak,
randomized but provides only 16 bits of protection (65,000 excepting MD5) form of authentication. Another form of cookie is the
combinations), which may be exhaustively attacked. This can be source port itself, which can be randomized but provides only 16 bits
combined with destination port randomization as well, but that would of protection (65,000 combinations), which may be exhaustively
require a separate coordination mechanism (so both parties know which attacked. This can be combined with destination port randomization
ports to use), which is equivalent to (and as infeasible for large- as well, but that would require a separate coordination mechanism (so
scale deployments as) exchanging a shared secret. both parties know which ports to use), which is equivalent to (and as
infeasible for large-scale deployments as) exchanging a shared secret
[35].
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
advertised receive window is opened to the maximum extent suggested advertised receive window is opened to the maximum extent suggested
by the bandwidth-delay product of the end-to-end path, and that the by the bandwidth-delay product of the end-to-end path, and that the
window is opened to an appreciable fraction of the overall sequence window is opened to an appreciable fraction of the overall sequence
number space. As noted earlier, for most common cases, connections number space. As noted earlier, for most common cases, connections
are too brief or over bandwidths too low for such a large window to are too brief or over bandwidths too low for such a large window to
be useful. Expanding TCP's sequence number space is a direct way to be useful. Expanding TCP's sequence number space is a direct way to
further avoid such vulnerability, even for long connections over further avoid such vulnerability, even for long connections over
emerging bandwidths. If either manual tuning or automatic tuning of emerging bandwidths. If either manual tuning or automatic tuning of
the advertised receive window (via receive buffer tuning) is not the advertised receive window (via receive buffer tuning) is not
provided, this is not an issue (although connection performance will provided, this is not an issue (although connection performance will
suffer) [32]. suffer) [34].
It is may be sufficient for the endpoint to limit the advertised It is may be sufficient for the endpoint to limit the advertised
receive window by deliberately leaving it small. If the receive receive window by deliberately leaving it small. If the receive
socket buffer is limited, e.g., to the ubiquitous default of 64KB, socket buffer is limited, e.g., to the ubiquitous default of 64KB,
the advertised receive window will not be as vulnerable even for very the advertised receive window will not be as vulnerable even for very
long connections over very high bandwidths. The vulnerability will long connections over very high bandwidths. The vulnerability will
grow linearly with the increased network speed, but not as the grow linearly with the increased network speed, but not as the
square. The consequence is lower sustained throughput, where only square. The consequence is lower sustained throughput, where only
one window's worth of data per round trip time (RTT) is exchanged. one window's worth of data per round trip time (RTT) is exchanged.
This will keep the connection open longer; for long-lived connections This will keep the connection open longer; for long-lived connections
skipping to change at page 13, line 49 skipping to change at page 14, line 24
exchanged quickly enough with bandwidth reduced due to the smaller exchanged quickly enough with bandwidth reduced due to the smaller
buffers, or perhaps that the advertised receive window is opened only buffers, or perhaps that the advertised receive window is opened only
during a large burst exchange (e.g., via some other signal between during a large burst exchange (e.g., via some other signal between
the two routers). 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 use them to authenticate a variety of other control establishment and use them to authenticate a variety of other control
messages [25][34]. The inclusion of such mechanism at the transport messages [26][37]. The inclusion of such mechanism at the transport
protocol, although emerging as standard practice, complicates the protocol, although emerging as standard practice, complicates the
design and implementation of new protocols [27]. As new attacks are design and implementation of new protocols [29]. As new attacks are
discovered (SYN floods, RSTs, etc.), each protocol must be modified discovered (SYN floods, RSTs, etc.), each protocol must be modified
individually to compensate. A network solution may be more individually to compensate. A network solution may be more
appropriate and efficient. appropriate and efficient.
It should be noted that RST attacks which rely on brute-force are
relatively easy for intrusion detection software to detect at the TCP
layer. Any connection that receives a large number of invalid -
outside-window - RSTs might have subsequent RSTs blocked, to defeat
such attacks. This would have the side-effect of blocking legitimate
RSTs to that connection, which might then interfere with cleaning up
the transport state between the endpoint peers. This side-effect,
coupled with the increased monitoring load, might render such
solutions undesirable in the general case, but they might usefully be
applied to special cases, e.g., for BGP for routers.
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: address filtering and IPsec. Address 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. Address filtering 3.2.1. Address filtering
Address 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 [2][12]. Address mechanisms to defeat IP source address spoofing [2][13]. 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 can also restrict core- networks based on the IP source address. It can also restrict core-
to-edge paths to reject traffic that should have originated further to-edge paths to reject traffic that should have originated further
toward the edge. It cannot restrict traffic from edges lacking toward the edge. It cannot restrict traffic from edges lacking
filtering through the core to a particular edge, i.e., from upstream filtering through the core to a particular edge, i.e., from upstream
sources. As a result, each border router must perform the sources. As a result, each border router must perform the
appropriate filtering for overall protection to result; failure of appropriate filtering for overall protection to result; failure of
any border router to filter defeats the protection of all any border router to filter defeats the protection of all
participants inside the border, ultimately. Address filtering at the participants inside the border, ultimately. Address filtering at the
border can protect those inside the border from some kinds of border can protect those inside the border from some kinds of
skipping to change at page 14, line 45 skipping to change at page 15, line 32
border. It cannot, however, protect connections originating outside border. It cannot, however, protect connections originating outside
the border except to restrict where the traffic enters from, e.g., if the border except to restrict where the traffic enters from, e.g., if
it expected from one AS and not another. it expected from one AS and not another.
As a result, address 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
[28].
A more recent variant of address 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 [14]. This relying on the TTL set by the other end of the connection [15]. 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 (i.e., a BGP router), but those to one hop upstream of the receiver (i.e., a BGP router), but those
hops could include other user programs at those nodes (e.g., the BGP hops could include other user programs at those nodes (e.g., the BGP
router's peer) or any traffic those nodes accept via tunnels - router's peer) or any traffic those nodes accept via tunnels -
because tunnels need not decrement TTLs [28] (see Sec. 5.1 of [14]). because tunnels need not decrement TTLs [30] (see Sec. 5.1 of [15]).
This method works only where all traffic from the other end of the This method works only where all traffic from the other end of the
tunnel is trusted, i.e., where it does not originate or transit tunnel is trusted, i.e., where it does not originate or transit
spoofed traffic. The use of TTL rather than link or network security spoofed traffic. The use of TTL rather than link or network security
also assumes an untampered point-to-point link, where no other also assumes an untampered point-to-point link, where no other
traffic can be spoofed onto a link. traffic can be spoofed onto a link.
This method of filtering works best where traffic originates one hop This method of filtering works best where traffic originates one hop
away, so that the address filtering is based on the trust of only away, so that the address filtering is based on the trust of only
directly-connected (tunneled or otherwise) nodes. Like conventional directly-connected (tunneled or otherwise) nodes. Like conventional
address filtering, this reduces spoofing traffic in general, but is address filtering, this reduces spoofing traffic in general, but is
skipping to change at page 15, line 48 skipping to change at page 16, line 38
many end-system operating systems. More importantly, it relies on many end-system operating systems. More importantly, it relies on
preshared keys, signed X.509 certificates, or a third-party (e.g., preshared keys, signed X.509 certificates, or a third-party (e.g.,
Kerberos) public key infrastructure to establish and exchange keying 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).
These keying challenges are being addressed in the IETF in ways that These keying challenges are being addressed in the IETF in ways that
will enable servers secure associations with other parties without will enable servers secure associations with other parties without
advance coordination [38][39]. This can be especially useful for advance coordination [41][42]. This can be especially useful for
publicly-available servers, or for protecting connections to servers publicly-available servers, or for protecting connections to servers
that - for whatever reason - have not, or will not deploy that - for whatever reason - have not, or will not deploy
conventional IPsec certificates (i.e., core Internet BGP routers). conventional IPsec certificates (i.e., core Internet BGP routers).
4. ICMP 4. ICMP
Just as spoofed TCP packets can kill a connection, so too can spoofed Just as spoofed TCP packets can terminate a connection, so too can
ICMP packets. TCP headers can occur inside certain ICMP messages spoofed ICMP packets. TCP headers can be included inside certain
[7]. There have been recent suggestions to validate the sequence ICMP messages [7]. There have been recent suggestions to validate
number of TCP headers when they occur inside ICMP messages [16]. the sequence number of TCP headers when they occur inside ICMP
This sequence checking is similar to checks that would occur for messages [17]. This sequence checking is similar to checks that
conventional data packets in TCP, but is being proposed in the spirit would occur for conventional data packets in TCP, but is being
of the RST window attenuation described in Section 3.1.2. 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 Some such checks may be reasonable, especially where they parallel
the validations already performed by TCP processing, notably where the validations already performed by TCP processing, notably where
they emulate the semantics of such processing. For example, the TCP they emulate the semantics of such processing. For example, the TCP
checksum should be validated (if the entire TCP segment is contained checksum should be validated (if the entire TCP segment is contained
in the ICMP message) before any fields of the TCP header are in the ICMP message) before any fields of the TCP header are
examined, to avoid reacting to corrupted packets. Similarly, if the examined, to avoid reacting to corrupted packets. Similarly, if the
TCP MD5 option is present, its signature should probably be validated TCP MD5 option is present, its signature should probably be validated
before considering the contents of the message. before considering the contents of the message.
skipping to change at page 17, line 25 skipping to change at page 18, line 19
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 protocols 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 [4][33]. window attenuation [4][36].
Transport layer solutions are not only per-protocol, but often per- Transport layer solutions are not only per-protocol, but often per-
connection. This has both advantages and drawbacks. One advantage connection. This has both advantages and drawbacks. One advantage
to transport layer solutions is that they can protect the transport to transport layer solutions is that they can protect the transport
protocol when lower layers have failed, e.g., due to bugs in protocol when lower layers have failed, e.g., due to bugs in
implementation. TCP already includes a variety of packet validation implementation. TCP already includes a variety of packet validation
mechanisms to protect in these cases, e.g., checking that RSTs are mechanisms to protect in these cases, e.g., checking that RSTs are
in-window. More strict checks can increase the protections provided, in-window. More strict checks can increase the protections provided,
e.g., to protect against misaddressed RSTs that end up in-window (via e.g., to protect against misaddressed RSTs that end up in-window (via
TCPsecure) or to protect against connection interruption due to RSTs, TCPsecure) or to protect against connection interruption due to RSTs,
SYNs, or data injection from misaddressed packets (TCP/MD5). SYNs, or data injection from misaddressed packets (TCP/MD5) [36].
Another advantage is that TCP layer protections can be more Another advantage is that transport layer protections can be more
specifically limited to a particular connection. Because each specifically limited to a particular connection. Because each
connection negotiates its state separately, that state can be more connection negotiates its state separately, that state can be more
specifically tied to that connection. This is both an advantage and specifically tied to that connection. This is both an advantage and
a drawback. It can make it easier to tie security to an individual a drawback. It can make it easier to tie security to an individual
connection, although in practice a shared secret or certificate will connection, although in practice a shared secret or certificate will
generally be shared across multiple connections. generally be shared across multiple connections.
As a drawback, each transport connection needs to negotiate and As a drawback, each transport connection needs to negotiate and
maintain authentication state separately. Some overhead is not maintain authentication state separately. Some overhead is not
amortized over multiple connections, e.g., overheads in packet amortized over multiple connections, e.g., overheads in packet
skipping to change at page 18, line 37 skipping to change at page 19, line 29
packets it emits. Such a network level solution protects all packets it emits. Such a network level solution protects all
transport protocols as a result, including both legacy and emerging transport protocols as a result, including both legacy and emerging
protocols, and reduces the complexity of these protocols as well. A protocols, and reduces the complexity of these protocols as well. A
shared solution also reduces protocol overhead, and decouples the shared solution also reduces protocol overhead, and decouples the
management (and refreshing) of authentication state from that of management (and refreshing) of authentication state from that of
individual transport connections. Finally, a network layer solution individual transport connections. Finally, a network layer solution
protects not only the transport layer but the network layer as well, protects not only the transport layer but the network layer as well,
e.g., from IGMP, and some kinds of ICMP (Sec. 4), spoofing attacks. e.g., from IGMP, and some kinds of ICMP (Sec. 4), spoofing attacks.
The IETF Proposed Standard protocol for network layer authentication The IETF Proposed Standard protocol for network layer authentication
is IPsec [24]. IPsec specifies the overall architecture, including is IPsec [25]. IPsec specifies the overall architecture, including
header authentication (AH) [22] and encapsulation (ESP) modes [23]. header authentication (AH) [23] and encapsulation (ESP) modes [24].
AH authenticates both the IP header and IP data, whereas ESP AH 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 Security
sufficient information to verify the IP header anyway. These two Parameters Index (SPI) includes sufficient information to verify the
modes describe the security applied to individual packets within the IP header anyway. These two modes describe the security applied to
IPsec system; key exchange and management is performed either out-of- individual packets within the IPsec system; key exchange and
band (via pre-shared keys) or by an automated key exchange protocol management is performed either out-of-band (via pre-shared keys) or
IKE [17][21]. by an automated key exchange protocol IKE [18][22].
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 on-path and off-path third-party contents sufficient to defeat both on-path and off-path third-party
spoofing attacks. IKE can configure authentication between two spoofing attacks. IKE can configure authentication between two
endpoints on a per-endpoint, per-protocol, or per-connection basis, endpoints on a per-endpoint, per-protocol, or per-connection basis,
as desired. IKE also can perform automatic periodic re-keying, as desired. IKE also can perform automatic periodic re-keying,
further defeating crypto-analysis based on snooping (clandestine data further defeating crypto-analysis based on snooping (clandestine data
collection). The use of IPsec is already commonly strongly collection). The use of IPsec is already commonly strongly
recommended for protected infrastructure. recommended for protected infrastructure.
Existing IPsec is not appropriate for many deployments. It is Existing IPsec is not appropriate for many deployments. It is
computationally intensive both in key management and individual computationally intensive both in key management and individual
packet authentication [36]. This computational overhead can be packet authentication [39]. This computational overhead can be
prohibitive, and so often requires additional hardware, especially in prohibitive, and so often requires additional hardware, especially in
commercial routers. As importantly, IKE is not anonymous; keys can commercial routers. As importantly, IKE is not anonymous; keys can
be exchanged between parties only if they trust each others' X.509 be exchanged between parties only if they trust each others' X.509
certificates, trust some other third-party to help with key certificates, trust some other third-party to help with key
generation (e.g., Kerberos), or pre-share a key. These certificates generation (e.g., Kerberos), or pre-share a key. These certificates
provide identification (the other party knows who you are) only where provide identification (the other party knows who you are) only where
the certificates themselves are signed by certificate authorities the certificates themselves are signed by certificate authorities
(CAs) that both parties already trust. To a large extent, the CAs (CAs) that both parties already trust. To a large extent, the CAs
themselves are the pre-shared keys which help IKE establish security themselves are the pre-shared keys which help IKE establish security
association keys, which are then used in the authentication association keys, which are then used in the authentication
algorithms. algorithms.
Alternative mechanisms are under development to address this Alternative mechanisms are under development to address this
limitation, to allow publicly-accessible servers to secure limitation, to allow publicly-accessible servers to secure
connections to clients not known in advance, or to allow unilateral connections to clients not known in advance, or to allow unilateral
relaxation of identity validation so that the remaining protections relaxation of identity validation so that the remaining protections
of IPsec to be available [38][39]. In particular, these mechanisms of IPsec to be available [41][42]. In particular, these mechanisms
can prevent a client (but without knowing who that client is) from can prevent a client (but without knowing who that client is) from
being affected by spoofing from other clients, even when the being affected by spoofing from other clients, even when the
attackers are on the same communications path. attackers are on the same 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 used except between parties that commodity end-systems, is not often used except between parties that
already have a preexisting relationship (employee/employer, between already have a preexisting relationship (employee/employer, between
two ISPs, etc.). Servers to anonymous clients (e.g., customer/ two ISPs, etc.). Servers to anonymous clients (e.g., customer/
business) or more open services (e.g., BGP, where routers may have business) or more open services (e.g., BGP, where routers may have
large numbers of peers) are unmanageable, due to the breadth and flux large numbers of peers) are unmanageable, due to the breadth and flux
skipping to change at page 20, line 26 skipping to change at page 21, line 18
An alternate application layer solution would involve resilience to An alternate application layer solution would involve resilience to
reset connections. If the application can recover from such reset connections. If the application can recover from such
connection interruptions, then such attacks have less impact. connection interruptions, then such attacks have less impact.
Unfortunately, attackers still affect the application, e.g., in the Unfortunately, attackers still affect the application, e.g., in the
cost of restarting connections, delays until connections are cost of restarting connections, delays until connections are
restarted, or increased connection establishment messages on the restarted, or increased connection establishment messages on the
network. Some applications - notably BGP - even interpret TCP network. Some applications - notably BGP - even interpret TCP
connection reliability as an indicator of route path stability, which connection reliability as an indicator of route path stability, which
is why attacks on BGP have such substantial consequences. is why attacks on BGP have such substantial consequences.
5.4. Shim Transport/Application Layer 5.4. Link Layer
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.
These protocols provide data protection for a variety of applications
over a single, legacy transport protocol, such as SSL/TCP for HTTPS.
Unfortunately, as with application authentication, they do not
protect the transport layer against spoofing attacks.
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.
5.6. Issues Discussion 5.5. 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, there 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, SHA1, etc., for IPsec already supports a variety of algorithms (MD5, SHA1, etc., for
authentication), but always assumes that: authentication), but always assumes that:
skipping to change at page 21, line 28 skipping to change at page 22, line 11
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 spoof attacks, but not addressing on- against off-path third-party spoof attacks, but not addressing on-
path attacks at all. Such potential solutions are discussed in the path attacks at all. Such potential solutions are discussed in the
BTNS document [5][38][39]. Note also that NULL Encryption in IPsec BTNS documents [5][41][42]. Note also that NULL Encryption in IPsec
applies a variant of this cookie, where the SPI is the cookie, and no applies a variant of this cookie, where the SPI is the cookie, and no
further encryption is applied [15]. further encryption is applied [16].
6. 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 on- implicit (e.g., window sequence attenuation) do not protect from on-
skipping to change at page 22, line 25 skipping to change at page 23, line 9
8. Conclusions 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.
9. Acknowledgments 9. Acknowledgments
This document was inspired by discussions on the This document was inspired by discussions in the TCPM WG
<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) [33][35]. The analysis of draft (which is now edited by M. Dalal) [36][38]. The analysis of
the 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. R. well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. R.
Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested
using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to
validate RSTs. Other improvements are due to the input of various validate RSTs. Other improvements are due to the input of various
members of the IETF's TCPM WG, notably detailed feedback from P. members of the IETF's TCPM WG, notably detailed feedback from P.
Savola. Savola.
10. References 10. References
skipping to change at page 23, line 35 skipping to change at page 24, line 20
[9] CERT alert: "Technical Cyber Security Alert TA04-111A: [9] 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.
[10] Convery, S. and M. Franz, "BGP Vulnerability Testing: [10] 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
[11] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP [11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations,"
draft-eddy-syn-flood-02.txt (work in progress), April 2006.
[12] 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, Mar. 1999. 1583, Mar. 1999.
[12] Ferguson, P. and D. Senie, Network Ingress Ingress Filtering: [13] 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 2827 / BCP 38, May 2000. Spoofing," RFC 2827 / BCP 38, May 2000.
[13] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP [14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
60, RFC 3360, Aug. 2002. 60, RFC 3360, Aug. 2002.
[14] Gill, V., J. Heasley, and D. Meyer, "The Generalized TTL [15] 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.
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its [16] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410 (Standards Track), Nov. 1998. Use With IPsec", RFC 2410 (Standards Track), Nov. 1998.
[16] Gont, F., "ICMP attacks against TCP," draft-gont-tcpm-icmp- [17] Gont, F., "ICMP attacks against TCP," draft-gont-tcpm-icmp-
attacks-05.txt, (work in progress), Oct. 2005. attacks-05.txt, (work in progress), Oct. 2005.
[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [18] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409 (Standards Track), Nov. 1998. RFC 2409 (Standards Track), Nov. 1998.
[18] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [19] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385 (Standards Track), Aug. 1998. Signature Option", RFC 2385 (Standards Track), Aug. 1998.
[19] Housley, R., Post to IETF Discussion mailing list regarding his [20] Housley, R., Post to IETF Discussion mailing list regarding his
IETF 64 Security Area presentation, IETF 64 Security Area presentation,
ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24, ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24,
2005, http://www1.ietf.org/mail- 2005, http://www1.ietf.org/mail-
archive/ietf/Current/maillist.html archive/ietf/Current/maillist.html
[20] Jacobson, V., B. Braden, and D. Borman, "TCP Extensions for [21] Jacobson, V., B. Braden, and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[21] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306 [22] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306
(Standards Track), Dec. 2005. (Standards Track), Dec. 2005.
[22] Kent, S., "IP Authentication Header", RFC 4302 (Standards [23] Kent, S., "IP Authentication Header", RFC 4302 (Standards
Track), Dec. 2005. Track), Dec. 2005.
[23] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 4303 [24] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 4303
(Standards Track), Dec. 2005. (Standards Track), Dec. 2005.
[24] Kent, S. and K. Seo, "Security Architecture for the Internet [25] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, Dec. 2005. Protocol", RFC 4301, Dec. 2005.
[25] 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-13 (work in Control Protocol (DCCP)", draft-ietf-dccp-spec-13 (work in
progress), Dec. 2005. progress), Dec. 2005.
[26] 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.
[27] O'Malley, S. and L. Peterson, "TCP Extensions Considered [28] Moore, D., G. Voelker, and S. Savage, "Inferring Internet
Denial-of-Service Activity," Proc. Usenix Security Symposium,
Aug. 2001.
[29] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991. Harmful", RFC 1263, October 1991.
[28] Perkins, C., "IP Encapsulation within IP," RFC 2003 (Standards [30] Perkins, C., "IP Encapsulation within IP," RFC 2003 (Standards
Track), Oct. 1996. Track), Oct. 1996.
[29] Poon, K., "Use of TCP timestamp option to defend against blind [31] Poon, K., "Use of TCP timestamp option to defend against blind
spoofing attack," draft-poon-tcp-tstamp-mod-01 (expired work in spoofing attack," draft-poon-tcp-tstamp-mod-01 (expired work in
progress), Oct. 2004. progress), Oct. 2004.
[30] Postel, J., "Transmission Control Protocol," RFC 793 / STD 7, [32] Postel, J., "Transmission Control Protocol," RFC 793 / STD 7,
Sep. 1981. Sep. 1981.
[31] Rekhter, Y. and T. Li, (eds.), "A Border Gateway Protocol 4 [33] Rekhter, Y. and T. Li, (eds.), "A Border Gateway Protocol 4
(BGP-4)," RFC 1771 (Standards Track), Mar. 1995. (BGP-4)," RFC 1771 (Standards Track), Mar. 1995.
[32] Semke, J., J. Mahdavi, M. Mathis, "Automatic TCP Buffer [34] Semke, J., J. Mahdavi, M. Mathis, "Automatic TCP Buffer
Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume
28, number 4, Oct. 1998. 28, number 4, Oct. 1998.
[33] Stewart, R. and M. Dalal, "Improving TCP's Robustness to Blind [35] Shepard, T., "Reassign Port Number option for TCP," draft-
sheard-tcp-reassign-port-number-00.txt (work in progress), Jul.
2004.
[36] Stewart, R. and M. Dalal, "Improving TCP's Robustness to Blind
In-Window Attacks", draft-ietf-tcpm-tcpsecure-04 (work in In-Window Attacks", draft-ietf-tcpm-tcpsecure-04 (work in
progress), Feb. 2005. progress), Feb. 2005.
[34] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, [37] 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), Oct. 2000. Track), Oct. 2000.
[35] TCPM: IETF TCPM Working Group and mailing list, [38] 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.
[36] Touch, J., "Report on MD5 Performance," RFC 1810 [39] Touch, J., "Report on MD5 Performance," RFC 1810
(Informational), Jun. 1995. (Informational), Jun. 1995.
[37] Touch, J., "Performance Analysis of MD5," Proc. Sigcomm 1995 [40] Touch, J., "Performance Analysis of MD5," Proc. Sigcomm 1995
pp. 77-86, Mar. 1999. pp. 77-86, Mar. 1999.
[38] Touch, J., "ANONsec: Anonymous Security to Defend Against [41] Touch, J., "ANONsec: Anonymous Security to Defend Against
Spoofing Attacks," draft-touch-anonsec-00 (expired work in Spoofing Attacks," draft-touch-anonsec-00 (expired work in
progress), May 2004. progress), May 2004.
[39] Touch, J., D. Black, and Y. Wang, "Problem and Applicability [42] Touch, J., D. Black, and Y. Wang, "Problem and Applicability
Statement for Better Than Nothing Security (BTNS)," Statement for Better Than Nothing Security (BTNS),"
draft-ietf-btns-prob-and-applic-02 (work in progress), Feb. draft-ietf-btns-prob-and-applic-02 (work in progress), Feb.
2006. 2006.
[40] Watson, P., "Slipping in the Window: TCP Reset attacks," [43] 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 [44] Wood, L., Post to TCPM mailing list regarding use of ISN in
RSTs, ID=Pine.GSO.4.50.0404232249570.5889- RSTs, ID=Pine.GSO.4.50.0404232249570.5889-
100000@argos.ee.surrey.ac.uk, Apr. 23, 2004. 100000@argos.ee.surrey.ac.uk, Apr. 23, 2004.
http://www1.ietf.org/mail- http://www1.ietf.org/mail-
archive/web/tcpm/current/msg00213.html 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
 End of changes. 104 change blocks. 
218 lines changed or deleted 244 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/