[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5961

Network Working Group                                         R. Stewart
Internet-Draft                                                    Editor
Expires: October 18, 2004                                 April 19, 2004



         Transmission Control Protocol security considerations
                    draft-ietf-tcpm-tcpsecure-00.txt


Status of this Memo


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


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on October 18, 2004.


Copyright Notice


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


Abstract


   TCP (RFC793 [1]) is widely deployed and one of the most often used
   reliable end to end protocols for data communication. Yet when it was
   defined over 20 years ago the internet, as we know it, was a
   different place lacking many of the threats that are now common.
   Recently several rather serious threats have been detailed that can
   pose new methods for both denial of service and possibly data
   injection by blind attackers. This document details those threats and
   also proposes some small changes to the way TCP handles inbound
   segments that either eliminate the threats or at least minimize them
   to a more acceptable level.





Stewart                 Expires October 18, 2004                [Page 1]

Internet-Draft                TCP Security                    April 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Blind reset attack using the RST bit . . . . . . . . . . . . .  4
     2.1   Description of the attack  . . . . . . . . . . . . . . . .  4
     2.2   Solution . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Blind reset attack using the SYN bit . . . . . . . . . . . . .  5
     3.1   Description of the attack  . . . . . . . . . . . . . . . .  5
     3.2   Solution . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Blind data injection attack  . . . . . . . . . . . . . . . . .  6
     4.1   Description of the attack  . . . . . . . . . . . . . . . .  6
     4.2   Solution . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   7.2   Informative References . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10

































Stewart                 Expires October 18, 2004                [Page 2]

Internet-Draft                TCP Security                    April 2004



1.  Introduction


   TCP (RFC793 [1]) is widely deployed and one of the most often used
   reliable end to end protocols for data communication. Yet when it was
   defined over 20 years ago the internet, as we know it, was a
   different place lacking many of the threats that are now common.
   Recently several rather serious threats have been detailed that can
   pose new methods for both denial of service and possibly data
   injection by blind attackers. This document details those threats and
   also proposes some small changes to the way TCP handles inbound
   segments that either eliminate the threats or at least minimize them
   to a more acceptable level.


   Most of these changes violate some of the handling procedures for
   DATA, RST and SYN's as defined in RFC793 [1] but do not cause
   interoperability issues. The authors feel that many of the changes
   proposed in this document would, if TCP were being standardized
   today, be required to be in the base TCP document and the lack of
   these procedures is more an  artifact of the time when TCP was
   developed than any strict requirement of the protocol.
































Stewart                 Expires October 18, 2004                [Page 3]

Internet-Draft                TCP Security                    April 2004



2.  Blind reset attack using the RST bit


2.1  Description of the attack


   It has been traditionally thought that for a blind attacker to reset
   a TCP connection the attacker would have to guess a single sequence
   number in the TCP sequence space. This would in effect require an
   attacker to generate (2^^32/2) segments in order to reset a
   connection. Recent papers have shown this to not necessarily be the
   case. An attacker need only guess a number that lies between the last
   sequence number acknowledged and the last sequence number
   acknowledged added to the receiver window (RCV.WND). Modern operating
   systems normally default the RCV.WND to about 32,768 bytes. This
   means that a blind attacker need only guess 65,535 RST segments
   (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds
   this means that most connections (assuming the attacker can
   accurately guess both ports) can be reset in under 200 seconds
   (usually far less). With the rise of broadband availability and
   increasing available bandwidth, many Operating Systems have raised
   their default RCV.WND to as much as 64k, thus making these attacks
   even easier.


2.2  Solution


   RFC793 [1] currently requires handling of a segment with the RST bit
   when in a synchronized state to be processed as follows:
   1) If the RST bit is set and the sequence number is outside the
      expected window, silently drop the segment.
   2) If the RST bit is set and the sequence number is acceptable i.e.:
      (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection.


   Instead, the following changes should be made to provide some
   protection against such an attack.
   A) If the RST bit is set and the sequence number is outside the
      expected window, silently drop the segment.
   B) If the RST bit is exactly the next expected sequence number, reset
      the connection.
   C) If the RST bit is set and the sequence number does not exactly
      match the next expected sequence value, yet is within the
      acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an
      acknowledgment.


   This solution forms a challenge/response with any RST where the value
   does not exactly match the expected value and yet the RST is within
   the window.  In cases of a legitimate reset without the exact
   sequence number, the consequences of this new challenge/response will
   be that the peer requires an extra round trip time before the
   connection can be reset.




Stewart                 Expires October 18, 2004                [Page 4]

Internet-Draft                TCP Security                    April 2004



3.  Blind reset attack using the SYN bit


3.1  Description of the attack


   The reset attack which uses the RST bit highlights another possible
   avenue for a blind attacker. Instead of using the RST bit an attacker
   can use the SYN bit as well to tear down a connection. Using the same
   guessing technique, repeated SYN's can be generated with sequence
   numbers incrementing by an amount not larger than the window size
   apart and thus eventually cause the connection to be terminated.


3.2  Solution


   RFC793 [1] currently requires handling of a segment with the SYN bit
   set in the synchronized state to be as follows:
   1) If the SYN bit is set and the sequence number is outside the
      expected window, send an ACK back to the sender.
   2) If the SYN bit is set and the sequence number is acceptable i.e.:
      (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to
      the peer.


   Instead, changing the handling of the SYN to the following will
   provide complete protection from this attack:
   A) If the SYN bit is set and the sequence number is outside the
      expected window, send an ACK back to the peer.
   B) If the SYN bit is set and the sequence number is an exact match to
      the next expected sequence (RCV.NXT == SEG.SEQ) then send an ACK
      segment to the peer but before sending the ACK segment subtract
      one from value being acknowledged.
   C) If the SYN bit is set and the sequence number is acceptable i.e.:
      (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) then send an ACK segment to
      the peer.


   By always sending an ACK to the sender, a challenge/response is setup
   with the peer. A legitimate peer, after restart, would not have a TCB
   in the synchronized state. Thus when the ACK arrives the peer should
   send a RST segment. Note that for the case of an attacker sending a
   SYN that exactly matches the RCV.NXT value, by sending a ACK that is
   less than the RCV.NXT value the true peer will drop the ACK as an old
   duplicate. In cases where a valid restarting peer picks the ISS
   number to match the RCV.NXT, sending an ACK value one less than
   RCV.NXT will cause the restarted peer to see the ACK value as invalid
   and thus send a RST.









Stewart                 Expires October 18, 2004                [Page 5]

Internet-Draft                TCP Security                    April 2004



4.  Blind data injection attack


4.1  Description of the attack


   A third type of attack is also highlighted by both reset attacks. It
   is quite possible to inject data into a TCP connection by simply
   guessing a sequence value that is within the window. The ACK value of
   any data segment is considered valid as long as it does not
   acknowledge data ahead of the next segment to send. In other words an
   ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <= SEG.ACK <
   SND.NXT). This means that an attacker simply need guess two ACK
   values with every guessed sequence number so that the chances of
   successfully injecting data into a connection are 1 in ((2^^32/
   (RCV.WND * 2)) * (2^^32/(SND.WND * 2))).


4.2  Solution


   An additional input check should be added to any incoming segment.
   The ACK value should be acceptable only if it is in the range of
   ((SND.UNA - MAX.SND.WND) <= SEG.ACK < SND.NXT). MAX.SND.WND is
   defined as the largest window that the local receiver has ever
   advertised to its peer. This window is the scaled value i.e. the
   value may be larger than 65,535 bytes. This small check will greatly
   reduce the vulnerability of an attacker guessing a valid sequence
   number since not only must he/she guess the sequence number in
   window, but must also guess a proper ack value within a scoped range.
   This solution reduces but does not eliminate the ability to generate
   false segments. It does however reduce the probability that invalid
   data will be injected to a more acceptable level when the maximum
   send and receive windows do not grow beyond 65,535 bytes. For those
   applications that wish to close this attack completely RFC2385 [2]
   should be deployed between the two endpoints.




















Stewart                 Expires October 18, 2004                [Page 6]

Internet-Draft                TCP Security                    April 2004



5.  Contributors


   The following people worked under extreme pressure and short notice
   through the 2003 holiday's to come up with a set of solutions for
   these attacks. Their contributions and ideas on how to "fix" these
   TCP weaknesses are inter-mixed with each other to arrive at the set
   of solutions presented in this document. Shrirang Bage of Cisco
   Systems, Mark Baushke of Juniper Networks, Mitesh Dalal of Cisco
   Systems, Frank Kastenholz of Juniper Networks, Amol Khare of Cisco
   Systems, Qing Li of Wind River Systems Inc., Peter Lei of Cisco
   Systems, Paul Goyette of Juniper Networks, Patrick Mahan of Cisco
   Systems, Preety Puri of Wind River Systems Inc., Anantha Ramaiah of
   Cisco Systems, Art Stine of Juniper Networks, Xiaodan Tang of QNX,
   and David Wang of Juniper Networks.






































Stewart                 Expires October 18, 2004                [Page 7]

Internet-Draft                TCP Security                    April 2004



6.  Acknowledgments


   Special thanks to Damir Rajnovic for suggestions and comments.

















































Stewart                 Expires October 18, 2004                [Page 8]

Internet-Draft                TCP Security                    April 2004



7.  References


7.1  Normative References


   [1]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.


7.2  Informative References


   [2]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
        Signature Option", RFC 2385, August 1998.



Author's Address


   Randall R. Stewart
   Editor
   8725 West Higgins Road
   Suite 300
   Chicago, IL  60631
   USA


   Phone: +1-815-477-2127
   EMail: rrs@cisco.com




























Stewart                 Expires October 18, 2004                [Page 9]

Internet-Draft                TCP Security                    April 2004



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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


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





Stewart                 Expires October 18, 2004               [Page 10]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/