Defending against Sequence Number Attacks
draft-ietf-tcpm-rfc1948bis-02

Internet-Draft  Defending Against Sequence Number Attacks  December 2011

7.2.  Informative References

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

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

   [CPNI-TCP]
              CPNI, "Security Assessment of the Transmission Control
              Protocol (TCP)",  http://www.cpni.gov.uk/Docs/
              tn-03-09-security-assessment-TCP.pdf, 2009.

   [I-D.gont-behave-nat-security]
              Gont, F. and P. Srisuresh, "Security implications of
              Network Address Translators (NATs)",
              draft-gont-behave-nat-security-03 (work in progress),
              October 2009.

   [Joncheray1995]
              Joncheray, L., "A Simple Active Attack Against TCP", Proc.
              Fifth Usenix UNIX Security Symposium, 1995.

   [Morris1985]
              Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
              Software",  CSTR 117, AT&T Bell Laboratories, Murray Hill,
              NJ, 1985.

   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
              Specification", STD 8, RFC 854, May 1983.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, May 1996.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

Gont & Bellovin           Expires June 18, 2012                 [Page 8]
Internet-Draft  Defending Against Sequence Number Attacks  December 2011

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4954]  Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", RFC 4954, July 2007.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC5936]  Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, June 2010.

   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              RFC 6151, March 2011.

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

   [Silbersack2005]
              Silbersack, M., "Improving TCP/IP security through
              randomization without sacrificing interoperability.",
              EuroBSDCon 2005 Conference .

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

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

   [Zalewski2001]
              Zalewski, M., "Strange Attractors and TCP/IP Sequence
              Number Analysis",
               http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001.

Gont & Bellovin           Expires June 18, 2012                 [Page 9]
Internet-Draft  Defending Against Sequence Number Attacks  December 2011

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

Appendix A.  Address-based trust relationship exploitation attacks

   This section discusses the trust-relationship exploitation attack
   that originally motivated the publication of RFC 1948 [RFC1948].  It
   should be noted that while RFC 1948 focused its discussion of
   address-based trust relationship exploitation attacks on Telnet
   [RFC0854] and the various UNIX "r" commands, both Telnet and the
   various "r" commands have since been largely replaced by secure
   counter-parts (such as SSH [RFC4251]) 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 [RFC5321] deployments still authenticate their
   users by means of their IP addresses, even when more appropriate
   authentication mechanisms are available [RFC4954].  Another example
   is the authentication of DNS secondary servers [RFC1034] by means of
   their IP addresses for allowing DNS zone transfers [RFC5936], or any
   other access control mechanism based on IP addresses.

   In 1985, Morris [Morris1985] described a form of attack based on
   guessing what sequence numbers TCP [RFC0793] 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 3-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 [RFC4301] [RFC4120] [RFC4251].

   The following subsection provides technical details for the trust
   relationship exploitation attack described by Morris [Morris1985].

A.1.  Blind TCP connection-spoofing

   In order to understand the particular case of sequence number
   guessing, one must look at the 3-way handshake used in the TCP open
   sequence [RFC0793].  Suppose client machine A wants to talk to rsh
   server B. It sends the following message:

                              A->B: SYN, ISNa

Gont & Bellovin           Expires June 18, 2012                [Page 10]
Internet-Draft  Defending Against Sequence Number Attacks  December 2011

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

   B replies with

                         B->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->B: ACK(ISNb)

   RFC 793 [RFC0793] 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->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->A: SYN, ISNb', ACK(ISNx)

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

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

Gont & Bellovin           Expires June 18, 2012                [Page 11]
Internet-Draft  Defending Against Sequence Number Attacks  December 2011

   send a RST packet in response to tear down the connection.  However,
   an attacker could send the TCP segments containing the commands to be
   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 [RFC1948]).  However, all TCP implementations
      that used to implement this bug have been fixed for a long time.

Appendix B.  Changes from RFC 1948

   o  This document aims at Standards Track (rather than Informational).

   o  Formal requirements ([RFC2119]) 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.

Appendix C.  Changes from previous versions of the document (this
             section should be removed by the RFC Editor before
             publication of this document as an RFC)

C.1.  Changes from draft-ietf-tcpm-rfc1948bis-00

   o  Addresses WGLC feedback (posted on-list) by Wesley Eddy, and some
      comments submitted by Anantha Ramaiah.

C.2.  Changes from draft-gont-tcpm-rfc1948bis-00

   o  The recommended hash algorithm has been changed back to MD5
      [RFC1321], with a note that the security implications of MD5 have
      been carefully considered.

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

   o  Minor editorial changes.

Gont & Bellovin           Expires June 18, 2012                [Page 12]
Internet-Draft  Defending Against Sequence Number Attacks  December 2011

C.3.  Changes from RFC 1948

   o  New document aims at Standards Track (rather than Informational).

   o  The discussion of address-based trust relationship attacks was
      updated and moved to an Appendix.

   o  The recommended hash algorithm has been changed to SHA-256, in
      response to the security concerns for MD5 [RFC1321].

   o  Formal requirements ([RFC2119]) are specified.

Authors' Addresses

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

   Phone: +54 11 4650 8472
   Email: fernando@gont.com.ar
   URI:   http://www.si6networks.com

   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 & Bellovin           Expires June 18, 2012                [Page 13]