IETF TCPM WG                                                   J. Touch
Internet Draft                                                  USC/ISI
Expires: August October 2005                                  February 13,                                    April 26, 2005

                  Defending TCP Against Spoofing Attacks

Status of this Memo

   By submitting this Internet-Draft, I certify each author represents that
   any applicable patent or other IPR claims of which I am he or she is
   aware have been or will be disclosed, and any of which I become he or she
   becomes aware will be disclosed, in accordance with
   RFC 3668.

   This document may only be posted in an Internet-Draft. Section 6 of
   BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 13, October 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   Recent analysis of potential attacks on core Internet infrastructure
   indicates an increased vulnerability of TCP connections to spurious
   resets (RSTs). (RSTs), sent with forged IP source addresses (spoofing).  TCP
   has always been susceptible to such RST spoof spoofing attacks, which were
   indirectly protected by checking that the RST sequence number was
   inside the current receive window, as well as via the obfuscation of
   TCP endpoint and port numbers.  For pairs of well-
   known 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 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. The susceptibility to attack increases as the square
   of the bandwidth, thus presents a significant vulnerability for
   recent high-speed networks. 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",
   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 Receiver Window..........6
   3. Proposed solutions.............................................8
      3.1. Transport Layer Solutions.................................8
         3.1.1. TCP MD5 Authentication...............................8 Authentication...............................9
         3.1.2. TCP RST Window Attenuation...........................8 Attenuation...........................9
         3.1.3. TCP Timestamp Authentication.........................9 Authentication........................10
         3.1.4. Other TCP Cookies...................................10
         3.1.5. Other TCP Considerations............................10 Considerations............................11
         3.1.6. Other Transport Protocol Solutions..................11
      3.2. Network Layer (IP) Solutions.............................11 Solutions.............................12
         3.2.1. Ingress filtering...................................12
         3.2.2. IPsec...............................................13
   4. Issues........................................................12 Issues........................................................13
      4.1. Transport Layer (e.g., TCP)..............................12 TCP)..............................13
      4.2. Network Layer (IP).......................................13 (IP).......................................14
      4.3. Application Layer........................................14 Layer........................................15
      4.4. Shim Transport/Application Layer.........................14 Layer.........................16
      4.5. Link Layer...............................................14 Layer...............................................16
      4.6. Conclusion...............................................15 Issues Discussion........................................16
   5. Security Considerations.......................................15 Considerations.......................................17
   6. Conclusions...................................................16 Conclusions...................................................17
   7. Acknowledgments...............................................16 Acknowledgments...............................................17
   8. References....................................................16 References....................................................18
      8.1. Normative References.....................................16 References.....................................18
      8.2. Informative References...................................18
   Author's Addresses...............................................18 Addresses...............................................21
   Intellectual Property Statement..................................19 Statement..................................21
   Disclaimer of Validity...........................................19 Validity...........................................21
   Copyright Statement..............................................19
   Acknowledgment...................................................19 Statement..............................................22

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
   [6][7][15][35].  These connections, typically using TCP, can be
   susceptible to off-path (non man-in-the-middle) third-party reset
   (RST) segments, segments with forged source addresses (spoofed), which
   terminate the TCP connection.  BGP routers react to a terminated TCP
   connection in various ways, ways which can amplify the impact of an attack,
   ranging from restarting the connection to deciding that the other
   router is unreachable and thus flushing the BGP routes. routes [29].  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 spoofing 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. challenge.

   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
   [8], modifications to TCP's timestamp processing [5], [27], and
   modifications to IPsec and TCP/MD5 keying [6]. [34].

   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
   development of TCP/MD5 [15]. The recent attack scenario was first
   documented by Convery at a NANOG meeting in 2003, but that analysis
   assumed the entire sequence space (2^32 packets) needed to be covered
   for an attack to succeed [7]. Watson's more detailed analysis
   discovered that a single packet anywhere in the current window could
   succeed at an attack [35]. This document adds the observation that
   susceptibility to attack goes as the square of bandwidth, due to the
   coupling between the linear decrease in window size and linear
   increase in rate an attacker, as well as comparing the variety of
   more recent proposals, including modifications to TCP, use of IPsec,
   and use of TCP/MD5 to resist such attacks.

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
   [6][7][35].  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. attacks because
   it uses TCP connectivity to infer routability, so losing a TCP
   connection with a BGP peer can result in the flushing of routes to
   that peer [29].

   Until six years ago, such connections were assumed difficult to
   attack because they were described by a few comparatively obscure
   parameters [15]. 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

   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
   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 advertised receive 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 [29].  This causes routers to drop the BGP routing
   information already exchanged, in addition to inhibiting their
   ongoing exchanges. exchanges, thus amplifying the impact of the attack.  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]. [5].  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]. [9].

   Firewalls and load balancers, so-called 'middleboxes', sometimes emit
   RSTs on behalf of transited connections to optimize server
   performance [9]. [11].  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

2.3. What Changed -- the Ever Opening Receiver 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,
   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, 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

   TCP uses two window mechanisms, a primary mechanism which uses a
   space of 32 bits, and a secondary mechanism which scales this window
   [28][16].  The valid advertised 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 advertised receive window should
   open to around the path bandwidth-
   delay bandwidth-delay product, including buffering
   delays (assume 1 packet/hop).  Many paths in the Internet have end-to-end 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, 57,000 of falling
   within the advertised receive window.  Put differently, a blind (non man-
   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 higher result in
   bandwidth-delay products over 125 MB - approximately 1/10 of TCP's
   overall maximum advertised receive 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 advertised 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

          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: 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 advertised receive window (2^32) is an insufficient

   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

      congestion window over the duration of most of the connection)


   3. the receive socket buffers do not limiting the receive window


   4. the attack bandwidth is similar to the end-to-end path bandwidth

   Of these assumptions, the last two are more notable.  The issue of
   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

   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 advertised
   receive 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]. [15].  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. keys [2][24].  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]. [8].  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
   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]. [31].  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]. [27].  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
   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

   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
   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]. [30][23].  The inclusion of such mechanism at the
   transport protocol, although emerging as standard practice,
   unnecessarily complicates the design and implementation of new
   protocols [25]  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

   There are equally susceptible.  Although
   emerging transport protocols attempt to defeat such attacks at the
   transport layer, such attacks take advantage two primary variants of network layer
   identity spoofing.  The packet solutions to
   spoofing: ingress filtering and IPsec. Ingress filtering is coming from an endpoint who is
   spoofing another endpoint, either
   indirect system which relies on other parties to filter packets sent
   upstream or somewhere else in of an attack, but does not necessarily require participation
   of the
   Internet. packet source. IPsec was designed specifically requires cooperation between the
   endpoints wanting to establish and enforce
   authentication avoid attack on their connection, which
   currently involves pre-existing shared knowledge of either a packet's source and contents, to most directly
   and explicitly addresses this security vulnerability.

   The larger problem with IPsec is that of CA shared
   key distribution and use.
   IPsec or shared certificate authority.

3.2.1. Ingress filtering

   Ingress filtering is often cumbersome, and has only recently been supported in
   many end-system operating systems.  More importantly, it relies on
   signed X.509 certificates proposed as an alternative to establish and exchange keying
   information (e.g., via IKE).  These present challenges when using
   IPsec protocol
   mechanisms to secure defeat IP source address spoofing [1][10]. Ingress
   filtering restricts traffic from downstream sources across transit
   networks based on the IP source address. It cannot restrict traffic
   from the core to edges, i.e., from upstream sources. As a well-known server, whose clients may not
   support IPsec or may not have registered with result,
   each ingress must perform the appropriate filtering for overall
   protection to result; failure of any ingress to filter defeats the
   protection of all network participants, ultimately.

   As a result, ingress filtering is not a local solution that can be
   deployed to protect communicating pairs, but rather relies on a
   distributed infrastructure of trusted gateways filtering forged
   traffic where it enters the network. It is not feasible for local,
   incremental deployment, and relies too heavily on distributed
   cooperation. Although useful to reduce the load of spoofed traffic,
   it is insufficient to protect particular connections from attack.

   A more recent variant of ingress filtering checks the IP TTL field,
   relying on the TTL set by the other end of the connection [12]. This
   technique has been used to provide filtering for BGP. It assumes the
   connection source TTL is set to 255; packets at the receiver are
   checked for TTL=255, and others are dropped. This restricts traffic
   to one hop upstream of the receiver, but those hops could include
   other user programs at those nodes or any traffic those nodes accept
   via tunnels - because tunnels need not decrement TTLs [26]. This
   method of filtering works best where traffic originates one hop away,
   so that the ingress filtering is based on the trust of only directly-
   connected (tunneled or otherwise) nodes. Like conventional ingress
   filtering, this reduces spoofing traffic in general, but is not
   considered a reliable security mechanism because it relies on
   distributed filtering (that upstream nodes do not terminate tunnels
   arbitrarily, e.g.).

3.2.2. IPsec

   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).

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]. [3][8].

   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.

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
   [19][22].  IPsec specifies the overall architecture, including header
   authentication (AH) [19][27] [20][18] and encapsulation (ESP) modes [20]. [21].  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]. [14][17].

   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
   [32].  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.

   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.

4.6. Conclusion Issues Discussion

   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:


   4. the entire body of the packet is secured


   5. security associations are established only where identity is
      authenticated by a know certificate authority or other pre-shared


   6. 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]. [4][34].
   Note also that NULL Encryption in IPsec applies a variant of this
   cookie, where the SPI is the cookie, and no further encryption is
   applied [13].

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.

   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
   <> about the
   recent spoofed RST attacks on BGP routers, including R. Stewart's
   draft [15][24]. (which is now edited by M. Dalal) [31][8].  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

   As this is not a standards document, this section has no meaning.

8.2. Informative References

   [1]   Bradner, S., "Key words   Baker, F. and P. Savola, "Ingress Filtering for use in RFCs to Indicate Requirement
         Levels", BCP 14, Multihomed
         Networks," RFC 2119, 2827 / BCP 84, March 1997.

   [2]   Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC.,

   [3]   "Technical Cyber Security Alert TA04-111A: Vulnerabilities in
         TCP --",
         April 20 2004.

   [4]   Heffernan, A., "Protection of BGP Sessions via

   [2]   Bellovin, S. and A. Zinin, "Standards Maturity Variance
         Regarding the TCP MD5
         Signature Option", RFC 2385, August 1998.

   [5]   Poon, K., "Use of TCP timestamp option to defend against blind
         spoofing attack", Signature Option (RFC 2385) and the BGP-4
         Specification," (work in progress), June
         draft-iesg-tcpmd5app-01.txt, Sept. 2004.

   [6]   Touch, J., "ANONsec: Anonymous

   [3]   Bernstein, D., "SYN cookies -",

   [4]   Better Than Nothing Security to Defend Against
         Spoofing Attacks", (work in progress), July 2004.

   [7] [BTNS] BOF, IETF-61, Wash. DC.,

   [5]   Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337,
         May 1992.

   [6]   CERT alert: "Technical Cyber Security Alert TA04-111A:
         Vulnerabilities in   TCP --", April 20

   [7]   Convery, S. and M. Franz, "BGP Vulnerability Testing:
         Separating Fact from FUD", 2003,

   [8]   Dalal, M., (ed.), "Transmission Control Protocol security
         considerations", draft-ietf-tcpm-tcpsecure-02 (work in
         progress), Nov. 2004.

   [9]   Faber, T., Touch, J. Touch, and W. Yue, "The TIME-WAIT state in TCP
         and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
         1583, March 1999.


   [10]  Ferguson, P. and D. Senie, Network Ingress Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Address
         Spoofing," RFC 2267 / BCP 38, May 2000.

   [11]  Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
         60, RFC 3360, August 2002.

   [10]  Postel, J., "Transmission Control Protocol", STD 7,

   [12]  Gill, V., J. Heasley, and D. Meyer, "The Generalized TTL
         Security Mechanism (GTSM)," RFC 793,
         September 1981.

   [11] 3682 (Experimental), Feb. 2004.

   [13]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
         Use With IPsec", RFC 2410 (Standards Track), November 1998.

   [14]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409 (Standards Track), November 1998.

   [15]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
         Signature Option", RFC 2385 (Standards Track), August 1998.

   [16]  Jacobson, V., Braden, B. Braden, 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 -".

   [16]  Stewart, R., Xie, Q., Morneault, K., Sharp,

   [17]  Kaufman, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
         "Stream Control Transmission "Internet Key Exchange (IKEv2) Protocol", RFC 2960, October 2000.

   [17]  Bernstein, D., "SYN cookies -",
         draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.

   [18]  Kent, S., "IP Authentication Header",
         draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004.

   [19]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, 2401 (Standards Track), November 1998.


   [20]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 2402
         (Standards Track),   November 1998.


   [21]  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, 2406 (Standards Track), 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 S. 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 K. Seo, "Security Architecture for the Internet
         Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), June 2004.

         April 2005.

   [23]  Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion
         Control Protocol (DCCP)",
         draft-ietf-dccp-spec-06   draft-ietf-dccp-spec-11 (work in
         progress), February 2004.

   [26]  Kent, S. and K. Seo, "Security Architecture March 2005.

   [24]  Leech, M., "Key Management Considerations for the Internet
         Protocol", draft-ietf-ipsec-rfc2401bis-02 (work in progress),
         April 2004.

   [27]  Kent, S., TCP MD5
         Signature Option," RFC 3562 (Informational), July 2003.

   [25]  O'Malley, S. and L. Peterson, "TCP Extensions Considered
         Harmful", RFC 1263, October 1991.

   [26]  Perkins, C., "IP Authentication Header", draft-ietf-ipsec-
         rfc2402bis-07 Encapsulation within IP," RFC 2003 (Standards
         Track), Oct. 1996.

   [27]  Poon, K., "Use of TCP timestamp option to defend against blind
         spoofing attack," draft-poon-tcp-tstamp-mod-01 (work in
         progress), March Oct. 2004.

   [28]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-
         ietf-ipsec-ikev2-14  Postel, J., "Transmission Control Protocol," RFC 793 / STD 7,
         September 1981.

   [29]  Rekhter, Y. and T. Li, (eds.), "A Border Gateway Protocol 4
         (BGP-4)," RFC 1771 (Standards Track), March 1995.

   [30]  Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
         T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson,
         "Stream Control Transmission Protocol," RFC 2960 (Standards
         Track), October 2000.

   [31]  TCPM: IETF TCPM Working Group and mailing list-

   [32]  Touch, J., "Report on MD5 Performance," RFC 1810
         (Informational), June 1995.

   [33]  Touch, J., "Performance Analysis of MD5," Proc. Sigcomm 1995
         77-86., March 1999.

   [34]  Touch, J., "ANONsec: Anonymous Security to Defend Against
         Spoofing Attacks," draft-touch-anonsec-00 (work in progress), June
         May 2004.

   [35]  Watson, P., "Slipping in the Window: TCP Reset attacks,"
         Presentation at 2004 CanSecWest.

Author's Addresses

   Joe Touch
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: +1 (310) 448-9151
   Fax:   +1 (310) 448-9300

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

   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  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

Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).

   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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.