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]