<pre>Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 6528                        SI6 Networks / UTN-FRH
Obsoletes: <a href="./rfc1948">1948</a>                                              S. Bellovin
Updates: <a href="./rfc793">793</a>                                         Columbia University
Category: Standards Track                                  February 2012
ISSN: 2070-1721


               <span class="h1">Defending against Sequence Number Attacks</span>

Abstract

   This document specifies an algorithm for the generation of TCP
   Initial Sequence Numbers (ISNs), such that the chances of an off-path
   attacker guessing the sequence numbers in use by a target connection
   are reduced.  This document revises (and formally obsoletes) <a href="./rfc1948">RFC</a>
   <a href="./rfc1948">1948</a>, and takes the ISN generation algorithm originally proposed in
   that document to Standards Track, formally updating <a href="./rfc793">RFC 793</a>.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6528">http://www.rfc-editor.org/info/rfc6528</a>.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Generation of Initial Sequence Numbers . . . . . . . . . . . .  <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Proposed Initial Sequence Number Generation Algorithm  . . . .  <a href="#page-4">4</a>
   <a href="#section-4">4</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-5">5</a>.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
   <a href="#section-6">6</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
     <a href="#section-6.1">6.1</a>.  Normative References . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
     <a href="#section-6.2">6.2</a>.  Informative References . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
   <a href="#appendix-A">Appendix A</a>.  Address-Based Trust-Relationship Exploitation
                Attacks . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#appendix-A.1">A.1</a>.  Blind TCP Connection-Spoofing  . . . . . . . . . . . . . . <a href="#page-10">10</a>
   <a href="#appendix-B">Appendix B</a>.  Changes from <a href="./rfc1948">RFC 1948</a> . . . . . . . . . . . . . . . . <a href="#page-12">12</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   For a long time, the Internet has experienced a number of off-path
   attacks against TCP connections.  These attacks have ranged from
   trust-relationship exploitation to denial-of-service attacks
   [<a href="#ref-CPNI-TCP" title="&quot;Security Assessment of the Transmission Control Protocol (TCP)&quot;">CPNI-TCP</a>].  Discussion of some of these attacks dates back to at
   least 1985, when Morris [<a href="#ref-Morris1985" title="&quot;A Weakness in the 4.2BSD UNIX TCP/IP Software&quot;">Morris1985</a>] described a form of attack based
   on guessing what sequence numbers TCP [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] will use for new
   connections between two known end-points.

   In 1996, <a href="./rfc1948">RFC 1948</a> [<a href="./rfc1948" title="&quot;Defending Against Sequence Number Attacks&quot;">RFC1948</a>] proposed an algorithm for the selection
   of TCP Initial Sequence Numbers (ISNs), such that the chances of an
   off-path attacker guessing valid sequence numbers are reduced.  With
   the aforementioned algorithm, such attacks would remain possible if
   and only if the attacker already has the ability to perform "man-in-
   the-middle" attacks.

   This document revises (and formally obsoletes) <a href="./rfc1948">RFC 1948</a>, and takes
   the ISN generation algorithm originally proposed in that document to
   Standards Track.

   <a href="#section-2">Section 2</a> provides a brief discussion of the requirements for a good
   ISN generation algorithm.  <a href="#section-3">Section 3</a> specifies a good ISN selection
   algorithm.  <a href="#appendix-A">Appendix A</a> provides a discussion of the trust-
   relationship exploitation attacks that originally motivated the
   publication of <a href="./rfc1948">RFC 1948</a> [<a href="./rfc1948" title="&quot;Defending Against Sequence Number Attacks&quot;">RFC1948</a>].  Finally, <a href="#appendix-B">Appendix B</a> lists the
   differences from <a href="./rfc1948">RFC 1948</a> to 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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].





<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Generation of Initial Sequence Numbers</span>

   <a href="./rfc793">RFC 793</a> [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] suggests that the choice of the ISN of a connection
   is not arbitrary, but aims to reduce the chances of a stale segment
   from being accepted by a new incarnation of a previous connection.
   <a href="./rfc793">RFC 793</a> [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] suggests the use of a global 32-bit ISN generator
   that is incremented by 1 roughly every 4 microseconds.

   It is interesting to note that, as a matter of fact, protection
   against stale segments from a previous incarnation of the connection
   is enforced by preventing the creation of a new incarnation of a
   previous connection before 2*MSL have passed since a segment
   corresponding to the old incarnation was last seen (where "MSL" is
   the "Maximum Segment Lifetime" [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>]).  This is accomplished by
   the TIME-WAIT state and TCP's "quiet time" concept (see <a href="./rfc1323#appendix-B">Appendix&nbsp;B of
   [RFC1323]</a>).

   Based on the assumption that ISNs are monotonically increasing across
   connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an
   incoming SYN segment to perform "heuristics" that enable the creation
   of a new incarnation of a connection while the previous incarnation
   is still in the TIME-WAIT state (see p. 945 of [<a href="#ref-Wright1994" title="&quot;TCP/IP Illustrated, Volume 2: The Implementation&quot;">Wright1994</a>]).  This
   avoids an interoperability problem that may arise when a node
   establishes connections to a specific TCP end-point at a high rate
   [<a href="#ref-Silbersack2005" title="&quot;Improving TCP/IP security through randomization without sacrificing interoperability&quot;">Silbersack2005</a>].

   Unfortunately, the ISN generator described in [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] makes it
   trivial for an off-path attacker to predict the ISN that a TCP will
   use for new connections, thus allowing a variety of attacks against
   TCP connections [<a href="#ref-CPNI-TCP" title="&quot;Security Assessment of the Transmission Control Protocol (TCP)&quot;">CPNI-TCP</a>].  One of the possible attacks that takes
   advantage of weak sequence numbers was first described in
   [<a href="#ref-Morris1985" title="&quot;A Weakness in the 4.2BSD UNIX TCP/IP Software&quot;">Morris1985</a>], and its exploitation was widely publicized about 10
   years later [<a href="#ref-Shimomura1995" title="&quot;Technical details of the attack described by Markoff in NYT&quot;">Shimomura1995</a>].  [<a href="#ref-CERT2001" title="&quot;CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers&quot;">CERT2001</a>] and [<a href="#ref-USCERT2001" title="&quot;US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers&quot;">USCERT2001</a>] are
   advisories about the security implications of weak ISN generators.
   [<a href="#ref-Zalewski2001" title="&quot;Strange Attractors and TCP/IP Sequence Number Analysis&quot;">Zalewski2001</a>] and [<a href="#ref-Zalewski2002" title="&quot;Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later&quot;">Zalewski2002</a>] contain a detailed analysis of ISN
   generators, and a survey of the algorithms in use by popular TCP
   implementations.

   Simple random selection of the TCP ISNs would mitigate those attacks
   that require an attacker to guess valid sequence numbers.  However,
   it would also break the 4.4BSD "heuristics" to accept a new incoming
   connection when there is a previous incarnation of that connection in
   the TIME-WAIT state [<a href="#ref-Silbersack2005" title="&quot;Improving TCP/IP security through randomization without sacrificing interoperability&quot;">Silbersack2005</a>].

   We can prevent sequence number guessing attacks by giving each
   connection -- that is, each four-tuple of (localip, localport,
   remoteip, remoteport) -- a separate sequence number space.  Within




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   each space, the ISN is incremented according to [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>]; however,
   there is no obvious relationship between the numbering in different
   spaces.

   An obvious way to prevent sequence number guessing attacks while not
   breaking the 4.4BSD heuristics would be to perform a simple random
   selection of TCP ISNs while maintaining state for dead connections
   (e.g. changing the TCP state transition diagram so that both end-
   points of all connections go to TIME-WAIT state).  That would work
   but would consume system memory to store the additional state.
   Instead, we propose an improvement to the TCP ISN generation
   algorithm that does not require TCP to keep state for all recently
   terminated connections.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Proposed Initial Sequence Number Generation Algorithm</span>

   TCP SHOULD generate its Initial Sequence Numbers with the expression:

      ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

   where M is the 4 microsecond timer, and F() is a pseudorandom
   function (PRF) of the connection-id.  F() MUST NOT be computable from
   the outside, or an attacker could still guess at sequence numbers
   from the ISN used for some other connection.  The PRF could be
   implemented as a cryptographic hash of the concatenation of the
   connection-id and some secret data; MD5 [<a href="./rfc1321" title="&quot;The MD5 Message-Digest Algorithm&quot;">RFC1321</a>] would be a good
   choice for the hash function.

   The result of F() is no more secure than the secret key.  If an
   attacker is aware of which cryptographic hash function is being used
   by the victim (which we should expect), and the attacker can obtain
   enough material (i.e., ISNs selected by the victim), the attacker may
   simply search the entire secret-key space to find matches.  To
   protect against this, the secret key should be of a reasonable
   length.  Key lengths of 128 bits should be adequate.  The secret key
   can either be a true random number [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>] or some per-host secret.
   A possible mechanism for protecting the secret key would be to change
   it on occasion.  For example, the secret key could be changed
   whenever one of the following events occur:

   o  The system is being bootstrapped (e.g., the secret key could be a
      combination of some secret and the boot time of the machine).

   o  Some predefined/random time has expired.

   o  The secret key has been used sufficiently often that it should be
      regarded as insecure at that point.




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   Note that changing the secret would change the ISN space used for
   reincarnated connections, and thus could cause the 4.4BSD heuristics
   to fail; to maintain safety, either dead connection state could be
   kept or a quiet time observed for two maximum segment lifetimes
   before such a change.

   It should be noted that while there have been concerns about the
   security properties of MD5 [<a href="./rfc6151" title="&quot;Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms&quot;">RFC6151</a>], the algorithm specified in this
   document simply aims at reducing the chances of an off-path attacker
   guessing the ISN of a new connection, and thus in our threat model it
   is not worth the effort for an attacker to try to learn the secret
   key.  Since MD5 is faster than other "stronger" alternatives, and is
   used in virtually all existing implementations of this algorithm, we
   consider that use of MD5 in the specified algorithm is acceptable.
   However, implementations should consider the trade-offs involved in
   using functions with stronger security properties, and employ them if
   it is deemed appropriate.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Security Considerations</span>

   Good sequence numbers are not a replacement for cryptographic
   authentication, such as that provided by IPsec [<a href="./rfc4301" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC4301</a>] or the TCP
   Authentication Option (TCP-AO) [<a href="./rfc5925" title="&quot;The TCP Authentication Option&quot;">RFC5925</a>].  At best, they are a
   palliative measure.

   If random numbers are used as the sole source of the secret, they
   MUST be chosen in accordance with the recommendations given in
   [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>].

   A security consideration that should be made about the algorithm
   proposed in this document is that it might allow an attacker to count
   the number of systems behind a Network Address Translator (NAT)
   [<a href="./rfc3022" title="&quot;Traditional IP Network Address Translator (Traditional NAT)&quot;">RFC3022</a>].  Depending on the ISN generators implemented by each of
   the systems behind the NAT, an attacker might be able to count the
   number of systems behind a NAT by establishing a number of TCP
   connections (using the public address of the NAT) and identifying the
   number of different sequence number "spaces".  [<a href="#ref-Gont2009" title="&quot;Security implications of Network Address Translators (NATs)&quot;">Gont2009</a>] discusses
   how this and other information leakages at NATs could be mitigated.

   An eavesdropper who can observe the initial messages for a connection
   can determine its sequence number state, and may still be able to
   launch sequence number guessing attacks by impersonating that
   connection.  However, such an eavesdropper can also hijack existing
   connections [<a href="#ref-Joncheray1995" title="&quot;A Simple Active Attack Against TCP&quot;">Joncheray1995</a>], so the incremental threat is not that
   high.  Still, since the offset between a fake connection and a given
   real connection will be more or less constant for the lifetime of the
   secret, it is important to ensure that attackers can never capture




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   such packets.  Typical attacks that could disclose them include both
   eavesdropping and the variety of routing attacks discussed in
   [<a href="#ref-Bellovin1989" title="&quot;Security Problems in the TCP/IP Protocol Suite&quot;">Bellovin1989</a>].

   Off-path attacks against TCP connections require the attacker to
   guess or know the four-tuple (localip, localport, remoteip,
   remoteport) that identifies the target connection.  TCP port number
   randomization [<a href="./rfc6056" title="&quot;Recommendations for Transport-Protocol Port Randomization&quot;">RFC6056</a>] reduces the chances of an attacker of
   guessing such a four-tuple by obfuscating the selection of TCP
   ephemeral ports, therefore contributing to the mitigation of such
   attacks.  [<a href="./rfc6056" title="&quot;Recommendations for Transport-Protocol Port Randomization&quot;">RFC6056</a>] provides advice on the selection of TCP ephemeral
   ports, such that the overall protection of TCP connections against
   off-path attacks is improved.

   [<a id="ref-CPNI-TCP">CPNI-TCP</a>] contains a discussion of all the currently known attacks
   that require an attacker to know or be able to guess the TCP sequence
   numbers in use by the target connection.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Acknowledgements</span>

   Matt Blaze and Jim Ellis contributed some crucial ideas to <a href="./rfc1948">RFC 1948</a>,
   on which this document is based.  Frank Kastenholz contributed
   constructive comments to that memo.

   The authors of this document would like to thank (in chronological
   order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William
   Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben
   Campbell for providing valuable comments on draft versions of this
   document.

   Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and
   Guillermo Gont for their love and support, and Daniel Bellomo and
   Christian O'Flaherty for their support in his Internet engineering
   activities.

   Fernando Gont's attendance to IETF meetings was supported by ISOC's
   "Fellowship to the IETF" program.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  References</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Normative References</span>

   [<a id="ref-RFC0793">RFC0793</a>]         Postel, J., "Transmission Control Protocol", STD 7,
                     <a href="./rfc793">RFC 793</a>, September 1981.

   [<a id="ref-RFC1321">RFC1321</a>]         Rivest, R., "The MD5 Message-Digest Algorithm",
                     <a href="./rfc1321">RFC 1321</a>, April 1992.




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   [<a id="ref-RFC1323">RFC1323</a>]         Jacobson, V., Braden, B., and D. Borman, "TCP
                     Extensions for High Performance", <a href="./rfc1323">RFC 1323</a>,
                     May 1992.

   [<a id="ref-RFC2119">RFC2119</a>]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC4086">RFC4086</a>]         Eastlake, D., Schiller, J., and S. Crocker,
                     "Randomness Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>,
                     <a href="./rfc4086">RFC 4086</a>, June 2005.

   [<a id="ref-RFC6056">RFC6056</a>]         Larsen, M. and F. Gont, "Recommendations for
                     Transport-Protocol Port Randomization", <a href="https://www.rfc-editor.org/bcp/bcp156">BCP 156</a>,
                     <a href="./rfc6056">RFC 6056</a>, January 2011.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Informative References</span>

   [<a id="ref-Bellovin1989">Bellovin1989</a>]    Morris, R., "Security Problems in the TCP/IP
                     Protocol Suite", Computer Communications Review,
                     vol. 19, no. 2, pp. 32-48, 1989.

   [<a id="ref-CERT2001">CERT2001</a>]        CERT, "CERT Advisory CA-2001-09: Statistical
                     Weaknesses in TCP/IP Initial Sequence Numbers",
                     <a href="http://www.cert.org/advisories/CA-2001-09.html">http://www.cert.org/advisories/CA-2001-09.html</a>,
                     2001.

   [<a id="ref-CPNI-TCP">CPNI-TCP</a>]        CPNI, "Security Assessment of the Transmission
                     Control Protocol (TCP)",  <a href="http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf">http://www.gont.com.ar/</a>
                     <a href="http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf">papers/tn-03-09-security-assessment-TCP.pdf</a>, 2009.

   [<a id="ref-Gont2009">Gont2009</a>]        Gont, F. and P. Srisuresh, "Security implications
                     of Network Address Translators (NATs)", Work
                     in Progress, October 2009.

   [<a id="ref-Joncheray1995">Joncheray1995</a>]   Joncheray, L., "A Simple Active Attack Against
                     TCP", Proc. Fifth Usenix UNIX Security Symposium,
                     1995.

   [<a id="ref-Morris1985">Morris1985</a>]      Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
                     Software", CSTR 117, AT&amp;T Bell Laboratories, Murray
                     Hill, NJ, 1985.

   [<a id="ref-RFC0854">RFC0854</a>]         Postel, J. and J. Reynolds, "Telnet Protocol
                     Specification", STD 8, <a href="./rfc854">RFC 854</a>, May 1983.

   [<a id="ref-RFC1034">RFC1034</a>]         Mockapetris, P., "Domain names - concepts and
                     facilities", STD 13, <a href="./rfc1034">RFC 1034</a>, November 1987.




<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   [<a id="ref-RFC1948">RFC1948</a>]         Bellovin, S., "Defending Against Sequence Number
                     Attacks", <a href="./rfc1948">RFC 1948</a>, May 1996.

   [<a id="ref-RFC3022">RFC3022</a>]         Srisuresh, P. and K. Egevang, "Traditional IP
                     Network Address Translator (Traditional NAT)",
                     <a href="./rfc3022">RFC 3022</a>, January 2001.

   [<a id="ref-RFC4120">RFC4120</a>]         Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
                     "The Kerberos Network Authentication Service (V5)",
                     <a href="./rfc4120">RFC 4120</a>, July 2005.

   [<a id="ref-RFC4251">RFC4251</a>]         Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
                     Protocol Architecture", <a href="./rfc4251">RFC 4251</a>, January 2006.

   [<a id="ref-RFC4301">RFC4301</a>]         Kent, S. and K. Seo, "Security Architecture for the
                     Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.

   [<a id="ref-RFC4954">RFC4954</a>]         Siemborski, R. and A. Melnikov, "SMTP Service
                     Extension for Authentication", <a href="./rfc4954">RFC 4954</a>, July 2007.

   [<a id="ref-RFC5321">RFC5321</a>]         Klensin, J., "Simple Mail Transfer Protocol",
                     <a href="./rfc5321">RFC 5321</a>, October 2008.

   [<a id="ref-RFC5925">RFC5925</a>]         Touch, J., Mankin, A., and R. Bonica, "The TCP
                     Authentication Option", <a href="./rfc5925">RFC 5925</a>, June 2010.

   [<a id="ref-RFC5936">RFC5936</a>]         Lewis, E. and A. Hoenes, "DNS Zone Transfer
                     Protocol (AXFR)", <a href="./rfc5936">RFC 5936</a>, June 2010.

   [<a id="ref-RFC6151">RFC6151</a>]         Turner, S. and L. Chen, "Updated Security
                     Considerations for the MD5 Message-Digest and the
                     HMAC-MD5 Algorithms", <a href="./rfc6151">RFC 6151</a>, March 2011.

   [<a id="ref-Shimomura1995">Shimomura1995</a>]   Shimomura, T., "Technical details of the attack
                     described by Markoff in NYT",
                     <a href="http://www.gont.com.ar/docs/post-shimomura-usenet.txt">http://www.gont.com.ar/docs/post-shimomura-</a>
                     <a href="http://www.gont.com.ar/docs/post-shimomura-usenet.txt">usenet.txt</a>, Message posted in USENET's
                     comp.security.misc newsgroup, Message-ID:
                     &lt;3g5gkl$5j1@ariel.sdsc.edu&gt;, 1995.

   [<a id="ref-Silbersack2005">Silbersack2005</a>]  Silbersack, M., "Improving TCP/IP security through
                     randomization without sacrificing
                     interoperability", EuroBSDCon 2005 Conference.








<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   [<a id="ref-USCERT2001">USCERT2001</a>]      US-CERT, "US-CERT Vulnerability Note VU#498440:
                     Multiple TCP/IP implementations may use
                     statistically predictable initial sequence
                     numbers",  <a href="http://www.kb.cert.org/vuls/id/498440">http://www.kb.cert.org/vuls/id/498440</a>,
                     2001.

   [<a id="ref-Wright1994">Wright1994</a>]      Wright, G. and W. Stevens, "TCP/IP Illustrated,
                     Volume 2: The Implementation", Addison-Wesley,
                     1994.

   [<a id="ref-Zalewski2001">Zalewski2001</a>]    Zalewski, M., "Strange Attractors and TCP/IP
                     Sequence Number Analysis",
                     <a href="http://lcamtuf.coredump.cx/oldtcp/tcpseq.html">http://lcamtuf.coredump.cx/oldtcp/tcpseq.html</a>,
                     2001.

   [<a id="ref-Zalewski2002">Zalewski2002</a>]    Zalewski, M., "Strange Attractors and TCP/IP
                     Sequence Number Analysis - One Year Later",
                      <a href="http://lcamtuf.coredump.cx/newtcp/">http://lcamtuf.coredump.cx/newtcp/</a>, 2002.

































<span class="grey">Gont &amp; Bellovin              Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Address-Based Trust-Relationship Exploitation Attacks</span>

   This section discusses the trust-relationship exploitation attack
   that originally motivated the publication of <a href="./rfc1948">RFC 1948</a> [<a href="./rfc1948" title="&quot;Defending Against Sequence Number Attacks&quot;">RFC1948</a>].  It
   should be noted that while <a href="./rfc1948">RFC 1948</a> focused its discussion of
   address-based trust-relationship exploitation attacks on Telnet
   [<a href="./rfc0854" title="&quot;Telnet Protocol Specification&quot;">RFC0854</a>] and the various UNIX "r" commands, both Telnet and the
   various "r" commands have since been largely replaced by secure
   counterparts (such as SSH [<a href="./rfc4251" title="&quot;The Secure Shell (SSH) Protocol Architecture&quot;">RFC4251</a>]) for the purpose of remote login
   and remote command execution.  Nevertheless, address-based trust
   relationships are still employed nowadays in some scenarios.  For
   example, some SMTP [<a href="./rfc5321" title="&quot;Simple Mail Transfer Protocol&quot;">RFC5321</a>] deployments still authenticate their
   users by means of their IP addresses, even when more appropriate
   authentication mechanisms are available [<a href="./rfc4954" title="&quot;SMTP Service Extension for Authentication&quot;">RFC4954</a>].  Another example
   is the authentication of DNS secondary servers [<a href="./rfc1034" title="&quot;Domain names - concepts and facilities&quot;">RFC1034</a>] by means of
   their IP addresses for allowing DNS zone transfers [<a href="./rfc5936" title="&quot;DNS Zone Transfer Protocol (AXFR)&quot;">RFC5936</a>], or any
   other access control mechanism based on IP addresses.

   In 1985, Morris [<a href="#ref-Morris1985" title="&quot;A Weakness in the 4.2BSD UNIX TCP/IP Software&quot;">Morris1985</a>] described a form of attack based on
   guessing what sequence numbers TCP [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] will use for new
   connections.  Briefly, the attacker gags a host trusted by the
   target, impersonates the IP address of the trusted host when talking
   to the target, and completes the three-way handshake based on its
   guess at the next ISN to be used.  An ordinary connection to the
   target is used to gather sequence number state information.  This
   entire sequence, coupled with address-based authentication, allows
   the attacker to execute commands on the target host.

   Clearly, the proper solution for these attacks is cryptographic
   authentication [<a href="./rfc4301" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC4301</a>] [<a href="./rfc4120" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">RFC4120</a>] [<a href="./rfc4251" title="&quot;The Secure Shell (SSH) Protocol Architecture&quot;">RFC4251</a>].

   The following subsection provides technical details for the trust-
   relationship exploitation attack described by Morris [<a href="#ref-Morris1985" title="&quot;A Weakness in the 4.2BSD UNIX TCP/IP Software&quot;">Morris1985</a>].

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Blind TCP Connection-Spoofing</span>

   In order to understand the particular case of sequence number
   guessing, one must look at the three-way handshake used in the TCP
   open sequence [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>].  Suppose client machine A wants to talk to
   rsh server B.  It sends the following message:

                              A-&gt;B: SYN, ISNa

   That is, it sends a packet with the SYN ("synchronize sequence
   number") bit set and an initial sequence number ISNa.






<span class="grey">Gont &amp; Bellovin              Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   B replies with

                         B-&gt;A: SYN, ISNb, ACK(ISNa)

   In addition to sending its own ISN, it acknowledges A's.  Note that
   the actual numeric value ISNa must appear in the message.

   A concludes the handshake by sending

                              A-&gt;B: ACK(ISNb)

   <a href="./rfc793">RFC 793</a> [<a href="./rfc0793" title="&quot;Transmission Control Protocol&quot;">RFC0793</a>] specifies that the 32-bit counter be incremented by
   1 in the low-order position about every 4 microseconds.  Instead,
   Berkeley-derived kernels traditionally incremented it by a constant
   every second, and by another constant for each new connection.  Thus,
   if you opened a connection to a machine, you knew to a very high
   degree of confidence what sequence number it would use for its next
   connection.  And therein lied the vulnerability.

   The attacker X first opens a real connection to its target B -- say,
   to the mail port or the TCP echo port.  This gives ISNb.  It then
   impersonates A and sends

                              Ax-&gt;B: SYN, ISNx

   where "Ax" denotes a packet sent by X pretending to be A.

   B's response to X's original SYN (so to speak)

                        B-&gt;A: SYN, ISNb', ACK(ISNx)

   goes to the legitimate A, about which more anon.  X never sees that
   message but can still send

                             Ax-&gt;B: ACK(ISNb')

   using the predicted value for ISNb'.  If the guess is right -- and
   usually it will be, if the sequence numbers are weak -- B's rsh
   server thinks it has a legitimate connection with A, when in fact X
   is sending the packets.  X can't see the output from this session,
   but it can execute commands as more or less any user -- and in that
   case, the game is over and X has won.

   There is a minor difficulty here.  If A sees B's message, it will
   realize that B is acknowledging something it never sent, and will
   send a RST packet in response to tear down the connection.  However,
   an attacker could send the TCP segments containing the commands to be




<span class="grey">Gont &amp; Bellovin              Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6528">RFC 6528</a>        Defending against Sequence Number Attacks  February 2012</span>


   executed back-to-back with the segments required to establish the TCP
   connection, and thus by the time the connection is reset, the
   attacker has already won.

      In the past, attackers exploited a common TCP implementation bug
      to prevent the connection from being reset (see subsection "A
      Common TCP Bug" in [<a href="./rfc1948" title="&quot;Defending Against Sequence Number Attacks&quot;">RFC1948</a>]).  However, all TCP implementations
      that used to implement this bug have been fixed for a long time.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Changes from <a href="./rfc1948">RFC 1948</a></span>

   o  This document is Standards Track (rather than Informational).

   o  Formal requirements [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] are specified.

   o  The discussion of address-based trust-relationship attacks has
      been updated and moved to an appendix.

   o  The subsection entitled "A Common TCP Bug" (describing a common
      bug in the BSD TCP implementation) has been removed.

Authors' Addresses

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   EMail: fgont@si6networks.com
   URI:   <a href="http://www.si6networks.com">http://www.si6networks.com</a>


   Steven M. Bellovin
   Columbia University
   1214 Amsterdam Avenue
   MC 0401
   New York, NY  10027
   US

   Phone: +1 212 939 7149
   EMail: bellovin@acm.org








Gont &amp; Bellovin              Standards Track                   [Page 12]
</pre>