Network Working Group K. Poon Internet-Draft Sun Microsystems, Inc. Expires: December 16, 2004 June 17, 2004 Use of TCP timestamp option to defend against blind spoofing attack draft-poon-tcp-tstamp-mod-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 December 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The US-CERT alert (TA04-111A) shows that the well-known weakness in TCP's segment acceptance test is easier to exploit than previously thought. While there are already mechanisms, such as RFC 2385 for BGP and IPSEC, to defend against this kind of attack, we propose a light weight method making use of TCP timetstamp option as an alternative. Poon Expires December 16, 2004 [Page 1] Internet-Draft Timestamp against spoofing June 2004 1. Requirements notation The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Poon Expires December 16, 2004 [Page 2] Internet-Draft Timestamp against spoofing June 2004 2. Introduction As specified in [RFC793], TCP's segment acceptance test in ESTABLISHED state is based on the current expected receive sequence number RCV.NXT, the receive window RCV.WND, and the received segment length SEG.LEN. For example, suppose TCP receives a RST (SEG.LEN is equal to 0), and the targeted connection's RCV.WND is 32K. As long as the SEG.SEQ of the RST is in [RCV.NXT, RCV.NXT + 32K), the received RST is considered acceptable. In this case, the TCP connection will be aborted. Another form of attack is an attacker can inject spoofed data to a TCP connection. In addition to causing data corruption, spoofed data injection may also lead to an ACK storm if the SEG.SEQ of the spoofed segment is of a proper value. As stated on Page 72 of RFC 793, if an ACK acknowledges some data never sent, TCP should send back an ACK and drop the ACK. For example, if the SEG.SEQ of the spoofed segment is RCV.NXT for receiver A, A will send back an ACK acknowledging that segment. A's peer B will send back an ACK, per Page 72 of RFC 793. But this ACK has SEG.SEQ equals to A's original RCV.NXT, which is not acceptable. A will then send back an ACK, per RFC 793. This will lead to an ACK storm. As RCV.NXT of a connection is constantly changing, and RCV.WND for most TCP connections is small comparing to the entire sequence number space, it has been thought that as long as the initial sequence number is generated in a proper way, as described in [RFC1948], blind spoofing attack on this mechanism is not considered a serious threat. An example of a blind spoofing attack is to send a large number of RSTs with different sequence numbers spread over the sequence number space to a known TCP end point. If one RST is acceptable, the connection will be aborted resulting in a denial of service. This attack can also take advantage of the fact that some protocols use well known ports so that the attacker does not need to also search the port number space for the attack to be successful. A recent study described in NISCC Vulnerability Advisory 236929 [NISCC] has shown that this kind of attack is very easy to exploit in some type of TCP connection, such as the persistent connection used in routers supporting BGP [RFC1771]. The number of segments needed to have a successful attack is far less than previously thought. And as the receive window used in TCP connection is getting larger as network speed is getting faster, this TCP weakness also becomes easier to exploit. [RFC2385] describes a method of using a TCP MD5 signature option to strength the segment acceptance test. The option contains a MD5 digest of the segment and a key known only to the two end points of a TCP connection. The receiver can then use this option to verify the Poon Expires December 16, 2004 [Page 3] Internet-Draft Timestamp against spoofing June 2004 segment's acceptability. This method not only can defend against blind spoofing attack, it can also defend against attacker who can obtain segments exchanged in a connection. IPSEC [RFC2401] is another obvious choice to use for authentication. It not only protects TCP, but other protocols over IP as well. In this document, we propose a light weight alternative to the above methods by making use of the TCP timestamp option [RFC1323]. The timestamp option already provides PAWS checking. It can also be used to strength the TCP segment acceptance test if the handling is modified a little as described in RFC1323. Poon Expires December 16, 2004 [Page 4] Internet-Draft Timestamp against spoofing June 2004 3. Motivation With the current TCP segment acceptance test, the probability of a successful blind spoofing attack is proportional to the receive window used. This assumes that an attacker can find out the ports and IP addresses being used in a connection. The obvious solution is to use cryptographic method to authenticate all TCP segments, as suggested in the other methods mentioned in the Introduction. Another possible solution to address this weakness is to put a "cookie" in every TCP segments. If the cookie is only known to the end points of a connection, it allows the receiver to verify that a segment indeed belongs to the connection by checking the segment's cookie. This is similar to the verification tag (vtag) in SCTP [RFC2960]. Note that the SCTP vtag is the same in every packets and its original use is for demultiplexing. But it can also be seen as a light weight method for defending against blind spoofing attack as an attacker needs to find out the vtag of an association to spoof any packet. The issue with the cookie mechanism is that it does not protect against a man in the middle attack. Cryptographic methods, such as the TCP MD5 option, do not have this problem. A cookie requires a new TCP option to hold the value. As the option space in a TCP header is limited, we look at the existing timestamp option to see if it can be used instead. As specified in RFC1323, the TCP timestamp option contains two values, the sender's timestamp and the echo reply of the timestamp received from its peer end point. The sender's timestamp is used for PAWS checking and the timestamp echo reply is used for RTT calculation. While the timetstamp value can be considered as an "extension" to the sequence number space, the timestamp echo reply may be considered as a "pseudo cookie." The reason is that a receiver should know exactly what timestamp values it has used to send segments to its peer, and the timestamp echo reply only contains those values. This means that a receiver should be able to verify that a timemstamp echo reply value is one of those timestamps it has used. If the timestamp option value used is not easy to guess by an attacker, the timestamp echo reply can be treated as a "pseudo cookie." Note also that the timestamp option has to be used if the receive window of a connection is large, and this is when TCP is more vulnerable to blind spoofing attack. Poon Expires December 16, 2004 [Page 5] Internet-Draft Timestamp against spoofing June 2004 4. Modified Timestamp Option Handling A TCP implementation MAY add the following modified timestamp option handling to defend against blind spoofing attack. If it is used, the implementation MUST provide a mechanism, such as a TCP socket option, for this handling to be turned on or off for individual TCP connection. A new state variable TS.Echo is added. It is initialized to be the first timestamp sent to the peer. And it is updated using the timestamp echo reply value in a segment. See below on the procedure. 4.1 Connection setup The timestamp option MUST be negotiated in setting up a connection in both passive and active open. If the peer does not accept timestamp option, send a RST to end the connection setup. SYN-SENT state SYN-RECEIVED state In SYN-SENT state, if the ACK is not acceptable according to RFC793, send back a RST and discard the segment. 4.2 RST generation On Page 18 of RFC1323, it is recommended that a RST should not contain a timestamp option and a TCP stack should ignore the timestamp option of an incoming segment if it is a RST. To make use of timestamp option for stricter segment acceptance test, we propose to change the way RST is generated in all TCP states. If a RST is sent because of one of the reasons stated in RFC793 for an incoming segment and it has a timetstamp option, the RST MUST be If the ACK bit is off, sequence number zero is used, Poon Expires December 16, 2004 [Page 6] Internet-Draft Timestamp against spoofing June 2004 If the ACK bit is on, If the incoming segment does not contain a timestamp option, send a RST without timestamp option according to RFC793. If a RST is sent because a connection is aborted, the RST MUST be 4.3 Modified acceptance test in ESTABLISHED state If an incoming segment does not contain a timestamp option, drop it. Follow RFC1323 to verify the timestamp value TSval of the segment. If it is not acceptable, follow RFC1323 to send back an ACK. If the segment is a SYN, the peer may have restarted. The TCP stack SHOULD send a keep-alive segment, as specified on Page 101 of [RFC1122], to check if the peer has really restarted. If the peer has restarted, it will send back a RST. If the segment is acceptable according to the timestamp test, verify the timestamp echo reply TSecr value. The value should be between the TS.Echo and the current timestamp. If it is not, drop the segment. If the segment is acceptable, and SEG.SEQ equals to RCV.NXT, update the TS.Echo with TSecr. Follow RFC1323 for the rest of processing. Poon Expires December 16, 2004 [Page 7] Internet-Draft Timestamp against spoofing June 2004 5. Limitations The proposed method requires both sides of a TCP connection to support the timetstamp option. This is generally not a problem in today's host TCP implementations. Most, if not all, support RFC1323 extensions. This may not be true for TCP implementations in small devices as they usually do not need to support high speed TCP transfer, thus no need for RFC1323 extensions . But those devices are also less likely to be hit by a blind spoofing attack. If only one side of a TCP connection has the proposed change, it means that the unchanged side may not send an acceptable RST to its modified peer. This is following the recommendation on Page 18 of RFC1323. And this may create a "hung" TCP connection. An application which enables this protection mechanism SHOULD use an application timer to guard against this case. When a connection has been idle for a long time T, the protection becomes weaker. Any TSecr value between TS.Echo + T is acceptable. For example, if the local clock increases 1 per 10ms and the connection has been idle of 120s, the window of acceptable TSecr is 120000. In such a case, the acceptance test MAY be modified to a stricter check as follows. If the connection has been idle for a time period longer than T, the TSecr value of an incoming segment MUST be equal to TS.Echo to be acceptable. T SHOULD be greater than 60s. Poon Expires December 16, 2004 [Page 8] Internet-Draft Timestamp against spoofing June 2004 6. Security Considerations The proposed method in this document is not a replacement of other cryptographic mechanisms for authenticating TCP segments. It only reduces the probability of a successful blind spoofing attack provided that the attacker cannot obtain segments exchanged between the two TCP end points of a connection. The initial timestamp chosen MUST not be guessed easily. A similar algorithm as in choosing a good initial sequence number, such as RFC1948, SHOULD be used. Poon Expires December 16, 2004 [Page 9] Internet-Draft Timestamp against spoofing June 2004 7. Acknowledgment The idea of using TCP timestamp option originates from discussion on the TCPM WG mailing list [TCPM]. 8 References [NISCC] National Infrastructure Security Co-ordination Centre, "NISCC Vulnerability Advisory 236929", April 2004, . [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", October 1989. [RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for High Performance", May 1992. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", March 1995. [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", August 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", November 1998. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", October 2000. [RFC793] Postel, J., "Transmission Control Protocol", September 1981. [TCPM] IETF TCPM Working Group and mailing list, "http://www.ietf.org/html.charters/tcpm-charter.html", April 2004. Poon Expires December 16, 2004 [Page 10] Internet-Draft Timestamp against spoofing June 2004 Author's Address Kacheong Poon Sun Microsystems, Inc. M/S USJC01-201 4150 Network Circle Santa Clara, CA 95054 US EMail: kacheong.poon@sun.com Poon Expires December 16, 2004 [Page 11] Internet-Draft Timestamp against spoofing June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Poon Expires December 16, 2004 [Page 12] Internet-Draft Timestamp against spoofing June 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Poon Expires December 16, 2004 [Page 13]