Network Working Group Noritoshi Demizu INTERNET-DRAFT NICT Expires: April 18, 2005 October 18, 2004 Protection Against Spoofing Attacks by Using the TCP Timestamps Option 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, or will be 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo describes a method of protecting TCP connections against off-path, third party spoofing attacks, by making use of the TCP Timestamps option specified in RFC1323. The original basis of the idea was proposed by Kacheong Poon. This memo discusses its issues to add complementary ideas to his original approach. Viable ideas in this memo will be incorporated into his upcoming draft. Demizu Expires April 2005 [Page 1] Internet-Draft October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Tracking the Range . . . . . . . . . . . . . . . . . . . . 5 4.2 Narrowing the Range . . . . . . . . . . . . . . . . . . . . 6 4.3 Unpredictable Timestamps . . . . . . . . . . . . . . . . . 12 4.4 Changing the Range Slowly . . . . . . . . . . . . . . . . . 13 4.5 Timestamps to Send . . . . . . . . . . . . . . . . . . . . 15 4.6 Protection Levels . . . . . . . . . . . . . . . . . . . . . 18 4.7 Timestamps to Accept . . . . . . . . . . . . . . . . . . . 20 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1 Inequalities (A), (B), and (C) vs. RTTM, PAWS, and Eifel . 21 5.2 Proposal (2d) vs. RTTM, PAWS, and Eifel . . . . . . . . . . 23 5.3 Comparison of Proposed Solutions of Section 4.2 . . . . . . 24 6. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1 TCP PASA-OK option . . . . . . . . . . . . . . . . . . . . 25 6.2 Timestamps to Send . . . . . . . . . . . . . . . . . . . . 26 6.3 Protection Levels . . . . . . . . . . . . . . . . . . . . . 26 6.4 Timestamps to Accept . . . . . . . . . . . . . . . . . . . 28 6.5 The Processing Rule of PASA . . . . . . . . . . . . . . . . 29 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Demizu Expires April 2005 [Page 2] Internet-Draft October 2004 1. Introduction This memo describes a method of protecting TCP connections against off-path, third party spoofing attacks, by making use of the TCP Timestamps option [RFC1323]. In this memo, the proposed method of protecting against spoofing attacks is called PASA (Protection Against Spoofing Attacks). The original basis of this idea was proposed by Kacheong Poon [Poon04]. This memo discusses its issues to provide complementary ideas to his original idea. Viable ideas in this memo will be incorporated into his upcoming draft. This memo would provide background thought behind the method. This memo is organized as follows. Section 2 describes the problems caused by spoofing attacks. Section 3 introduces the basic idea for protection against these attacks. Section 4 introduces key issues and proposals, which are discussed further in section 5. Section 6 specifies the components of the PASA method, while section 7 gives examples of how it works. Section 8 and 9 discuss security and IANA considerations, respectively. In short, the purpose of sections 3 through 5 is to give the technical reasoning behind the specification described in section 6. The key words "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]. 2. Problem Description <<>> o Spoofing attacks to abort TCP connections by using RST segments. o Spoofing attacks to abort TCP connections by using SYN segments. o Spoofing attacks to close TCP connections by using FIN segments. o Spoofing attacks to break TCP connections by using ACK segments. o Spoofing attacks to inject false data segments. 3. Basic Idea The TCP Timestamps option [RFC1323] has two fields: TSval and TSecr. From the receiver's point of view, the values of these fields are recognized as follows. Demizu Expires April 2005 [Page 3] Internet-Draft October 2004 o TSval The value of SEG.TSval (i.e., TSval on each incoming segment) is determined in a monotonically non-decreasing manner by the peer node. Each value of SEG.TSval is thus greater than or equal to the value for the previous segment unless reordering occurs or the TCP connection is idle for a significant amount of time (e.g., more than 24.8 days). The value of SEG.TSval is checked by PAWS (Protect Against Wrapped Sequence numbers) [RFC1323]. The probability of guessing a valid SEG.TSval is 1 in 2. o TSecr The value of SEG.TSecr (i.e., TSecr on each incoming segment) is the value of TSval on the last segment that advanced the left edge (RCV.NXT) of the receiving window of the peer node. The valid range of SEG.TSecr would vary from a few RTTs to a few seconds. Hence, the probability of guessing a valid SEG.TSecr would vary from 1 in 2^32 during idle 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, however, is not checked. Since the probability of guessing a valid SEG.TSecr is not very high, SEG.TSecr can be used to provide an additional obfuscation mechanism. In other words, TCP connections can be protected against off-path, third party spoofing attacks at a certain level by checking the SEG.TSecr values of incoming segments. This is the basic idea of PASA. This memo recommends using PAWS together with PASA as an additional obfuscation mechanism. [RFC1323] proposes to use the TCP Timestamps option for two mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequence numbers). [RFC3522] proposes another mechanism using this option: Eifel. This memo proposes yet another new mechanism based on the TCP Timestamp option. [RFC1323] suggests but does not recommend checking the SEG.TSecr values of incoming segments as a means of implementing PAWS. Since the purpose of this proposal is different from that of PAWS and it is not intended as a replacement for PAWS, the reason why [RFC1323] does not recommend checking SEG.TSecr does not apply to this memo's proposal. Demizu Expires April 2005 [Page 4] Internet-Draft October 2004 4. Issues The design of PASA involves the following issues. 1. Tracking the valid range of SEG.TSecr. 2. Keeping the valid range of SEG.TSecr narrow. 3. Making timestamps unpredictable. 4. Changing the valid range of SEG.TSecr slowly 5. Determining the timestamps that can be sent securely. 6. Classifying the protection levels. 7. Determining the timestamps that can be accepted securely. This section discusses each of these issues one by one. 4.1 Tracking the Range The key to this proposal is keeping track of the valid range of SEG.TSecr accurately. This memo proposes tracking both the maximum and the minimum values of SEG.TSecr. The TCP per-connection state is augmented by two timestamps: TS.SndMax and TS.SndMin. o TS.SndMax --- Tracks the maximum valid value of SEG.TSecr. Definition: TS.SndMax holds the maximum value of TSval that has been sent. Description: TS.SndMax is monotonically non-decreasing. The maximum value of TSval that has been sent is equal to the value of TSval on the last data segment sent, because the value of TSval on outgoing segments is monotonically non-decreasing. Since the value of SEG.TSecr is copied from TS.Recent on the peer node, and the value of TS.Recent is copied from SEG.TSval on segments sent by the local node, SEG.TSecr never exceeds TS.SndMax. When the TCP connection is idle, SEG.TSecr is typically equal to TS.SndMax. Therefore, TS.SndMax is exactly the upper limit of valid SEG.TSecr values. Demizu Expires April 2005 [Page 5] Internet-Draft October 2004 o TS.SndMin --- Tracks the minimum valid value of SEG.TSecr. Definition: TS.SndMin holds the maximum value of SEG.TSecr that has been received for an acceptable segments [RFC793]. Its initial value is the value of TSval on the first segment sent. Description: TS.SndMin is monotonically non-decreasing. Since TS.Recent on a peer node is monotonically non-decreasing and SEG.TSecr is copied from TS.Recent on the peer node, SEG.TSecr is also monotonically non-decreasing and is never less than TS.SndMin, unless segments are reordered. Taking account of reordering, it would be possible to choose an appropriate margin "T1" so that SEG.TSecr would not exceed TS.SndMin - T1 for almost all cases. Possible candidates for the value of T1 would be one RTT or RTO. A TCP module would maintain the estimated RTT and RTO from the sender's point of view according to [RFC2988]. Although the actual RTT from the receiver's point of view might be different from the estimated RTT from the sender's point of view, especially for asymmetric paths, the estimated RTT or RTO from the sender's point of view would be a candidate for T1. Note: TS.SndMin is the same as TS.Echo proposed in [Poon04]. Therefore, SEG.TSecr on any valid incoming segment is expected to satisfy the following inequality with an appropriate margin "T1": TS.SndMin - T1 <= SEG.TSecr <= TS.SndMax, where T1 = RTT or RTO. This memo proposes to test incoming segments by applying this inequality in order to detect spoofed segments. This test is called the "PASA test" in this memo. 4.2 Narrowing the Range To make PASA effective, it is important to keep the valid range of SEG.TSecr as narrow as possible. In fact, the width of the valid range depends on the implementation of the TCP Timestamps option on a peer node. Demizu Expires April 2005 [Page 6] Internet-Draft October 2004 4.2.1 Variants of the Timestamps Option There are two implementation variants of the TCP Timestamps option. The difference lies in the conformance level to the inequality defined in step (2) in section 3.4 of [RFC1323]. o Some implementations use the following inequality: SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN ... (A) Note: (A) appears in step (2) in section 3.4 of [RFC1323]. o Other implementations use the following inequality: SEG.SEQ <= Last.ACK.sent ... (B) Note: (B) appears in step R3) in section 4.2.1 of [RFC1323]. It also appears in section 3.4 of both [JBB97] and [JBB03] as "SEG.TSval >= TS.Recent and SEG.SEQ <= Last.ACK.sent". For simplicity, here we ignore "SEG.TSval >= TS.Recent", because it is part of the PAWS test and does not affect the discussion below. If a peer node complied with inequality (A), 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 was lost, the difference between TS.SndMax and TS.SndMin would be at most around one RTT. And when a TCP connection became idle, the difference would typically become zero. Even in cases where some segments were lost, if the losses were recovered soon, within a few RTTs, the difference would be at most around a few RTTs. There are exceptions, however: if a recovery procedure after a loss took a long period of time with numbers of unsuccessful retransmission timeouts, the valid range of SEG.TSecr would become wide. Under such bad situations, the best case would be where all retransmitted data segments except the last one are lost. In this case, TS.SndMax is updated on each retransmission timeout while TS.SndMin is unchanged. When the loss is recovered, however, TS.SndMin becomes equal to TS.SndMax. The worst case would be where the first data segment arrives at the receiver, while all ACK segments except one for the last retransmitted data segment are lost. In this case, TS.SndMin keeps the time before the retransmission started, while TS.SndMax holds the time when a segment was last sent. Even when the loss is recovered, TS.SndMin is not changed because TS.Recent on the peer node is not updated Demizu Expires April 2005 [Page 7] Internet-Draft October 2004 by duplicate data segments. Hence, the difference between TS.SndMax and TS.SndMin becomes large, and they would stay unchanged until some segments were exchanged afterwards. In any case, since the recovery period would be less than several minutes, and the probability of these exceptional cases occurring would not be high, these cases would not be a big problem. On the other hand, if a peer node complies with inequality (B), the valid range of SEG.TSecr could be very wide 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 segments. Therefore, TS.SndMax MUST be updated whenever any segment is sent in order for the peer node to comply with (B). When such non-data segments are sent, however, TS.SndMin could not be updated because no segment might be sent back. Consequently, the difference between TS.SndMax and TS.SndMin could become very wide for a long period of time. The following are examples of scenarios where the valid range of SEG.TSecr would become very wide. Note: In the examples below, TS.SndMax is updated whenever any segment is sent. Ex. 1 Window updates. Window updates could 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 (e.g., by typing ^Z) for a long time, it cannot read received data during the suspended period. In such cases, upon sending window updates, TS.SndMax would be advanced while TS.SndMin would stay unchanged. The difference between TS.SndMax and TS.SndMin would become larger and nearly equal to the difference between the time when all data are received by the TCP module and the time when all data are read by the application. Even worse, TS.SndMax and TS.SndMin would stay unchanged until some segments were exchanged afterwards. Ex. 2 TCP keep-alive from a peer node. The interval between TCP keep-alive procedures is typically a couple of hours. In the case where a peer node starts the TCP keep-alive procedure, SEG.TSecr on each incoming keep-alive segment contains an old timestamp near the value of TS.SndMin, indicating a couple of hours earlier. The local node responds with an ACK segment whose TSval contains the current timestamp clock, which is equivalent to TS.SndMax. Note that TS.SndMin Demizu Expires April 2005 [Page 8] Internet-Draft October 2004 is never updated in this scenario. Hence, the difference between TS.SndMax and TS.SndMin would become a couple of hours until some segments were exchanged afterwards. Ex. 3 TCP keep-alive from a local node. The interval between TCP keep-alive procedures is typically a couple of hours, and the interval between retransmissions of TCP keep-alive segments is normally very long compared to RTT. In the case where a local node starts the TCP keep-alive procedure, if a keep-alive segment or its corresponding ACK segment was lost, the difference between TS.SndMax and TS.SndMin would be a couple of hours until the TCP keep-alive procedure finished successfully. Fortunately, in this case, TS.SndMax and TS.SndMin would become the same once the TCP keep-alive procedure finished. In summary: o If a peer node complies with (A) and the local node knows this, the valid range of SEG.TSecr will be within a few RTTs almost all the time, and there will be no problem with executing PASA. o If a peer node complies with (B) or the local node does not know which inequality the peer node complies with, TS.SndMax MUST be updated whenever any segment is sent. Therefore, the valid range of SEG.TSecr could be very wide for a long period of time. This problem should be solved. 4.2.2 Proposed Solutions for (B) The following proposals could be applied in response to the problem introduced by nodes complying with (B), as described above. (2a) Modify all peer nodes to comply with (A). (2b) Inspect the variant types of peer nodes. (2c) Introduce a new inequality (C). (2d) Change the rule generating TSval. These proposals are described below, and they are compared in section 5.3. Note: Section 5.3 currently recommends (2d), and counts (2c) as the second candidate. Readers may skip other proposals. The author believes rejected proposals would inspire readers to invent better proposals than (2c) or (2d). Rejected proposals will be removed in future revisions, however. Demizu Expires April 2005 [Page 9] Internet-Draft October 2004 4.2.2.1 Proposal (2a) Proposal (2a) would modify all peer nodes to comply with (A). Since (B) provides better RTT measurements for retransmitted segments than does (A), (B) would supposedly be deployed widely. Therefore, (2a) would be deployable only where administrators consider PASA much more important than the advantages of using (B) and all peer nodes are under control of such administrators. Hence, it would be difficult to deploy (2a) widely. Interactions between inequality (A) and RTTM, PAWS, and Eifel are discussed in sections 5.1. Pros. No need to invent a new mechanism. Cons. Every peer node complying with (B) must be modified. 4.2.2.2 Proposal (2b) Proposal (2b) would inspect the variant type of the peer node and switch the behavior of the local node properly. The outline of this procedure is as follows: TS.SndMax should be updated whenever any segment is sent, until the variant type of the peer node can be inferred. When a TCP connection is idle, inspect the variant type of the peer node by using the procedure described below. If the peer node complies with (A), switch the rule for updating TS.SndMax to the one described in section 4.1. If the peer node complies with (B), or if its variant type has not yet been inspected, then when the valid range of the TCP connection becomes wide, start the TCP keep-alive procedure in order to make the valid range on the local node narrow, as described below. The variant type of a peer node can be inspected by applying the following procedure: When a TCP connection is idle for more than several RTOs, update TS.SndMax with the current timestamp clock, send a TCP keep-alive segment whose TSval contains TS.SndMax, and wait for an ACK segment. o If SEG.TSecr on the returned ACK segment is near TS.SndMin, the peer node would comply with (A). o If SEG.TSecr on the returned ACK segment is equal to TS.SndMax, the peer node would comply with (B). This test can be rewritten as follows: Demizu Expires April 2005 [Page 10] Internet-Draft October 2004 If (TS.SndMin - T1 <= SEG.TSecr < TS.SndMax), then (A). If (SEG.TSecr == TS.SndMax), then (B). If the peer node complies with (B), do the following: When the TCP connection is idle, if the valid range of SEG.TSecr has been wide for a certain period of time, the node should start the TCP keep-alive procedure. After the keep-alive procedure finishes successfully, the valid range of SEG.TSecr on the node will be narrow. Note that this procedure only makes the valid range of the local node narrow. It does not make the valid range on the peer node narrow. Therefore, both nodes may need to start this procedure independently. Pros. Peer nodes need not be modified. Cons. The implementation would be very complex. 4.2.2.3 Proposal (2c) Proposal (2c) would introduce a new inequality for peer nodes. As seen in section 4.2.1, the essential difference between (A) and (B) is that TS.Recent on a node complying with (A) is updated only by new data segments, while TS.Recent on a node complying with (B) is updated by any segment including duplicate data segments and non-data segments. If inequality (A) was modified so that TS.Recent was updated by both new and duplicate data segments, the worst case among the exceptional cases described in section 4.2.1 would be mitigated. If inequality (B) was modified so that TS.Recent was not updated by non-data segments, the valid range of SEG.TSecr would become narrow enough. The inequalities from both modifications are fortunately the same. In addition, it would be better to set the lower limit of SEQ.SEQ. The proposed inequality is the following: RCV.NXT - RCV.WND <= SEG.SEQ <= Last.ACK.sent && (SEG.LEN > 0 || SYN || FIN) ... (C) If a peer node complied with (C), the valid range of SEG.TSecr would be narrower than that of the case where a peer node complied with (A) or (B). Furthermore, (C) would provide good RTT measurements for retransmitted segments like (B). Interactions between inequality (C) and RTTM, PAWS, and Eifel are discussed in sections 5.1. Demizu Expires April 2005 [Page 11] Internet-Draft October 2004 Unfortunately, (2c) would require all peer nodes to be modified. Hence, (2c) would be deployable only where all peer nodes were under control or cooperative. This would take many years to deploy. Pros. The valid range of SEG.TSecr would be the narrowest among all proposals. Cons. Every peer node must be modified. There may be unknown side effects. 4.2.2.4 Proposal (2d) Proposal (2d) would change the rule generating TSval in the local node. The new rule to generate TSval would be the following: For TSval on data segments, use the current timestamp clock, as specified in [RFC1323]. For TSval on non-data segments, use the same value of TSval on the last data segment. In other words, Update TS.SndMax before sending a data segment. Then, use TS.SndMax for TSval on any segment. With this rule, regardless of the variant type of a peer node, TS.Recent on the peer node would be updated only by data segments. Hence, PASA would work well with this rule. Since (2d) does not require peer nodes to be modified, it would be readily deployable. Currently, there is no known side effect of (2d) as discussed in section 5.2. Pros. Peer nodes need not be modified. Cons. There may be unknown side effects. 4.3 Unpredictable Timestamps Note: This section is based on the idea in section 6 of [Poon04]. To make PASA robust, it is important to keep the value of TSval sent in the TCP Timestamps option unpredictable from a malicious, off-path third party. According to [RFC1323], TSval contains the value of the timestamp clock when the segment was sent. Section 4.2.2.4 proposes a variant. Demizu Expires April 2005 [Page 12] Internet-Draft October 2004 In either cases, if a node uses one global timestamp clock for all TCP connections, it would be easy for a malicious, off-path third party to guess a valid value for SEG.TSecr, because the current TSval could easily be obtained by establishing a new TCP connection with the target node. To defend against such attacks, this memo proposes a random offset to the timestamp clock for each connection or destination. That is, the TCP per-connection state is augmented by one 32-bit unsigned integer: TS.SndOff. Each timestamp is calculated as my.TSclock + TS.SndOff, instead of using my.TSclock directly. Here, my.TSclock represents the "local source of 32-bit timestamp values" [RFC1323]. 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. Note: This is suggested in section 6 of [Poon04]. If a new TCP connection is opened with an existing tuple of addresses and ports, then the new TS.SndOff should be carefully chosen so that: - Duplicate delayed segments are not accepted as valid segments. - It is hard to infer a new valid range for SEG.TSecr in order to avoid spoofing attacks by previous address holders in dial-up or DHCP environments. To achieve these requirements, this memo suggests adding a random number to the existing TS.SndOff instead of assigning a newly generated random number to TS.SndOff. 4.4 Changing the Range Slowly To keep PASA safe, it is important not to leap TS.SndMax in order to always keep the difference between TS.SndMax and TS.SndMin small. Otherwise, spoofed segments could be injected at an unguarded moment. 4.4.1 Incrementing TS.SndMax Gradually When a data segment is sent after a long period of idle, TS.SndMax would be set to the value indicating the current timestamp clock, and the difference between TS.SndMax and TS.SndMin would be very wide until an ACK segment would be returned. If the data segment or the ACK segment in reply was lost, TS.SndMin would be unchanged until an ACK segment would be returned after the next or later retransmission Demizu Expires April 2005 [Page 13] Internet-Draft October 2004 timeouts. During the moment when the difference is large, the probability of guessing a valid SEG.TSval would also become large. Therefore, a method of keeping the difference small is required. The following method would prevent such accidental spoofing attacks. Introduce an upper limit to the advancement of TS.SndMax. If any data segment has not been sent on a TCP connection for more than the upper limit of time, then the next value of TS.SndMax should be TS.SndMax plus the upper limit instead of the value indicating the current timestamp clock. Note that TS.SndMax is still monotonically non-decreasing 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. A possible candidate for the upper limit would be one hour, ten minutes, etc. This solution can easily be implemented by tweaking TS.SndOff as follows: The TCP per-connection state is augmented by a timestamp: TS.MaxAdv Initially: TS.MaxAdv = the upper limit of the advancement of TS.SndMax Before sending a segment: (Only when TS.SndMax will be updated) if (my.TSclock - TS.SndMax > TS.MaxAdv) then TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax ) Since each timestamp is calculated as my.TSclock + TS.SndOff (See section 4.3), when a data segment had not been sent for more than the time indicated by TS.MaxAdv, the next TSval value would be as intended as follows. TSval = TS.SndMax = my.TSclock + TS.SndOff = my.TSclock + (TS.MaxAdv - (my.TSclock - old_TS.SndMax)) = old_TS.SndMax + TS.MaxAdv 4.4.2 Keeping the Range Smaller Than 2^31 If the difference between TS.SndMax and TS.SndMin became larger than or equal to 2^31, the PASA test introduced in section 4.1 would not Demizu Expires April 2005 [Page 14] Internet-Draft October 2004 work at all, because TS.SndMax and TS.SndMin are 32-bit unsigned integer. Hence, the difference must be kept less than 2^31. It would be already achieved by the combination of the method proposed in section 4.4.1 and the TCP timeout mechanisms. Only in the case where this assumption could be false, the following method would guarantee that the PASA test would be performed only when the difference was smaller than 2^31. Introduce a boolean variable: TS.Valid. On sending a segment: if (TS.SndMax < TS.SndMin), then TS.Valid = false. On receiving a segment: if (TS.SndMax >= TS.SndMin), then TS.Valid = true. if (TS.Valid is true), then perform the PASA test. Otherwise, treat the segment as if it passed the PASA test. 4.5 Timestamps to Send To make PASA workable under all circumstances, it is important to appropriately choose the timestamp values of TSval and TSecr in the TCP Timestamps option on outgoing segments. 4.5.1 In-connection Segments and Out-of-connection Segments To discuss the timestamp values on segments being sent, this memo introduces two terms: "in-connection segments" and "out-of-connection segments." All incoming and outgoing segments are grouped into one of these categories. o In-connection segments In-connection segments are those that could be exchanged in a normal TCP connection. They would appear in a TCP connection in synchronizing, synchronized, or desynchronizing states. Examples: SYN and SYN+ACK segments to establish a TCP connection, a data segment, an ACK segment, a FIN segment to close a TCP connection, a RST segment to abort a TCP connection, a keep-alive segment, a window update segment, a retransmitted segment, a delayed segment, etc. Demizu Expires April 2005 [Page 15] Internet-Draft October 2004 o Out-of-connection segments Out-of-connection segments are those incoming segments that are apparently not intended for a given TCP connection and those outgoing segments sent in reply to such incoming segments. They would appear in accidentally desynchronized TCP connections or half-open TCP connections. Examples: an incoming segment for which [RFC793] specifies that a RST segment should be sent in reply, and such a RST segment sent in reply. Note: The author thought there would be other examples before. But now the author believes these two are the only examples of "out-of-connection segments," and all other segments should be grouped into "in-connection segments." Thus, these terms should be renamed to more descriptive ones. The timestamp values in the TCP Timestamps option on outgoing segments should be discussed separately for these two groups of segments, because they have different requirements. The timestamp values for an outgoing in-connection segment should be chosen so that the segment will pass both the PASA test and the PAWS test at the peer node if the TCP connection is alive. The timestamp values also should be meaningful for other mechanisms, such as RTTM and Eifel. The timestamp values for an outgoing out-of-connection segment should be chosen so that the segment will pass both the PASA test and the PAWS test at the remote node to indicate that the TCP connection is desynchronized, if the corresponding incoming segment came from the remote node. On the other hand, if the corresponding incoming segment was spoofed, it would be better, but not required, for the outgoing segment to fail either the PASA test or the PAWS test at the remote node in order to suppress possible negative effects, such as a needless Fast Retransmit. In either cases, the timestamp values can be meaningless for other mechanisms such as RTTM and Eifel, because the TCP connection would be not synchronized. Since the local node does not have any state for the unsynchronized TCP connection, the timestamps values for an outgoing segment should be generated from the timestamp values on the corresponding incoming segments. 4.5.2 Timestamps on RST Segments To protect TCP connections against spoofed RST segments by using PASA, genuine RST segments need to carry the TCP Timestamps option in Demizu Expires April 2005 [Page 16] Internet-Draft October 2004 order to be distinguished from spoofed RST segments. [RFC1323], however, states, "It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp." The purpose of this recommendation would be to make out-of-connection RST segments sent in reply to incoming out-of-connection segments acceptable to remote nodes. Hence, in-connection RST segments would be able to carry the TCP Timestamps option with the timestamp values as specified in [RFC1323], because they would pass both the PASA test and the PAWS test at the peer nodes if the TCP connection is synchronized. On the other hand, to make it possible for outgoing out-of-connection RST segments to carry the TCP Timestamps option, we would need a special rule for their timestamp values. The rule would be the same as that for outgoing out-of-connection non-RST segments, which is discussed below in section 4.5.4. Thus, to make PASA functional, this memo recommends that RST segments DO carry timestamps with the special rule described later in this memo, and that RST segments be tested by both PASA and PAWS. Note: This is proposed in section 4.2 of [Poon04]. 4.5.3 Timestamps on In-connection Segments The timestamp values in the TCP Timestamps option on an outgoing in-connection segment should be suitable for any mechanisms such as RTTM, PAWS, and Eifel, as discussed in section 4.5.1, if the TCP connection is synchronized. [RFC1323] specifies the values as , which satisfies the requirement above. Regarding PASA, in cases where proposal (2a), (2b), or (2c) is chosen as described in section 4.2, PASA would work with the timestamp values specified by [RFC1323]. On the other hand, to make PASA work in the case of proposal (2d), the TSval value SHOULD be TS.SndMax instead of my.TSclock. In any case, the same timestamp values would be applicable to RST segments, as suggested in section 4.5.2. As a result, the timestamp values in the TCP Timestamps option on outgoing in-connection segments SHOULD be the following: for (2a), (2b), or (2c). for (2d). Interactions between the timestamp values for (2d) and mechanisms Demizu Expires April 2005 [Page 17] Internet-Draft October 2004 such as RTTM, PAWS, and Eifel are discussed in sections 5.2. If an outgoing in-connection segment is a response to an incoming in-connection segment, TS.SndMax and TS.Recent MUST be updated by the incoming segment before determining the timestamp values for the outgoing segment. If the TCP Timestamps option is not used on a given TCP connection, every outgoing in-connection segment SHOULD NOT carry the TCP Timestamps option on that connection. 4.5.4 Timestamps on Out-of-connection Segments The timestamp values in the TCP Timestamps option on an outgoing out-of-connection segment should pass both the PASA test and the PAWS test at the remote node, as discussed in 4.5.1, while the local node does not have any corresponding state. The timestamp values that would satisfy this requirement would be . Note: This form is proposed in section 4.1 and 4.2 of [Poon04]. If an incoming out-of-connection segment does not carry the TCP Timestamps option, an outgoing out-of-connection segment sent in reply SHOULD not carry the TCP Timestamps option. 4.6 Protection Levels To classify what kinds of spoofed segments can be detected on a given TCP connection, this section proposes a concept called "protection level." The protection level of a TCP connection depends on whether the TCP Timestamps option is used and whether PASA is supported by both end nodes of the connection. For example, if the TCP Timestamps option is not used on a TCP connection, PASA cannot protect the connection against any spoofed segments. Even when the TCP Timestamps option is used on a TCP connection, if a segment without the TCP Timestamps option is received, PASA cannot determine whether that segment is genuine or spoofed. For instance, [RFC1323] recommends that RST segments not carry the TCP Timestamps option. For another instance, there is a discussion to limit segments that carry the TCP Timestamps option to save TCP options space. Demizu Expires April 2005 [Page 18] Internet-Draft October 2004 4.6.1 Classification This memo classifies protection levels into three, as follows: Protection Level 0: No protection. If the TCP Timestamps option is not used on a TCP connection, or if the local node does not support PASA, the protection level of the TCP connection is 0. At this protection level, no spoofed segment can be detected. Protection Level 1: Protection against spoofed non-RST segments. If the TCP Timestamps option is used on a TCP connection, and if the local node supports PASA but the peer node does not, the protection level of the TCP connection is 1. At this protection level, all incoming spoofed non-RST segments would be detected if they carry the TCP Timestamps option. The TCP Timestamps option SHOULD be sent on all outgoing non-RST segments and SHOULD be tested for all incoming non-RST segments. The TCP Timestamps option MAY be sent on RST segments and MAY be tested for incoming RST segments. Protection Level 2: Protection against any spoofed segment. If the TCP Timestamps option is used on a TCP connection, and if both the local node and the peer node support PASA, the protection level of the TCP connection is 2. At this protection level, all incoming spoofed segments including RST segments would be detected if they carry the TCP Timestamps option. The TCP Timestamps option SHOULD be sent on all outgoing segments including RST segments and SHOULD be tested for all incoming segments including RST segments. 4.6.2 The TCP PASA-OK option An application might want to specify a required protection level for a TCP connection. To make sure that the protection level of a given TCP connection is 2, it is necessary to recognize whether the peer node supports PASA. To exchange information about whether a node supports PASA, this memo proposes a new TCP option called "PASA-OK," as described in section 6.1. The TCP PASA-OK option is carried on SYN and SYN+ACK segments to indicate that the sender node supports PASA. Demizu Expires April 2005 [Page 19] Internet-Draft October 2004 The necessity of the TCP PASA-OK option depends on whether an application needs to ensure that the protection level is 2 on a given TCP connection. If there is no such demand, the TCP PASA-OK option is unnecessary. Even if the TCP PASA-OK option was removed from the PASA specification, PASA would still work as discussed in section 4.6.3. This memo recommends supporting the TCP PASA-OK option. 4.6.3 If the TCP PASA-OK Option Was Removed Even if the TCP PASA-OK option was removed from the specification, PASA would still work. Applications, however, cannot ensure that a given TCP connection is protected against spoofed RST segments. In this case, the conditions of protection levels 1 and 2 would be replaced with the following conditions. Protection Level 1': Protection against spoofed non-RST segments. If the TCP Timestamps option is used on a TCP connection, and if the local node supports PASA and the application requires this level, the protection level of the TCP connection is 1. Protection Level 2': Protection against any spoofed segment. If the TCP Timestamps option is used on a TCP connection, and if the local node supports PASA and the application requires this level, the protection level of the TCP connection is 2. 4.7 Timestamps to Accept To detect spoofed segments precisely, it is important to properly test the timestamp values in the TCP Timestamps option on received segments. The processing rules for received segments depend on the TCP state. For example, in the CLOSED and LISTEN states, the only valid segment is a SYN segment in the LISTEN state. A RST segment received in either of these states MUST be silently discarded. If another segment is received in either of these states, a RST segment SHOULD be sent in reply. To implement these behaviors, the PASA test SHOULD NOT be performed. The SYN-SENT state is also a special state. One of its roles is to Demizu Expires April 2005 [Page 20] Internet-Draft October 2004 detect half-open TCP connections. To test all received segment according to [RFC793], the PASA test SHOULD NOT be performed. Note: This is different from section 4.1 of [Poon04]. In other states, i.e., the SYN-RECEIVED state and the states after the ESTABLISHED state has been reached, the PASA test SHOULD be performed to protect TCP connections against spoofed segments. Thus, the TCP states can be grouped into the following two categories: - The CLOSED, LISTEN, and SYN-SENT states. - All other states. The processing rules for received segments are specified for each group in section 6.4. 5. Discussion This section compares inequalities and proposals introduced in section 4.2. 5.1 Inequalities (A), (B), and (C) vs. RTTM, PAWS, and Eifel This subsection discusses whether inequalities (A), (B), and (C) would work well with mechanisms utilizing the TCP Timestamps option: RTTM, PAWS, and Eifel. At first, this subsection discusses when TS.Recent is updated. When one or more data segments have been received but an ACK segment has not been sent in reply yet, if a new data segment was received, TS.Recent would not not be updated. TS.Recent also would not be updated when a new but out-of-order segment was received. In other cases, TS.Recent would be updated as follows. If a peer node complied with (A), TS.Recent on the peer node would be updated only when a new data segment was received. On the other hand, if a peer node complied with (B) or (C), TS.Recent on the peer node would be updated when a duplicate data segment was received, as well as when a new data segment was received. In addition, if a peer node complied with (B), TS.Recent on the peer node would be updated even when a non-data segment was received. The following table summarizes the differences between these Demizu Expires April 2005 [Page 21] Internet-Draft October 2004 inequalities. +-------------------------------+-----+-----+-----+ | | (A) | (B) | (C) | +-------------------------------+-----+-----+-----+ | New in-sequence data segment | Yes | Yes | Yes | | Duplicate data segment | No | Yes | Yes | | Non-data segment | No | Yes | No | +-------------------------------+-----+-----+-----+ | New out-of-order data segment | No | No | No | | New data while ACK is delayed | No | No | No | +-------------------------------+-----+-----+-----+ Table 1: Which segments update TS.Recent? Then, this subsection discusses whether the inequalities would work well with RTTM, PAWS, Eifel, and PASA. RTTM would work with any inequality, however, (B) and (C) provide better RTT measurements for retransmitted segments than does (A), because TS.Recent on peer nodes complying (B) or (C) is updated by duplicate data segments as well as new data segments. PAWS assumes that SEG.TSval is monotonically non-decreasing. Any inequality does not break this assumption. Hence, PAWS would work with any inequality (A), (B), or (C). Eifel would work with any inequality. According to section 3.3 of [RFC3522], however, (A) has a drawback in a corner case. As described in section 4.2, PASA would work if the peer node supported (A) or (C), or if the local node supported (2d). These considerations can be summarized as follows. +-------+--------------+--------------+--------------+ | | (A) | (B) | (C) | +-------+--------------+--------------+--------------+ | RTTM | Acceptable | Preferred | Preferred | +-------+--------------+--------------+--------------+ | PAWS | Workable | Workable | Workable | +-------+--------------+--------------+--------------+ | Eifel | Workable | Preferred | Preferred | +-------+--------------+--------------+--------------+ | PASA | Workable | OK iff (2d) | Preferred | +-------+--------------+--------------+--------------+ Table 2: Inequalities vs. RTTM, PAWS, Eifel, and PASA Demizu Expires April 2005 [Page 22] Internet-Draft October 2004 5.2 Proposal (2d) vs. RTTM, PAWS, and Eifel This subsection discusses whether (2d) proposed in section 4.2 would work well with mechanisms utilizing the TCP Timestamps option: RTTM, PAWS, and Eifel. 5.2.1 Proposal (2d) vs. RTTM and Eifel If the peer node complied with (A) or (C), TS.Recent on the peer node would be updated only by data segments. Since (2d) changes only the rule for the TSval value on non-data segments, the TS.Recent value on the peer node would not be affected by whether the local node supported (2d). Hence, (2d) would not have any side effects on RTTM and Eifel in this case. If the peer node complied with (B), TS.Recent on the peer node is updated by non-data segments as well as data segments. Since (2d) does not change the rule for the TSval value on data segments, and RTTM and Eifel check the SEG.TSecr value only on segments that acknowledge data, RTTM and Eifel would work well with (2d) in this case. Consequently, RTTM and Eifel would work well with (2d) regardless of whether the peer node supported (A), (B), or (C). 5.2.2 Proposal (2d) vs. PAWS PAWS assumes that SEG.TSval is monotonically non-decreasing. Since (2d) does not break this assumption, PAWS would work with (2d) regardless of whether the peer node supported (A), (B), or (C). It would be worth to mention, however, that (2d) has a side effect on PAWS if the method proposed in section 4.4 was not implemented, as described below. Suppose the method proposed in section 4.4 is not implemented. If the local node supported (2d), the TSval value on a non-data segment being sent might not be equal to the current timestamp clock. This would cause the following side effect on PAWS. If the local node did not send any data segment for more than 2^31 units of time (i.e., if the local current timestamp clock had wrapped away), and if the local node had sent one or more non-data segments within 24 days, then the next data segments sent by the local node would be discarded by PAWS at the peer node. Demizu Expires April 2005 [Page 23] Internet-Draft October 2004 In such cases, the value of TS.Recent on the peer node would be judged valid, while it actually had been wrapped away. Hence, a TCP connection under such a situation would be blocked for a long period of time until TS.Recent on the peer node was invalidated or TS.SndMax was wrapped again. This phenomenon would happen if the age of TS.Recent was rewound whenever a valid segment was received at the peer node even if its TSval was equal to TS.Recent. According to [RFC1323], TS.Recent is invalid if "a connection is idle for more than 24 days." To cope with (2d), this condition should be interpreted as "a connection whose TS.Recent has not changed for more than 24 days." It would be impractical, however, to modify all peer nodes to follow this interpretation. Therefore, some solution to this side effect is required at the local node. The method proposed in section 4.4 would effectively eliminate this phenomenon. 5.3 Comparison of Proposed Solutions of Section 4.2 Section 4.2 describes the following proposals for the problem introduced by nodes complying with (B). (2a) Modify all peer nodes to comply with (A). (2b) Inspect the variant types of peer nodes. (2c) Introduce a new inequality (C). (2d) Change the rule generating TSval. This subsection compares these proposals. The simplest proposal is (2a), because no new mechanism needs to be invented. It would be difficult, however, to deploy (2a) in real networks, because (B) would supposedly be deployed widely, and (B) provides better RTT measurements for retransmitted segments than does (A), as discussed in section 5.1. Since it would be very complex to implement (2b), this memo does not recommend it. Although (2c) is similar to (2a), it would be deployable because (C) would provide RTT measurement accuracy similar to that of (B). In addition, the valid range of SEG.TSecr with (C) would be narrower than that for both (A) and (B), as described in section 4.2. Therefore, (2c) would be better than (2a) from the point of view of both RTTM and PASA. Demizu Expires April 2005 [Page 24] Internet-Draft October 2004 It would be practical to follow (2d), because it does not require modifying peer nodes, and it would not be complex to implement (2d). Note that protection level 1 does not require peer nodes to support PASA. Therefore, with (2d), incoming spoofed segments except for RST segments can be detected without modifying any peer nodes, as long as they support the TCP Timestamps option. Protection level 2, however, which would be the most useful, desirable protection level, requires peer nodes to support PASA. In other words, to detect spoofed RST segments at the local node, or spoofed segments at the peer nodes, all peer nodes need to be modified to support PASA. From this point of view, the advantage of (2d) might be minor, and (2c) would also be deployable. To support protection level 1 in communication with any nodes supporting the TCP Timestamps option, this memo currently recommends (2d). Nevertheless, (2c) is still a good candidate as a long-term solution. Fortunately, (2c) and (2d) could coexist. Further discussion of this issue is required. 6. Specification A TCP implementation MAY support PASA. If PASA is implemented, its implementation MUST obey the specification described in this section. The technical reasoning behind this specification is discussed in sections 3 through 5. 6.1 TCP PASA-OK option The TCP PASA-OK option indicates that the sender node supports PASA. The purpose of the TCP PASA-OK option is to exchange information about whether a node supports PASA. The TCP PASA-OK option MAY be sent on a SYN segment. It also MAY be sent on a SYN+ACK segment, but only if the TCP PASA-OK option is received in the corresponding SYN segment. The TCP PASA-OK option SHOULD not be sent on other segments. The format of the TCP PASA-OK option is as follows: +--------+--------+ |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. Demizu Expires April 2005 [Page 25] Internet-Draft October 2004 Implementation note: These two TCP options can be sent in the following format: +--------+--------+--------+--------+ |PASA-OK | Len=2 | TSopt | Len=10 | +--------+--------+--------+--------+ | TSval | +--------+--------+--------+--------+ | TSecr | +--------+--------+--------+--------+ 6.2 Timestamps to Send To discuss the timestamp values on segments being sent, this memo introduces two terms: "in-connection segments" and "out-of-connection segments." All incoming and outgoing segments are grouped into one of these categories. o In-connection segments In-connection segments are those that could be exchanged on a normal TCP connection. If the TCP Timestamps option is used on a TCP connection, the timestamp values in the TCP Timestamps option on the outgoing segment SHOULD be . Otherwise, the segment SHOULD NOT carry the TCP Timestamps option. o Out-of-connection segments Out-of-connection segments are those incoming segments that are apparently not intended for a given TCP connection, and those outgoing segments sent in reply to such incoming segments. If a corresponding incoming segment carries the TCP Timestamps option, the timestamp values in the TCP Timestamps option on the outgoing segment SHOULD be . Otherwise, the segment sent in reply SHOULD not carry the TCP Timestamps option. 6.3 Protection Levels The protection level of a TCP connection is defined as follows: Demizu Expires April 2005 [Page 26] Internet-Draft October 2004 Protection Level 0: No protection. If the TCP Timestamps option is not exchanged on SYN and SYN+ACK segments, or if the local node does not support PASA, the protection level of the TCP connection is 0. Protection Level 1: Protection against spoofed non-RST segments. If the TCP Timestamps option is exchanged on SYN and SYN+ACK segments, but the TCP PASA-OK option is not exchanged on SYN and SYN+ACK segments and the local node supports PASA, the protection level of the TCP connection is 1. Protection Level 2: Protection against any spoofed segment. If both the TCP Timestamps option and the TCP PASA-OK option are exchanged on SYN and SYN+ACK segments, the protection level of the TCP connection is 2. Implementations SHOULD allow applications to specify the required protection level for each TCP connection in the CLOSED or LISTEN states. If the negotiated protection level does not satisfy the required protection level, the TCP connection SHOULD be aborted and a RST segment with the timestamp values for in-connection segments SHOULD be sent in reply. Note: This is suggested in section 4 of [Poon04]. 6.4 Timestamps to Accept The processing rule for received segments depends on the TCP states. 6.4.1 In the CLOSED, LISTEN, and SYN-SENT States In these states, the PASA test SHOULD NOT be performed for received segments, regardless of whether a received segment carries the TCP Timestamps option. When a SYN segment is received in the LISTEN state, or when a SYN or SYN+ACK segment is received in the SYN-SENT state, after the segment is accepted by rules other than PASA, it SHOULD be tested for whether it satisfies the protection level required by an application, as follows: If the required protection level is 1, the received segment MUST carry the TCP Timestamps option. If the required protection level Demizu Expires April 2005 [Page 27] Internet-Draft October 2004 is 2, the received segment MUST carry both the TCP Timestamps option and the TCP PASA-OK option. If the received segment does not satisfy these requirements, the unestablished TCP connection SHOULD be aborted, and a RST segment with the timestamp values for in-connection segments SHOULD be sent in reply. When a segment other than the above is received, and a RST segment SHOULD be sent in reply, the received segment and the RST segment are out-of-connection segments. If the received segment carries the TCP Timestamps option, the RST segment sent in reply SHOULD carry the TCP Timestamps option with the timestamp values for out-of-connection segments. 6.4.2 In the Other States In the other states (i.e., the SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT states), if a segment with the TCP Timestamps option is received, the PASA test SHOULD be performed. Or, if a segment without the TCP Timestamps option is received, it SHOULD be tested for whether it satisfies the required protection level, as follows: - If the required protection level is 2, the segment SHOULD be treated as if it failed the PASA test. - If the required protection level is 1, and - if the segment is not a RST segment, it SHOULD be treated as if it failed the PASA test; or - if the segment is a RST segment, it SHOULD be treated as if it passed the PASA test. - If the required protection level is 0, the segment SHOULD be treated as if it passed the PASA test. If a received segment fails the PASA test, and if the segment is not a RST segment, an ACK segment SHOULD be sent in reply as specified on page 69 of [RFC793], and the received segment MUST be dropped. Note that this rule is the same as that of PAWS [RFC1323]. An ACK throttling mechanism SHOULD be implemented. Demizu Expires April 2005 [Page 28] Internet-Draft October 2004 6.5 The Processing Rule of PASA The TCP per-connection state SHOULD be augmented by four timestamps: TS.SndMax, TS.SndMin, TS.SndOff, and TS.MaxAdv. Initially: /* See section 4.3 */ TS.SndOff = random number TS.SndMin = my.TSclock + TS.SndOff TS.SndMax = my.TSclock + TS.SndOff /* See section 4.4 */ TS.MaxAdv = the upper limit to the advancement of TS.SndMax On sending a segment: /* Only when TS.SndMax will be updated */ if (SEG.LEN > 0 || SYN || FIN) then /* See section 4.4 */ if (my.TSclock - TS.SndMax > TS.MaxAdv) then TS.SndOff = TS.MaxAdv - ( my.TSclock - TS.SndMax ) /* See section 4.2.2.4 (See also section 4.1) */ if (SEG.LEN > 0 || SYN || FIN) then TS.SndMax = my.TSclock + TS.SndOff /* See section 6.2 */ Send the segment according to section 6.2. On receiving a segment: /* See section 6.4 */ Perform the PASA test for the segment according to section 6.4 /* After this segment passes all TCP tests */ /* See section 4.1 */ if (TS.SndMin < SEG.TSecr) then TS.SndMin = SEG.TSecr Demizu Expires April 2005 [Page 29] Internet-Draft October 2004 7. Examples The following are examples of how PASA would work. 7.1 Half-open Connections A TCP connection is said to be "half-open" if one of the two nodes has aborted the TCP connection or has rebooted itself while the other does not know of this. 7.1.1 Half-open Connection: CLOSED vs. ESTABLISHED In this example, suppose a TCP connection has been established between TCP A and TCP B. Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B. Step 1: TCP A aborts the TCP connection and sends a RST segment as an in-connection segment. But it is lost. Step 2: TCP A moves to the CLOSED state. Step 3: TCP B sends a data segment as an in-connection segment. TCP A does not execute the PASA test, because TCP A is in the CLOSED state. TCP A considers the data segment as an out-of-connection segment. Step 4: A RST segment is sent in reply as an out-of-connection segment. It passes the PASA test at TCP B. It makes TCP B discard the TCP connection. Step 5: TCP B moves to the CLOSED state. As seen above, TCP B succeeds to detect that TCP A has closed the TCP connection. The following diagram illustrates this scenario. TCP A TCP B (SND.NXT=100, RCV.NXT=200) 1. (Abort) ---> .... (lost) ESTABLISHED 2. CLOSED ESTABLISHED Demizu Expires April 2005 [Page 30] Internet-Draft October 2004 3. CLOSED <--- <--- ESTABLISHED (with data) 4. CLOSED ---> ---> (Abort) 5. CLOSED CLOSED 7.1.2 Half-open Connection: SYN-SENT vs. ESTABLISHED In this example, suppose a TCP connection has been established between TCP A and TCP B. Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B. Step 1: TCP A crashes, but TCP B does not detect it. Step 2: TCP A moves to the CLOSED state after a reboot. Step 3: TCP A sends a SYN segment as an in-connection segment to establish a new TCP connection. Suppose the SYN segment fails the PASA test at TCP B. TCP B considers it as an in-connection segment. Step 4: TCP B sends an ACK segment in reply as an in-connection segment. TCP A does not execute the PASA test, because TCP A is in the SYN-SENT state. TCP A considers the ACK segment as an out-of-connection segment. Step 5: A RST segment is sent in reply as an out-of-connection segment. It passes the PASA test at TCP B. It makes TCP B discard the TCP connection. Step 6: TCP B moves to the CLOSED state. Step 7-9: A new TCP connection is established between TCP A and TCP B. This scenario is similar to Figure 10 of RFC793 (page 34). But the SYN segment sent at step 3 above is supposed to be rejected by PASA instead of a rule in [RFC793]. If the SYN segment accidentally passed the PASA test at step 3 above, the SYN segment would be processed according to [RFC793]. In such cases, if the sequence number of the SYN segment was out-of-window, the scenario would be the same as above. If it was in-window, a RST segment would be sent by TCP B to TCP A, and TCP Demizu Expires April 2005 [Page 31] Internet-Draft October 2004 B would discard the TCP connection. As seen above, TCP B succeeds to detect that TCP A has closed the TCP connection. The following diagram illustrates this scenario. TCP A TCP B (SND.NXT=100, RCV.NXT=200) 1. (crashed) ESTABLISHED 2. CLOSED ESTABLISHED 3. SYN-SENT ---> ---> ESTABLISHED 4. SYN-SENT <--- <--- ESTABLISHED 5. SYN-SENT ---> ---> (Abort) 6. SYN-SENT CLOSED 7. SYN-SENT ---> ---> CLOSED 8. SYN-SENT <--- SYN-RECEIVED 9. ESTABLISHED ---> ESTABLISHED 7.1.3 Half-open Connection: SYN-SENT vs. ESTABLISHED In this example, suppose a TCP connection has been established between TCP A and TCP B. Suppose SND.NXT = 100 and RCV.NXT = 200 at TCP B. Step 1: TCP A crashes, but TCP B does not detect it. Step 2: TCP A moves to the CLOSED state after a reboot. Step 3: TCP A sends a SYN segment as an in-connection segment to establish a new TCP connection. But it is lost. Demizu Expires April 2005 [Page 32] Internet-Draft October 2004 Step 4: TCP B sends a data segment as an in-connection segment. TCP A does not execute the PASA test, because TCP A is in the SYN-SENT state. TCP A considers the data segment as an out-of-connection segment. Step 5: A RST segment is sent in reply as an out-of-connection segment. It passes the PASA test at TCP B. It makes TCP B discard the TCP connection. Step 6: TCP B moves to the CLOSED state. Step 7-9: A new TCP connection is established between TCP A and TCP B. As seen above, TCP B succeeds to detect that TCP A has closed the TCP connection. The following diagram illustrates this scenario. TCP A TCP B (SND.NXT=100, RCV.NXT=200) 1. (crashed) ESTABLISHED 2. CLOSED ESTABLISHED 3. SYN-SENT ---> ---> (lost) 4. SYN-SENT <--- <--- ESTABLISHED (with data) 5. SYN-SENT ---> ---> (Abort) 6. SYN-SENT CLOSED 7. SYN-SENT ---> ---> CLOSED 8. SYN-SENT <--- SYN-RECEIVED 9. ESTABLISHED ---> ESTABLISHED Demizu Expires April 2005 [Page 33] Internet-Draft October 2004 8. Security Considerations This memo proposes a method of protecting TCP connections against off-path, third party spoofing attacks, by making use of the TCP Timestamps option. The proposal provides an obfuscation mechanism, but it is not strong as cryptographic approaches. 9. IANA Considerations One new TCP option value will need to be assigned for the TCP PASA-OK option described in section 6.1 Acknowledgments The original idea for the method described in this memo was proposed by Kacheong Poon [Poon04]. He also provided many valuable comments including a hint for the idea proposed as (2d) in section 4.2.2.4. Normative References [RFC793] J. Postel, "Transmission Control Protocol", RFC793, September 1981 [RFC1323] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", RFC1323, May 1992 [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC2119, BCP14, March 1997 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF Technology", RFC3668, BCP79, February 2004 [Poon04] K. Poon, "Use of TCP timestamp option to defend against blind spoofing attack", (work in progress), Internet-Draft , June 2004 Informative References [RFC2988] V. Paxson, M. Allman, "Computing TCP's Retransmission Timer", RFC2988, November 2000 [RFC3522] R. Ludwig, M. Meyer, "The Eifel Detection Algorithm for TCP", RFC3522, April 2003 Demizu Expires April 2005 [Page 34] Internet-Draft October 2004 [JBB97] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", (work in progress), Internet-Draft , February 1997 [JBB03] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", (work in progress), Internet-Draft , August 2003 Author's Address Noritoshi Demizu National Institute of Information and Communications Technology(NICT) 4-2-1 Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Phone: +81-42-327-7432 (Ex. 5813) E-mail: demizu@nict.go.jp 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. 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. Intellectual Property 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 Demizu Expires April 2005 [Page 35] Internet-Draft October 2004 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Demizu Expires April 2005 [Page 36]