Network Working Group K. Poon Internet-Draft Sun Expires: April 24, 2005 N. Demizu NICT October 24, 2004 Use of TCP timestamp option to defend against blind spoofing attack draft-poon-tcp-tstamp-mod-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 timestamp (RFC 1323) option as an alternative. Poon & Demizu Expires April 24, 2005 [Page 1] Internet-Draft Timestamp against spoofing October 2004 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Tracking the TSecr range . . . . . . . . . . . . . . . . . 7 4.2 Narrowing Down the Valid TSecr Range . . . . . . . . . . . 8 4.3 Unpredictable Timestamp . . . . . . . . . . . . . . . . . 9 4.4 TSval to use after the connection is idle . . . . . . . . 10 4.5 RST Handling . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 Level of Protection . . . . . . . . . . . . . . . . . . . 11 5. Modified Timestamp Option Handling . . . . . . . . . . . . . . 13 5.1 Segment Sending . . . . . . . . . . . . . . . . . . . . . 13 5.2 Segment Receiving . . . . . . . . . . . . . . . . . . . . 13 5.2.1 LISTEN, and SYN-SENT States . . . . . . . . . . . . . 13 5.2.2 Other States . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 A. Timestamp Specification Inconsistency . . . . . . . . . . . . 18 B. PASA Issues with Different TS.Recent Update Methods . . . . . 19 C. New Condition for Updating TS.Recent . . . . . . . . . . . . . 21 D. TCP PASA-OK Option . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 23 Poon & Demizu Expires April 24, 2005 [Page 2] Internet-Draft Timestamp against spoofing October 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 & Demizu Expires April 24, 2005 [Page 3] Internet-Draft Timestamp against spoofing October 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, the received segment sequence number SEG.SEQ, and length SEG.LEN. For example, suppose TCP receives a spoofed 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. The probability of an attacker guessing the correct sequence number is thus RCV.WND / 2^32. An attacker can also inject spoofed data to a TCP connection using a similar idea. 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 Poon & Demizu Expires April 24, 2005 [Page 4] Internet-Draft Timestamp against spoofing October 2004 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 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 (Protect Against Wrapped Sequence numbers) and RTTM (Round Trip Time Measurement). It can also be used to strengthen the TCP segment acceptance test if the handling is modified a little. Poon & Demizu Expires April 24, 2005 [Page 5] Internet-Draft Timestamp against spoofing October 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 use is for verifying an incoming packet indeed belongs to the intended SCTP association. 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. Poon & Demizu Expires April 24, 2005 [Page 6] Internet-Draft Timestamp against spoofing October 2004 4. Basic Idea As specified in RFC 1323, the TCP timestamp option contains two values, the sender's timestamp (TSval) and the echo reply (TSecr) of the timestamp received from its peer end point. From a receiver's view, the value of TSval in each incoming segment (SEG.TSval) is set in a monotonically increasing manner by the peer. Each value of SEG.TSval is thus greater than or equal to the value of the previous received segment unless reordering occurs or the TCP connection is idle for a significant amount of time (e.g., more than 24.8 days) such that the value wraps around. TSval is used for PAWS checking. The check is in section 4.2.1 of RFC 1323 If SEG.TSval < TS.Recent and TS.Recent is valid, the segment is rejected. The probability of guessing a valid SEG.TSval that passes the PAWS test is 1 in 2. Also see Appendix A about a specification inconsistency in [1323bis]. The value of TSecr in each incoming segment (SEG.TSecr) is the value of TSval in the last segment received by the peer that advances its RCV.NXT. The possible range of SEG.TSecr would vary from a few RTTs to a few seconds. Hence, the probability of guessing a SEG.TSecr that falls within this range would vary from 1 in 2^32 during idle time in a lossless network to around 1 in 2^20 when an ACK segment is lost, where RTO is 3 seconds and the timestamp clock frequency is 1 ms. The value of SEG.TSecr is not checked as specified in RFC 1323. TCP only uses SEG.TSecr to do RTTM. While the TSval can be considered as an "extension" to the sequence number space, the TSecr may be considered as a "pseudo cookie." The reason is that a TCP end point should know exactly what TSval values it has used to send segments to its peer, and the TSecr in every incoming segments should only contain those values. This means that a TCP end point should be able to verify that a TSecr value is one of those TSval it has used. As noted above, the probability of guessing a TSecr to fall within this valid range is not high. So the TSecr value can be treated as a "pseudo cookie." The timestamp option is normally used if the receive window of a connection is large, and this is when TCP is more vulnerable to blind spoofing attack. This makes the use of timestamp option to protect against blind spoofing attack more attractive as it is "free." 4.1 Tracking the TSecr range The first issue to resolve is how to track the TSecr valid range such Poon & Demizu Expires April 24, 2005 [Page 7] Internet-Draft Timestamp against spoofing October 2004 that a receiver can easily determine if an incoming segment is spoofed. We propose to add two new variables to the TCP connection state, TS.SndMax and TS.SndMin. TS.SndMax holds the maximum value of TSval that has been used. It is set whenever a new data segment is sent to the peer. Since the value of TSecr in every segments is copied from TS.Recent on the peer node, and the value of TS.Recent is copied from TSval, TSecr in every received segments should never exceed TS.SndMax. TS.SndMax is the upper bound of valid TSecr values in every non-spoofed segments. TS.SndMin holds the value of TSecr in every acceptable segments received which SEG.SEQ is equal to RCV.NXT. Its initial value is the value of TSval in the first segment sent, which is either the SYN or SYN|ACK segment. As TS.Recent in the peer node is monotonically increasing and TSecr is copied from TS.Recent, TS.SndMin is the lower bound of valid TSecr values in every non-spoofed segments. With these two variables, a receiver can verify if an incoming segment is valid or not by the following condition If TS.SndMin <= SEG.TSecr <= TS.SndMax, the segment is accepted. We refer the above condition as PASA (Protection Against Spoofing Attack) [PASA] test. 4.2 Narrowing Down the Valid TSecr Range To make the PASA test more effective, the valid range of TSecr must be as narrow as possible. Because of a specification inconsistency (refer to Appendix A), there can be more than one way by which TS.Recent is updated. For example, if an implementation follows section 3.4 of 1323bis, TSval in pure ACK segment can be used to update TS.Recent. But an implementation following RFC 1323 does not allow this. This causes different dynamics in the valid TSecr range and makes narrowing down the range difficult. Refer to Appendix B for a detailed explanation on how the different ways of updating TS.Recent can cause problems with the PASA test. As a sender can control what TSval to put in an outgoing segment, we propose to change the rule in generating TSval so that the PASA test can work well with different implementations using different methods of updating TS.Recent. The new rule is For TSval on segments with SEG.LEN > 0, use the current timestamp clock as specified in RFC 1323. For TSval on segments with SEG.LEN = 0, use the last value of TSval sent to the peer. Poon & Demizu Expires April 24, 2005 [Page 8] Internet-Draft Timestamp against spoofing October 2004 Making use of the newly introduced TS.SndMax, the above rule is equivalent to When sending a segment with SEG.LEN > 0, set TS.SndMax to the current timestamp clock. Use this TS.SndMax as TSval in the outgoing segment. Use TS.SndMax as TSval on segment with SEG.LEN = 0. Using this new rule, only TSval in a segment with SEG.LEN > 0 will update the TS.Recent value as other segments contain an old TSval. This rule narrows down the valid range of TSecr. Note that it does not affect RTTM as only TSecr in an incoming segment which acknowledges data is used to make measurement. This means that only the TSval in a segment with SEG.LEN > 0 is needed to update TS.Recent for RTTM. Also see Appendix C for another proposal on how to deal with this problem. 4.3 Unpredictable Timestamp To make PASA robust, it is important to keep the value of TSval used unpredictable from a malicious, off-path third party. Normally, the SEG.TSval contains the value of the local timestamp clock (my.TSclock) when a segment is sent. If a node uses one global timestamp clock as the my.TSclock for all TCP connections, it will be easy for a malicious, off-path third party to guess the valid value for TSecr. This is because the current TSval could easily be obtained by establishing another TCP connection with the target node. To defend against such attack, we propose to have a random offset to the timestamp clock for each connection or destination. The TCP connection state is augmented by one 32-bit unsigned integer, TS.SndOff. Each TSval is then calculated as my.TSclock + TS.SndOff, instead of using my.TSclock directly. The value of TS.SndOff may be a pseudo-random number or the result of F(local-node, local-port, remote-node, remote-port) where F is a cryptographic hash function. The latter is similar to the method of choosing a good initial sequence number as discussed in RFC 1948. If a new TCP connection is opened with the same four tuple of addresses of an existing TCP connection in TIME-WAIT state, the TS.SndOff should be carefully chosen so that: 1. Duplicate delayed segments are not accepted as valid segments. 2. It is hard to infer the new valid range of TSecr from the connection state of the previous TCP connection. This is to Poon & Demizu Expires April 24, 2005 [Page 9] Internet-Draft Timestamp against spoofing October 2004 avoid spoofing attack by the previous address holder in a DHCP or mobile environment. We suggest adding a random number to the existing TS.SndOff instead of assigning a newly generated random number to TS.SndOff. 4.4 TSval to use after the connection is idle When a data segment is sent after the connection is idle for a long period of time, TS.SndMax is set to the value of the current my.TSclock, and the difference between TS.SndMax and TS.SndMin will be very large until an ACK segment is returned. If the data segment or the ACK segment in reply is lost, TS.SndMin will be unchanged until the data segment sent is acknowledged after retransmission timeout. During the period when the difference is large, the probability of guessing a valid TSecr will also be large. Therefore, a method of keeping the difference small is desired. Note that this window of vulnerability is normally only a couple of RTOs. We introduce an upper limit to the advancement of TSval. If no data segment has been sent to the peer for more than the upper limit of time, then the next value of TSval used should be TS.SndMax plus the upper limit instead of the value of my.TSclock + TS.SndOff (Section 4.3). Note that TS.SndMax is still monotonically increasing with this modification. The upper limit should be long enough (at least longer than both RTT and MSL) so that there would be no side effect on other mechanisms, such as RTTM, PAWS, and Eifel [RFC3522]. A possible candidate for the upper limit will be ten minutes. This solution can easily be implemented by tweaking TS.SndOff as follows. The TCP connection state is augmented by a new variable, TS.MaxAdv, which is the upper limit of the advancement of TSval. Before sending a segment (only when TS.SndMax is updated), if (my.TSclock - TS.SndMax > TS.MaxAdv) then TS.SndOff = TS.MaxAdv - (my.TSclock - TS.SndMax) Since each TSval is calculated as my.TSclock + TS.SndOff (refer to Section 4.3), when no segment is sent for longer than TS.MaxAdv, the next TSval value used will be TSval = TS.SndMax = my.TSclock + TS.SndOff = my.TSclock + (TS.MaxAdv - (my.TSclock - old_TS.SndMax)) = old_TS.SndMax + TS.MaxAdv Poon & Demizu Expires April 24, 2005 [Page 10] Internet-Draft Timestamp against spoofing October 2004 4.5 RST Handling On Page 18 of RFC 1323, 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 PASA test, a RST needs to carry the timestamp option. We propose to change the way RST is generated in all TCP states as follows. If a RST is sent because of one of the reasons stated in RFC 793 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, If the ACK bit is on, If the incoming segment does not contain a timestamp option, send a RST without timestamp option according to RFC 793. If a RST is sent because a connection is aborted, the RST MUST be With the above changes, a valid RST containing the above TSecr will pass the PASA test and be accepted. And it is hard for an attacker to spoof such a RST segment. The problem with RST handling is that the TCP stack cannot know if its peer has this modification or not. If it receives a RST without a timestamp option, should the RST be accepted or not? This issue is discussed in the next section Section 4.6. 4.6 Level of Protection Level 0 - No Protection The PASA test requires the use of timestamp option. If the timestamp option is not used for a connection, there is no protection at all. Level 1 - Protection against spoofed segment, except RST If the timestamps option is used for a connection, a node implementing the PASA test is protected against "any" spoofed segment Poon & Demizu Expires April 24, 2005 [Page 11] Internet-Draft Timestamp against spoofing October 2004 except RST. As discussed in Section 4.5, the problem with RST is that it requires the peer to be modified for RST segment handling also. There is currently no way to communicate with the peer about this information. One solution is to introduce a new TCP option called PASA-OK (refer to Appendix D). Its purpose is to indicate that the sender of the PASA-OK option is modified to do what Section 4.5 suggests. Then the TCP stack can know if the PASA test can be used to test against RST segment. This leads to the next level of protection. Level 2 - Protection against any spoofed segment If both sides of a TCP connection know that its peer is PASA capable by using the PASA-OK option, then "no" spoofed segment will be accepted. If PASA-OK is not supported in either the local or peer node, a TCP stack SHOULD allow an application to specify that any RST segment not containing a timestamp option to be dropped. In this way, the TCP connection is protected against any spoofed segment. The only catch is that if the peer is not modified to do the RST handling in Section 4.5, the application SHOULD have some form of keep-alive probing mechanism to check the status of its peer. A PASA capable implementation SHOULD allow an application to specify the required level of protection for individual TCP connection. If required level cannot be met, the TCP connection SHOULD be aborted and a RST segment as described in Section 4.5 SHOULD be sent to its peer. If the application specifies a protection level 2 and the peer is not PASA capable (because PASA-OK option is not implemented in either the local or peer node), the stack SHOULD let the application know about this. The application can then decide whether to abort this connection. Poon & Demizu Expires April 24, 2005 [Page 12] Internet-Draft Timestamp against spoofing October 2004 5. Modified Timestamp Option Handling A TCP implementation MAY modify the timestamp option handling to support PASA as described below. If PASA 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. The TCP connection state SHOULD be augmented by four variables: TS.SndMax, TS.SndMin, TS.SndOff, and TS.MaxAdv. They should be initialized as follows. Refer to Section 4.1, Section 4.3, and Section 4.4. TS.SndOff = random number TS.SndMin = my.TSclock + TS.SndOff TS.SndMax = my.TSclock + TS.SndOff TS.MaxAdv = the upper limit to the advancement of TSval 5.1 Segment Sending When sending: 1. SYN or SYN|ACK, follow Appendix D and Section 4.6 if an application specifies a protection level. 2. RST, follow Section 4.5. 3. All other segments, if (SEG.LEN > 0) { if (my.TSclock - TS.SndMax > TS.MaxAdv) TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax ); TS.SndMax = my.TSclock + TS.SndOff; } 5.2 Segment Receiving If a TCP connection cannot be found for an incoming segment, send back a RST according to Section 4.5. If an application specifies protection level 0, follow the receive processing of RFC 1323. Otherwise, perform the following checks. 5.2.1 LISTEN, and SYN-SENT States Follow the receive processing as in RFC 793. After the segment is accepted, it SHOULD be tested for whether it satisfies the protection Poon & Demizu Expires April 24, 2005 [Page 13] Internet-Draft Timestamp against spoofing October 2004 level required by the application (either 1 or 2). This means that the received segment MUST carry the TCP Timestamps option. If not, send back a RST according to Section 4.5. If the TCP is in SYN-SENT state, the connection should be aborted. 5.2.2 Other States The incoming segment is a RST. 1. Protection level is 1: Follow the RFC 1323 receive processing. 2. Protection level is 2: If the segment does not contain the timestamp option, drop it. Otherwise, perform the PASA test on the. If the test fails, drop the RST segment. If not, follow the RFC 1323 receive processing. The incoming segment is not a RST. If the segment does not contain the timestamp option, drop it. Otherwise, perform the PASA test on the incoming segment. If the test fails, an ACK segment SHOULD be sent in reply as specified on page 69 of RFC 793. Then drop the segment. Note that this rule is the same as that of PAWS in RFC 1323. If the PASA test succeeds, if (TS.SndMin < SEG.TSecr && SEG.SEQ == RCV.NXT) TS.SndMin = SEG.TSecr; Follow RFC 1323 for the rest of processing. Poon & Demizu Expires April 24, 2005 [Page 14] Internet-Draft Timestamp against spoofing October 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. Poon & Demizu Expires April 24, 2005 [Page 15] Internet-Draft Timestamp against spoofing October 2004 7. Acknowledgement The idea of using TCP timestamp option originates from discussion on the TCPM WG mailing list [TCPM]. 8 References [1323bis] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for High Performance", (work in progress) draft-jacobson-tsvwg-1323bis-00.txt, August 2003. [NISCC] National Infrastructure Security Co-ordination Centre, "NISCC Vulnerability Advisory 236929", April 2004, . [PASA] Demizu, N., "Protection Against Spoofing Attacks by Using the TCP Timestamps Option", (work in progress) draft-demizu-tcpm-pasa-issues-00.txt, October 2004. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", RFC 1122, October 1989. [RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, 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", RFC 2960, October 2000. [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003. Poon & Demizu Expires April 24, 2005 [Page 16] Internet-Draft Timestamp against spoofing October 2004 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [TCPM] IETF TCPM Working Group, "http://www.ietf.org/html.charters/tcpm-charter.html", April 2004. Authors' Addresses Kacheong Poon Sun Microsystems, Inc. M/S USJC01-201 4150 Network Circle Santa Clara, CA 95054 USA EMail: kacheong.poon@sun.com Noritoshi Demizu National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei Tokyo 184-8795 Japan EMail: demizu@nict.go.jp Poon & Demizu Expires April 24, 2005 [Page 17] Internet-Draft Timestamp against spoofing October 2004 Appendix A. Timestamp Specification Inconsistency When RFC 1323 was updated by 1323bis, one important change was when to update TS.Recent as there was an inconsistency in RFC 1323. Section 3.4 of RFC 1323 specifies that if the following condition is true, TS.Recent is updated. SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN - (A) But in section 4.2.1 of RFC 1323, it uses this condition instead. SEG.SEQ <= Last.ACK.sent In 1323bis, this inconsistency was clarified and the condition was updated as SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent - (B) There is still a problem. Note that there is a step (R2) in section 4.2 of both RFC 1323 and 1323bis. (R2) specifies that if an incoming segment is not inside the receive window, the segment is rejected. This is done before the condition comparing SEG.SEQ and Last.ACK.Sent is checked. In effect, if (R2) is done, the condition (B) will become if (SEG.LEN > 0) SEG.SEQ <= Last.ACK.sent <= RCV.NXT < SEG.SEQ + SEG.LEN else if (SEG.LEN == 0) SEG.SEQ == Last.ACK.sent == RCV.NXT - (B') Another confusing fact is that the step (R2) is not shown in the Appendix E PSEUDO-CODE SUMMARY of 1323bis. Because of the above, an implementation may choose any one of the conditions for updating TS.Recent. As commented in Appendix C of 1323bis, it is good to be able to use the TSval in "a retransmitted segment that resulted from a lost ACK" (meaning duplicate segment). Both (A) and (B') do not allow this. We propose to change the condition to be SEG.TSval >= TS.Recent and RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent Using this condition, TS.Recent is also updated by duplicate segments. Poon & Demizu Expires April 24, 2005 [Page 18] Internet-Draft Timestamp against spoofing October 2004 Appendix B. PASA Issues with Different TS.Recent Update Methods As noted in Appendix A, there are different methods in updating TS.Recent. As TSecr in a segment is copied from TS.Recent, this means that the valid range of TSecr can be different if the peer uses different methods to update TS.Recent. This affects the effectiveness of the PASA test. If a peer node uses condition (A) in Appendix A to update TS.Recent, the valid range of SEG.TSecr would be within a few RTTs almost all the time. The reason is that TS.Recent on the peer node is updated only by new data segments. It is never updated by duplicate data segments, window updates, or keep-alive segments. Therefore, in cases where no segment is lost, the difference between TS.SndMax and TS.SndMin will be at most around one RTT. And when a TCP connection becomes idle, the difference will typically be zero. Even in cases where some segments are lost, if the losses are recovered soon, say within a few RTTs, the difference will be at most around a few RTTs. If a peer node uses condition (B), the valid range of SEG.TSecr can be very large for a long period of time. The reason is that TS.Recent on the peer node is updated by non-data segments, such as window updates and keep-alive probes. Assuming that the TCP also follows the rule specified in RFC 1323 in generating TSval in an outgoing segment. This means that TS.SndMax is updated whenever any segment is sent. When a non-data segment is sent, TS.SndMin may not be updated soon because no segment may be sent back in reaction to that non-data segment. Consequently, the difference between TS.SndMax and TS.SndMin can become very large for a long period of time. The following are examples of scenarios where the valid range of TSecr is very large. Note: In the examples below, TS.SndMax is updated whenever any segment is sent. Example 1 - Window updates Window updates can be delayed for a long period of time, because they are sent when an application reads data. For example, when an application is displaying a modal dialog and waiting for a user's input, it often does not read the received data until the modal dialog is closed. As another example, if a user suspends an application for a long time, it cannot read received data during the suspended period. In such cases, upon sending a window update, TS.SndMax is advanced while TS.SndMin stays unchanged. The difference between TS.SndMax and TS.SndMin can become very large. And TS.SndMax and TS.SndMin will stay unchanged until some segments are exchanged. Poon & Demizu Expires April 24, 2005 [Page 19] Internet-Draft Timestamp against spoofing October 2004 Example 2 - TCP receives a keep-alive probe from its peer The interval between TCP keep-alive probes is typically a couple of hours. When a peer node sends a TCP keep-alive probe, the TSecr in the probe segment contains an old timestamp near the value of TS.SndMin, which is a couple of hours earlier. TCP responds to the probe with an ACK segment which has a TSval equals to the current timestamp clock, TS.SndMax also needs to be updated to that value. But TS.SndMin is not updated in this scenario. Hence, the difference between TS.SndMax and TS.SndMin will become a couple of hours until some segments are exchanged afterwards. Example 3 - TCP sends a keep-alive probe to its peer In the case when TCP sends a keep-alive probe to its peer, if the keep-alive probe or its corresponding ACK segment is lost, the difference between TS.SndMax and TS.SndMin will be a couple of hours until the TCP keep-alive procedure finishes successfully after retransmitting the probe. At that time, TS.SndMax and TS.SndMin will become the same again. Fortunately, this should normally take a couple of RTTs. Poon & Demizu Expires April 24, 2005 [Page 20] Internet-Draft Timestamp against spoofing October 2004 Appendix C. New Condition for Updating TS.Recent As seen in Appendix B, the essential difference between conditions (A) and (B) is that TS.Recent in a node using (A) is updated only by new data segments while TS.Recent in a node using (B) can be updated by duplicate data segments and non-data segments. Taking into account of (B') in Appendix A, we propose the following condition to replace both (A) and (B) RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent && SEG.LEN > 0 - (C) If a peer node uses (C), the valid range of SEG.TSecr would be narrower than that of a peer node using (A) or (B). It does not have the problems discussed in Appendix B. Furthermore, (C) also provides RTT measurements for retransmitted segments like (B). Using condition (C) to update TS.Recent can be considered as an alternative to the method proposed in Section 4.2. The problem with this is that it requires all peer nodes to be modified. This is a difficult deployment issue to overcome. Poon & Demizu Expires April 24, 2005 [Page 21] Internet-Draft Timestamp against spoofing October 2004 Appendix D. TCP PASA-OK Option The TCP PASA-OK option indicates that the sender supports PASA. This option MAY be sent on a SYN segment. It also MAY be sent on a SYN|ACK segment, but only if the option is received in the corresponding SYN segment. This option SHOULD not be sent in other segments. As discussed in Section 4.6, this option is not mandatory in order to provide protection level 2. The format of the TCP PASA-OK option is +--------+--------+ |Kind=TBD|Length=2| +--------+--------+ If the TCP PASA-OK option is sent on a SYN or SYN|ACK segment, the TCP Timestamps option MUST be sent on the same segment. Implementation note: These two TCP options can be sent in the following format. +--------+--------+--------+--------+ |PASA-OK | Len=2 | TSopt | Len=10 | +--------+--------+--------+--------+ | TSval | +--------+--------+--------+--------+ | TSecr | +--------+--------+--------+--------+ In the above diagram, the TSval is equal to TS.SndMax. The TSecr is equal to 0 if it is a SYN segment. If it is a SYN|ACK segment, the TSecr is equal to the TSval in the corresponding SYN segment. Poon & Demizu Expires April 24, 2005 [Page 22] Internet-Draft Timestamp against spoofing October 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 procedures with respect to rights in RFC 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. Poon & Demizu Expires April 24, 2005 [Page 23]