One document matched: draft-ietf-tcpm-tcp-antispoof-00.txt
IETF TCPM WG J. Touch
Internet Draft USC/ISI
Expires: August 2005 February 13, 2005
Defending TCP Against Spoofing Attacks
draft-ietf-tcpm-tcp-antispoof-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Recent analysis of potential attacks on core Internet infrastructure
indicates an increased vulnerability of TCP connections to spurious
resets (RSTs). TCP has always been susceptible to such RST spoof
attacks, which were indirectly protected by checking that the RST
sequence number was inside the current receive window, as well as via
Touch Expires August 13, 2005 [Page 1]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
the obfuscation of TCP endpoint and port numbers. For pairs of well-
known endpoints often over predictable port pairs, such as BGP or
between web servers and well-known large-scale caches, increases in
the path bandwidth-delay product of a connection have sufficiently
increased the receive window space that off-path third parties can
guess a viable RST sequence number. This document addresses this
vulnerability, discussing proposed solutions at the transport level
and their inherent challenges, as well as existing network level
solutions and the feasibility of their deployment.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction...................................................3
2. Background.....................................................4
2.1. Recent BGP Attacks Using TCP RSTs.........................4
2.2. TCP RST Vulnerability.....................................5
2.3. What Changed -- the Ever Opening Window...................5
3. Proposed solutions.............................................8
3.1. Transport Layer Solutions.................................8
3.1.1. TCP MD5 Authentication...............................8
3.1.2. TCP RST Window Attenuation...........................8
3.1.3. TCP Timestamp Authentication.........................9
3.1.4. Other TCP Cookies...................................10
3.1.5. Other TCP Considerations............................10
3.1.6. Other Transport Protocol Solutions..................11
3.2. Network Layer (IP) Solutions.............................11
4. Issues........................................................12
4.1. Transport Layer (e.g., TCP)..............................12
4.2. Network Layer (IP).......................................13
4.3. Application Layer........................................14
4.4. Shim Transport/Application Layer.........................14
4.5. Link Layer...............................................14
4.6. Conclusion...............................................15
5. Security Considerations.......................................15
6. Conclusions...................................................16
7. Acknowledgments...............................................16
8. References....................................................16
8.1. Normative References.....................................16
8.2. Informative References...................................18
Author's Addresses...............................................18
Touch Expires August 13, 2005 [Page 2]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
Intellectual Property Statement..................................19
Disclaimer of Validity...........................................19
Copyright Statement..............................................19
Acknowledgment...................................................19
1. Introduction
Analysis of the Internet infrastructure has been recently
demonstrated new version of a vulnerability in BGP connections
between core routers using an attack known for nearly six years
[3][4]. These connections, typically using TCP, can be susceptible
to off-path (non man-in-the-middle) third-party reset (RST) segments,
which terminate the TCP connection. BGP routers react to a
terminated TCP connection in various ways, ranging from restarting
the connection to deciding that the other router is unreachable and
thus flushing the BGP routes. This sort of attack affects other
protocols besides BGP, involving any long-lived connection between
well-known endpoints. The impact on Internet infrastructure can be
substantial (esp. for the BGP case), and warrants immediate
attention.
TCP, like many other protocols, can be susceptible to these off-path
third-party attacks. Such attacks rely on the increase of commodity
platforms supporting public access to previously privileged
resources, such as root-level access. Given such access, it is
trivial for anyone to generate a packet with any header desired.
This, coupled with the lack of sufficient ingress filtering to drop
such spoofed traffic, can increase the potential for off-path third-
party spoofing attacks. Proposed solutions include the deployment of
existing Internet network and transport security as well as
modifications to transport protocols that reduce its vulnerability to
generated attacks.
One way to defeat spoofing is to validate the segments of a
connection, either at the transport level or the network level. TCP
with MD5 extensions provides this authentication at the transport
level, and IPsec provides authentication at the network level. In
both cases their deployment overhead may be prohibitive, e.g., it may
not feasible for public services, such as web servers, to be
configured with the appropriate certificate authorities of large
numbers of peers (for IPsec using IKE), or shared secrets (for IPsec
in shared-secret mode, or TCP/MD5), because many clients may need to
be configured rapidly without external assistance. Services from
public web servers connecting to large-scale caches to BGP with
larger numbers of peers can experience this challege.
Touch Expires August 13, 2005 [Page 3]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
The remainder of this document outlines the recent attack scenario in
detail and describes and compares a variety of solutions, including
existing solutions based on TCP/MD5 and IPsec, as well as recently
proposed solutions, including modifications to TCP's RST processing
[24], modifications to TCP's timestamp processing [5], and
modifications to IPsec and TCP/MD5 keying [6].
2. Background
The recent analysis of potential attacks on BGP has again raised the
issue of TCP's vulnerability to off-path third-party spoofing attacks
[3]. A variety of such attacks have been known for several years,
including sending RSTs, SYNs, and even ACKs in an attempt to affect
an existing connection or to load down servers. Overall, such
attacks are countered by the use of some form of authentication at
the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or
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 in recent weeks, rendering it moot.
2.1. Recent BGP Attacks Using TCP RSTs
BGP represents a particular vulnerability to spoofing attacks. Most
TCP connections are protected by multiple levels of obfuscation
except at the endpoints of the connection:
o Both endpoint addresses are usually not well-known; although server
addresses are advertised, clients are somewhat anonymous.
o Both port numbers are usually not well-known; the server's usually
is advertised (representing the service), but the client's is
typically sufficiently unpredictable to an off-path third-party.
o Valid sequence number space is not well-known.
o Connections are relatively short-lived and valid sequence space
changes, so any guess of the above information is unlikely to be
useful.
BGP represents an exception to the above criteria (though not the
only case). Both endpoints are well-known, notably as part of an AS
path. The destination port is typically fixed to indicate the BGP
service. The source port used by a BGP router is sometimes fixed and
advertised to enable firewall configuration; even when not fixed,
there are only 65,384 valid source ports which may be exhaustively
Touch Expires August 13, 2005 [Page 4]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
attacked. Connections are long-lived, and as noted before some BGP
implementations interpret successive TCP connection failures as
routing failures, discarding the corresponding routing information.
As importantly and as will be shown below, the valid sequence number
space once thought to provide some protection has been rendered
useless by increasing congestion window sizes.
2.2. TCP RST Vulnerability
TCP has a known vulnerability to third-party spoofed segments. SYN
flooding consumes server resources in half-open connections,
affecting the server's ability to open new connections. ACK spoofing
can cause connections to transmit too much data too quickly, creating
network congestion and segment loss, causing connections to slow to a
crawl. In the most recent attacks on BGP, RSTs cause connections to
be dropped. As noted earlier, some BGP implementations interpret TCP
connection termination, or a series of such failures, as a network
failure. This causes routers to drop the BGP routing information
already exchanged, in addition to inhibiting their ongoing exchanges.
The result can affect routing paths throughout the Internet.
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
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
premature reuse of address/port pairs, potentially allowing segments
from a previous connection to contaminate the data of a new
connection, known as TIME_WAIT assassination [7]. In this case,
assassination occurs inadvertently as the result of duplicate
segments from a legitimate source, and can be avoided by blocking RST
processing while in TIME_WAIT. However, assassination can be useful
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,
and that RSTs are not blocked in the TIME_WAIT state [8].
Firewalls and load balancers, so-called 'middleboxes', sometimes emit
RSTs on behalf of transited connections to optimize server
performance [9]. This is effectively a 'man in the middle' RST
attack in which the RSTs are sent for benign or beneficial intent.
There are numerous hazards with such use of RSTs, outlined in that
RFC.
2.3. What Changed -- the Ever Opening Window
RSTs represent a hazard to TCP, especially when completely unchecked.
Fortunately, there are a number of obfuscation mechanisms that make
it difficult for off-path third parties to forge (spoof) valid RSTs,
Touch Expires August 13, 2005 [Page 5]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
as noted earlier. We have already shown it is easy to learn both
endpoint addresses and ports for some protocols, notably BGP. The
final obfuscation is the segment sequence number.
TCP segments include a sequence number which enables out-of-order
receiver processing, as well as duplicate detection. The sequence
number space is also used to manage congestion, and indicates the
index of the next byte to be transmitted or received. For RSTs, this
is relevant because legitimate RSTs use the next sequence number in
the transmitter window, and the receiver checks that incoming RSTs
have a sequence number in the expected receive window. Such
processing is intended to eliminate duplicate segments (somewhat moot
for RSTs, though), and to drop RSTs which were part of previous
connections.
TCP uses two window mechanisms, a primary mechanism which uses a
space of 32 bits, and a secondary mechanism which scales this window
[10][11]. The valid receive window is a fraction, not to exceed
approximately half, of this space, or ~2,000,000,000. Under typical
use, the majority of TCP connections open to a very small fraction of
this space, e.g., 10,000-60,000(approximately 5-100 segments). On a
low-loss path, the window should open to around the path bandwidth-
delay product, including buffering delays (assume 1 packet/hop).
Many paths in the Internet have end-to-end bandwidths of under 1
Mbps, latencies under 100ms, and are under 15 hops, resulting in
fairly small windows as above (under 35,000 bytes). Under these
conditions, and further assuming that the initial sequence number is
suitably (pseudo-randomly) chosen, a valid guessed sequence number
would have odds of 1 in 57,000. Put differently, a blind (non man-
in-the-middle) attacker would need to send 57,000 RSTs with suitably
spaced sequence number guesses to successfully reset a connection.
At 1 Mbps, 57,000 (40 byte) RSTs would take over 50 minutes to
transmit, and, as noted earlier, most current connections are fairly
brief by comparison.
Recent use of high bandwidth paths of 10 Gbps and result in
bandwidth-delay products over 125 MB - approximately 1/10 of TCP's
overall window size excluding scale, assuming the receiver allocates
sufficient buffering (to be discussed later). Even under networks
that are ten times slower (1 Gbps), the active receiver window covers
1/100th of the overall window size. At these speeds, it takes only
10-100 packets, or under 32 microseconds, to correctly guess a valid
sequence number and kill a connection. A table of corresponding
exposure to various amounts of RSTs is shown below, for various line
rates, assuming the more conventional 100ms latencies (though even
100ms is large for BGP cases):
Touch Expires August 13, 2005 [Page 6]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
Figure 1: Time needed to kill a connection
This table demonstrates that the effect of bandwidth on the
vulnerability is squared; for every increase in bandwidth, there is a
linear decrease in the number of sequence number guesses needed, as
well as a linear decrease in the time needed to send a set of
guesses. Notably, as inter-router link bandwidths approach 1 Mbps,
an 'exhaustive' attack becomes practical. Checking that the RST
sequence number is somewhere in the valid window (bw*delay) out of
the overall window (2^32) is an insufficient obfuscation.
Note that this table makes a number of assumptions:
1. the overall bandwidth-delay product is relatively fixed
2. traffic losses are negligible (insufficient to affect the
3. congestion window over most of the connection)
4. the receive socket buffers do not limiting the receive window
5. the attack bandwidth is similar to the end-to-end path bandwidth
Of these assumptions, the last two are more notable. The issue of
receive socket buffers will be addressed later. The issue of the
attack bandwidth is considered reasonable as follows:
1. RSTs are substantially easier to send than data; they can be
precomputed and they are smaller than data packets (40 bytes).
2. although susceptible connections use somewhat less ubiquitous
high-bandwidth paths, the attack may be distributed, at which
point only the ingress link of the attack is the primary
limitation
Touch Expires August 13, 2005 [Page 7]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
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 previous sections discussed the nature of the recent attacks on
BGP due to the vulnerability of TCP to RST spoofing attacks, due
largely to recent increases in the fraction of the TCP window space
in use for a single, long-lived connection.
3. Proposed solutions
TCP currently authenticates received RSTs using the address and port
pair numbers, and checks that the sequence number is inside the valid
receiver window. The previous section demonstrated how TCP has
become more vulnerable to RST spoofing attacks due to the increases
in the receive window size. There are a number of current and
proposed solutions to this vulnerability, all attempting to increase
the authentication of received RSTs.
3.1. Transport Layer Solutions
The transport layer represents the last place that segments can be
authenticated before they affect connection management. TCP has a
variety of current and proposed mechanisms to increase the
authentication of segments, protecting against both off-path third-
party spoofs and man-in-the-middle attacks. SCTP also has mechanisms
to authenticate segments.
3.1.1. TCP MD5 Authentication
An extension to TCP supporting MD5 authentication was developed
around six years ago specifically to authenticate BGP connections
(although it can be used for any TCP connection) [4]. The extension
relies on a pre-shared secret key to authenticate the entire TCP
segment, including the data, TCP header, and TCP pseudo-header
(certain fields of the IP header). All segments are protected,
including RSTs, to be accepted only when their signature matches.
This option, although widely deployed in Internet routers, is
considered undeployable for widespread use because the need for pre-
shared keys. It further is considered computationally expensive for
either hosts or routers due to the overhead of MD5 [12][13].
3.1.2. TCP RST Window Attenuation
A recent proposal extends TCP to further constrain received RST to
match the expected next sequence number [24]. This restores TCP's
resistance to spurious RSTs, effectively limiting the receive window
for RSTs to a single number. As a result, an attacker would need to
Touch Expires August 13, 2005 [Page 8]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
send 2^32 different packets to correctly guess the sequence number.
The extension further modifies the RST receiver to react to
incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST
source is legitimate, upon receipt of an ACK the closed source would
presumably emit a RST with the sequence number matching the ACK,
correctly resetting the intended recipient. This modification adds
arcs to the TCP state diagram, adding to its complexity and thus
potentially affecting its correctness (in contrast to adding MD5
signatures, which is orthogonal to the state machine altogether).
For example, there may be complications between RSTs of different
connections between the same pair of endpoints because RSTs flush the
TIME-WAIT (as mentioned earlier). Further, this modifies TCP so that
under some circumstances a RST causes a reply, in violation of
generally accepted practice, if not gentle recommendation. The
advantage to this proposal is that it can be deployed incrementally
and has benefit to the endpoint on which it is deployed.
A variant of this proposal uses a different value to attenuate the
window of viable RSTs. It requires RSTs to carry the initial
sequence number rather than the next expected sequence number, i.e.,
the value negotiated on connection establishment [15]. This proposal
has the advantage of using an explicitly negotiated value, but at the
cost of changing the behavior of an unmodified endpoint to a
currently valid RST. It would thus be more difficult, without
additional mechanism, to deploy incrementally.
The most obvious other variant of this proposal involves increasing
TCP's window space, rather than decreasing the valid range for RSTs,
i.e., increasing the sequence space from 32 bits to 64 bits. This
has the equivalent effect - the ratio of the valid sequence numbers
for any segment to the overall sequence number space is significantly
reduced. The use of the larger space, as with current schemes to
establish weak authentication using initial sequence numbers (ISNs),
is contingent on using suitably random values for the ISN. Such
randomness adds additional complexity to TCP both in specification
and implementation, and provides only very weak authentication. Such
a modification is not obviously backward compatible, and would be
thus difficult to deploy.
3.1.3. TCP Timestamp Authentication
Another way to authenticate TCP segments is to utilize its timestamp
option, using the value as a sort of authentication [5]. This
requires that the receiver TCP discard values whose timestamp is
outside the accepted window, which is derived from the timestamps of
other packets from the same connection. This technique uses an
existing TCP option, but also requires modified RST processing and
Touch Expires August 13, 2005 [Page 9]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
may be difficult to deploy incrementally without further
modifications. Additionally, the timestamp value may be easier to
guess because it is derived from a predictable value.
3.1.4. Other TCP Cookies
All of the above techniques are variants of cookies, otherwise
meaningless data whose value is used to validate the packet. In the
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
in 2^(signature length) probability of attack. The primary
difference is that MD5 signatures are effectively one-time cookies,
not predictable based on man-in-the-middle snooping, because they are
dependent on packet data and thus do not repeat. Window attenuation
sequence numbers can be guessed by snooping the sequence number of
current packets, and timestamps can may be guessed even more
remotely. These variants of cookies are similar in spirit to TCP SYN
cookies, again patching a vulnerability to off-path third-party
spoofing attacks based on a (fairly weak, excepting MD5) form of
authentication. Another form of cookie is the source port itself,
which can be randomized but provides only 16 bits of protection
(65,000 combinations), which may be exhaustively attacked. This can
be combined with destination port randomization as well, but that
would require a separate coordination mechanism (so both parties know
which ports to use), which is equivalent to (and as infeasible for
large-scale deployments as) exchanging a shared secret.
3.1.5. Other TCP Considerations
The analysis of the potential for RST spoofing above assumes that the
receive window opens to the maximum extent suggested by the
bandwidth-delay product of the end-to-end path, and that the window
opens to an appreciable fraction of the overall sequence number
space. As noted earlier, for most common cases, connections are too
brief or over bandwidths too low to for such a large window to occur.
Expanding TCP's sequence number space is a direct way to further
avoid such vulnerability, even for long connections over emerging
bandwidths.
Finally, it is often sufficient for the endpoint to limit the receive
window in other ways, notably using 'socket options'. If the receive
socket buffer is limited, e.g., to the ubiquitous default of 65KB,
the receive window cannot grow to vulnerable sizes even for very long
connections over very high bandwidths. The consequence is lower
sustained throughput, where only one window's worth of data per round
trip time (RTT) is exchanged. Although this will keep the connection
open longer, it also reduces the receive window; for long-lived
Touch Expires August 13, 2005 [Page 10]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
connections with continuous sourced data, this may continue to
present an attack opportunity, albeit a sparse and slow-moving
target. For the most recent case where BGP data is being exchanged
between Internet routers, the data is bursty and the aggregate
traffic is small (i.e., unlikely to cover a substantial portion of
the sequence space, even if long-lived), so is difficult to consider
where smaller receive buffers would not sufficiently address the
immediate problem.
3.1.6. Other Transport Protocol Solutions
Segment authentication has been addressed at the transport layer in
other protocols. Both SCTP and DCCP* include cookies for connection
establishment and uses them to authenticate a variety of other
control messages [16][25]. The inclusion of such mechanism at the
transport protocol, although emerging as standard practice,
unnecessarily complicates the design and implementation of new
protocols. As new attacks are discovered (SYN floods, RSTs, etc.),
each protocol must be modified individually to compensate. A network
solution may be more appropriate and efficient.
*[AUTH - DCCP may be removing cookies from the spec for the
redundancies discussed above, because the use of cookies at the
transport layer primarily supports dynamic multihoming (a design goal
of SCTP, but not DCCP) rather than security.]
3.2. Network Layer (IP) Solutions
TCP is susceptible to RSTs, but also to other spoofing and man-in-
the-middle attacks, including SYN attacks. Other transport
protocols, such as UDP and RTP are equally susceptible. Although
emerging transport protocols attempt to defeat such attacks at the
transport layer, such attacks take advantage of network layer
identity spoofing. The packet is coming from an endpoint who is
spoofing another endpoint, either upstream or somewhere else in the
Internet. IPsec was designed specifically to establish and enforce
authentication of a packet's source and contents, to most directly
and explicitly addresses this security vulnerability.
The larger problem with IPsec is that of CA key distribution and use.
IPsec is often cumbersome, and has only recently been supported in
many end-system operating systems. More importantly, it relies on
signed X.509 certificates to establish and exchange keying
information (e.g., via IKE). These present challenges when using
IPsec to secure traffic to a well-known server, whose clients may not
support IPsec or may not have registered with a previously-known
certificate authority (CA).
Touch Expires August 13, 2005 [Page 11]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
4. Issues
There are a number of existing and proposed solutions addressing the
vulnerability of transport protocols in general, and TCP in specific,
to off-path third-party spoofing attacks. As shown, these operate at
the transport or network layer. Transport solutions require separate
modification of each transport protocol, addressing network identity
spoofing separately in the context of each transport association.
Network solutions are computationally intensive and require pervasive
registration of certificate authorities with every possible endpoint.
This section explains these observations further.
4.1. Transport Layer (e.g., TCP)
Transport solutions rely on shared cookies to authenticate segments,
including data, transport header, and even pseudo-header (e.g., fixed
portions of the outer IP header in TCP). Because the Internet relies
on stateless network protocols, it makes sense to rely on state
establishment and maintenance available in some transport layers not
only for the connection but for authentication state. Three-way
handshakes and heartbeats can be used to negotiate authentication
state in conjunction with connection parameters, which can be stored
with connection state easily.
As noted earlier, transport layer solutions require separate
modification of all transport protocols to include authentication.
Not all transport layers support negotiated endpoint state (e.g.,
UDP), and legacy protocols have been notoriously difficult to safely
augment. Not all authentication solutions are created equal either,
and relying on a variety of transport solutions exposes end-systems
to increased potential for incorrectly specified or implemented
solutions. Transport authentication has often been developed piece-
wise, in response to specific attacks, e.g., SYN cookies and RST
window attenuation [17][24].
Transport layer solutions are not only per-protocol, but often per-
connection. Each connection needs to negotiate and maintain
authentication state separately. Overhead is not amortized over
multiple connections - this includes overheads in packet exchanges,
design complexity, and implementation complexity. Finally, because
the authentication happens later in packet processing than is
required, additional endpoint resources may be needlessly consumed,
e.g., in demultiplexing received packets, indexing connection
identifiers, etc., only to be dropped later at the transport layer.
Touch Expires August 13, 2005 [Page 12]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
4.2. Network Layer (IP)
A network layer solution avoids the hazards of multiple transport
variants, using a single shared endpoint authentication mechanism
early in receiver packet processing to discard unauthenticated
packets quickly. Network solutions protect all transport protocols,
including both legacy and emerging protocols, and reduce the
complexity of these protocols as well. A shared solution also
reduces protocol overhead, and decouples the management (and
refreshing) of authentication state from that of individual transport
connections. Finally, a network layer solution protects not only the
transport layer but the network layer as well, e.g., from ICMP, IGMP,
etc., spoofing attacks.
The ubiquitous protocol for network layer authentication is IPsec
[18][26]. IPsec specifies the overall architecture, including header
authentication (AH) [19][27] and encapsulation (ESP) modes [20]. AH
authenticates both the IP header and IP data, whereas ESP
authenticates only the IP data (e.g., transport header and payload).
AH is deprecated since ESP is more efficient and the SPI includes
sufficient information to verify the IP header anyway. These two
modes describe the security applied to individual packets within the
IPsec system; key exchange and management is performed either out-of-
band (via pre-shared keys) or by an automated key exchange protocol
IKE [21][28].
IPsec already provides authentication of an IP header and its data
contents sufficient to defeat both man-in-the-middle and off-path
third-party spoofing attacks. IKE can configure authentication
between two endpoints on a per-endpoint, per-protocol, or per-
connection basis, as desired. IKE also can perform automatic
periodic re-keying, further defeating crypto-analysis based on
snooping (clandestine data collection). The use of IPsec is already
commonly strongly recommended for protected infrastructure.
IPsec is not appropriate for many deployments. It is computationally
intensive both in key management and individual packet authentication
[12]. As importantly, IKE is not anonymous; keys can be exchanged
between parties only if they trust each others' X.509 certificates or
pre-share a key. These certificates provide identification (the
other party knows who you are) only where the certificates themselves
are signed by certificate authorities (CAs) that both parties already
trust. To a large extent, the CAs themselves are the pre-shared keys
which help IKE establish security association keys, which are then
used in the authentication algorithms.
Touch Expires August 13, 2005 [Page 13]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
IPsec, although widely available both in commercial routers and
commodity end-systems, is not often utilized except between parties
that already have a preexisting relationship (employee/employer,
between two ISPs, etc.) Servers to anonymous clients (e.g., customer/
business) or more open services (e.g., BGP, where routers may large
numbers of peers) are unmanageable, due to the breadth and flux of
CAs. New endpoints cannot establish IPsec associations with such
servers unless their certificate is signed by a CA already trusted by
the server. Different servers - even within the same overall system
(e.g., BGP) - often cannot or will not trust overlapping subsets of
CAs in general.
4.3. Application Layer
There are a number of application layer authentication mechanisms,
often implicit within end-to-end encryption. Application-layer
security (e.g., TLS, SSH, or MD5 checksums within a BGP stream)
provides the ultimate protection of application data from all
intermediaries, including network routers as well as exposure at
other layers in the end-systems. This is the only way to ultimately
protect the application data.
Application authentication cannot protect either the network or
transport protocols from spoofing attacks, however. Spoofed packets
interfere with network processing or reset transport connections
before the application checks the data. Authentication needs to
winnow these packets and drop them before they interfere at these
lower layers.
4.4. Shim Transport/Application 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.
4.5. Link Layer
Link layer security operates separately on each hop of an Internet.
Such security can be critical in protecting link resources, such as
bandwidth and link management protocols. Protection at this layer
cannot suffice for network or transport layers, because it cannot
authenticate the endpoint source of a packet. Link authentication
ensures only the source of the current link hop where it is examined.
Touch Expires August 13, 2005 [Page 14]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
4.6. Conclusion
The issues raised in this section suggest that there are challenges
with all solutions to transport protection from spoofing attacks.
This raises the potential need for alternate security levels. While
it is already widely recognized that security needs to occur
simultaneously at many protocol layers, the also may be utility in
supporting a variety of strengths at a single layer. For example,
IPsec already supports a variety of algorithms (MD5, SHA, etc. for
authentication), but always assumes that:
1. the entire body of the packet is secured
2. security associations are established only where identity is
authenticated by a know certificate authority or other pre-shared
key
3. both man-in-the-middle and off-path third-party spoofing attacks
must be defeated
These assumptions are prohibitive, especially in many cases of
spoofing attacks. For spoofing, the primary issue is whether packets
are coming from the same party the server can reach. Only the IP
header is fundamentally in question, so securing the entire packet
(1) is computational overkill. It is sufficient to authenticate the
other party as "a party you have exchanged packets with", rather than
establishing their trusted identity ("Bill" vs. "Bob") as in (2).
Finally, many cookie systems use clear-text (unencrypted), fixed
cookie values, providing reasonable (1 in 2^{cookie-size}) protection
against off-path third-party spoofs, but not addressing man-in-the-
middle at all. Such potential solutions are discussed in the ANONsec
document, in the BTNS (Better Than Nothing Security) BOF [2][6].
5. Security Considerations
This entire document focuses on increasing the security of transport
protocols and their resistance to spoofing attacks. Security is
addressed throughout.
This document describes a number of techniques for defeating spoofing
attacks. Those relying on clear-text cookies, either explicit or
implicit (e.g., window sequence attenuation) do not protect from man-
in-the-middle spoofing attacks, since valid values can be learned
from prior traffic. Those relying on true authentication algorithms
are stronger, protecting even from man-in-the-middle, because the
authentication hash in a single packet approaches the behavior of
"one time" cookies.
Touch Expires August 13, 2005 [Page 15]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
The security of various levels of the protocol stack is addressed.
Spoofing attacks are fundamentally identity masquerading, so we
believe the most appropriate solutions defeat these at the network
layer, where end-to-end identity lies. Some transport protocols
subsume endpoint identity information from the network layer (e.g.,
TCP pseudo-headers), whereas others establish per-connection identity
based on exchanged nonces (e.g., SCTP). It is reasonable, if not
recommended, to address security at all layers of the protocol stack.
6. Conclusions
This document describes the details of the recent BGP spoofing
attacks involving spurious RSTs which could be used to shutdown TCP
connections. It summarizes and discusses a variety of current and
proposed solutions at various protocol layers.
7. Acknowledgments
This document was inspired by discussions on the
<http://www.ietf.org/html.charters/tcpm-charter.html> about the
recent spoofed RST attacks on BGP routers, including R. Stewart's
draft [15][24]. The analysis of the attack issues, alternate
solutions, and the anonymous security proposed solutions were the
result of discussions on that list as well as with USC/ISI's T.
Faber, A. Falk, G. Finn, and Y. Wang. Ran Atkinson suggested the
UDP variant of TCP/MD5, and Paul Goyette suggested using the ISN to
seed TCP/MD5. Other improvements are due to the input of various
members of the IETF's TCPM WG.
8. References
(NB: to be reordered and repartitioned)
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC.,
http://www.ietf.org/ietf/04nov/btns.txt.
[3] "Technical Cyber Security Alert TA04-111A: Vulnerabilities in
TCP -- http://www.us-cert.gov/cas/techalerts/TA04-111A.html",
April 20 2004.
[4] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
Touch Expires August 13, 2005 [Page 16]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
[5] Poon, K., "Use of TCP timestamp option to defend against blind
spoofing attack", (work in progress), June 2004.
[6] Touch, J., "ANONsec: Anonymous Security to Defend Against
Spoofing Attacks", (work in progress), July 2004.
[7] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337,
May 1992.
[8] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583, March 1999.
[9] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
60, RFC 3360, August 2002.
[10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[11] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[12] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[13] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995
77-86., March 1999.
[14] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991.
[15] "IETF TCPM Working Group and mailing list -
http://www.ietf.org/html.charters/tcpm-charter.html".
[16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[17] Bernstein, D., "SYN cookies - http://cr.yp.to/syncookies.html",
1997.
[18] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
Touch Expires August 13, 2005 [Page 17]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
[20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[21] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[22] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[23] Maughan, D., Schneider, M. and M. Schertler, "Internet Security
Association and Key Management Protocol (ISAKMP)", RFC 2408,
November 1998.
8.2. Informative References
[24] Stewart, R., "Transmission Control Protocol security
considerations", draft-ietf-tcpm-tcpsecure-01 (work in
progress), June 2004.
[25] Kohler, E., "Datagram Congestion Control Protocol (DCCP)",
draft-ietf-dccp-spec-06 (work in progress), February 2004.
[26] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-02 (work in progress),
April 2004.
[27] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
rfc2402bis-07 (work in progress), March 2004.
[28] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
ietf-ipsec-ikev2-14 (work in progress), June 2004.
Author's Addresses
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300
Email: touch@isi.edu
URI: http://www.isi.edu/touch
Touch Expires August 13, 2005 [Page 18]
Internet-Draft Defending TCP Against Spoofing Attacks February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that
any applicable patent or other IPR claims of which I am aware have
been disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Touch Expires August 13, 2005 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-21 02:08:12 |