idnits 2.17.1 draft-gont-tcpm-tcp-timestamps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.2b on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 319. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) Consultant 4 Internet-Draft October 28, 2008 5 Intended status: BCP 6 Expires: May 1, 2009 8 On the generation of TCP timestamps 9 draft-gont-tcpm-tcp-timestamps-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 1, 2009. 38 Abstract 40 This document describes an algorithm for selecting the timestamps (TS 41 value) used for TCP connections that use the TCP timestamp option, 42 such that the resulting timestamps are monotonically-increasing 43 across connections that involve the same four-tuple {local IP 44 address, local TCP port, remote IP address, remote TCP port}. The 45 properties of the algorithm are such the possibility of an attacker 46 guessing the exact value is reduced. Additionally, it describes an 47 algorithm for processing incoming SYN segments to allow a higher 48 connection establishment rates to any TCP end-point. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Improved processing of incoming connection requests . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 60 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Introduction 66 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 67 to include a timestamp value in its segments, that can be used used 68 to perform two functions: Round-Trip Time Measurement (RTTM), and 69 Protect Against Wrapped Sequences (PAWS). 71 For the purpose of PAWS, the timestamps sent on a connection are 72 required to be monotonically increasing. While there is no 73 requirement that timestamps are monotonically increasing across TCP 74 connections, the generation of timestamps such that they are 75 monotonically increasing across connections between the same two 76 endpoints allows the use of timestamps for improving the handling of 77 SYN segments that are received while the corresponding four-tuple is 78 in the TIME-WAIT state. That is, the timestamp option could be used 79 to perform heuristics to determine whether to allow the creation of a 80 new incarnation of a connection that is in the TIME-WAIT state. 82 This use of TCP timestamps is simply an extrapolation of the use of 83 ISNs for the same purpose, as allowed by RFC 1122 [RFC0793] itself, 84 and has been incorporated in a number of TCP implementations, such as 85 that included in the Linux kernel. [Linux] 87 In order to avoid the security implications of predictable 88 timestamps, the proposed algorithm generates timestamps such such 89 that the possibility of an attacker guessing the exact value is 90 reduced. 92 Section 2 proposes the aforementioned algorithm for generating TCP 93 timestamps. Section 3 describes an improved processing of incomming 94 connection requests, that may allow higher connection-establishment 95 rates to any TCP end-point. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Proposed algorithm 103 It is RECOMMENDED that timestamps are generated with a similar 104 algorithm to that introduced by RFC 1948 [RFC1948] for the generation 105 of Initial Sequence Numbers (ISNs). That is, 107 timestamp = T() + F(localhost, localport, remotehost, remoteport, 108 secret_key) 110 where the result of T() is a global system clock that complies with 111 the requirements of Section 4.2.2 of RFC 1323 [RFC1323], and F() is a 112 function that should not be computable from the outside. Therefore, 113 we suggest F() to be a cryptographic hash function of the 114 connection-id and some secret data. 116 F() provides an offset that will be the same for all incarnations of 117 a connection between the same two endpoints, while T() provides the 118 monotonically increasing values that are needed for PAWS. 120 3. Improved processing of incoming connection requests 122 In a number of scenarios a socket pair may need to be reused while 123 the corresponding four-tuple is still in the TIME-WAIT state in a 124 remote TCP peer. For example, a client accessing some service on a 125 host may try to create a new incarnation of a previous connection, 126 while the corresponding four-tuple is still in the TIME-WAIT state at 127 the remote TCP peer (the server). This may happen if the ephemeral 128 port numbers are being reused too quickly, either because of a bad 129 policy of selection of ephemeral ports, or simply because of a high 130 connection rate to the corresponding service. In such scenarios, the 131 establishment of new connections that reuse a four-tuple that is in 132 the TIME-WAIT state would fail. In order to avoid this problem, RFC 133 1122 [RFC1122] (in Section 4.2.2.13) states that when a connection 134 request is received with a four-tuple that is in the TIME-WAIT state, 135 the connection request could be accepted if the sequence number of 136 the incoming SYN segment is greater than the last sequence number 137 seen on the previous incarnation of the connection (for that 138 direction of the data transfer). 140 This requirement aims at avoiding the sequence number space of the 141 new and old incarnations of the connection to overlap, thus avoiding 142 old segments from the previous incarnation of the connection to be 143 accepted as valid by the new connection. 145 The following paragraphs summarize the processing of SYN segments 146 received for connections in the TIME-WAIT state. Both the ISN 147 (Initial Sequence Number) and the timestamp option (if present) of 148 the incoming SYN segment are included in the heuristics performed for 149 allowing a high connection-establishment rate. 151 Processing of SYN segments received for connections in the TIME-WAIT 152 state should occur as follows: 154 o If the previous incarnation of the connection used timestamps, 155 then, 156 * If the incoming SYN segment contains a timestamp option, and 157 the timestamp is greater than the last timestamp seen on the 158 previous incarnation of the connection, honor the connection 159 request (creating a connection in the SYN-RECEIVED state). 161 * If the incoming SYN segment contains a timestamp option, and 162 the timestamp is equal to the last timestamp seen on the 163 previous incarnation of the connection (for that direction of 164 the data transfer), and the sequence number of the incoming SYN 165 segment is larger than the last sequence number seen on the 166 previous incarnation of the connection (for that direction of 167 the data transfer), then honor the connection request. 169 * If the incoming SYN segment does not contain a timestamp 170 option, but the Sequence Number of the incoming SYN segment is 171 larger than the last sequence number seen on the previous 172 incarnation of the connection (for the same direction of the 173 data transfer), honor the connection request. 175 * Otherwise, silently drop the incoming SYN segment, thus leaving 176 the previous connection in the TIME-WAIT state. 178 o If the previous incarnation of the connection did not use 179 timestamps, then, 181 * If the incoming connection request contains a timestamp option, 182 and timestamps will be enabled for the new incarnation of the 183 connection (i.e., the SYN/ACK segment will contain a timestamp 184 option), honor the incoming connection request. 186 * If the incoming connection request does not contain a timestamp 187 option, but the Sequence Number of the incoming SYN segment is 188 larger than the last sequence number seen on the previous 189 incarnation of the connection for the same direction of the 190 data transfer, then honor the incoming connection request (even 191 if the sequence number of the incoming SYN segment falls within 192 the receive window of the previous incarnation of the 193 connection). 195 Many implementations do not include the TCP timestamp option when 196 performing the above heuristics, thus imposing stricter constraints 197 on the generation of Initial Sequence Numbers, the average data 198 transfer rate of the connections, and the amount of data transferred 199 with them. RFC 793 [RFC0793] states that the ISN generator should be 200 incremented roughly once every four microseconds (i.e., roughly 201 250000 times per second). As a result, any connection that transfers 202 more than 250000 bytes of data at more than 250 KB/s could lead to 203 scenarios in which the last sequence number seen on a connection that 204 moves into the TIME-WAIT state is still greater than the sequence 205 number of an incoming SYN segment that aims at creating a new 206 incarnation of the same connection. In those scenarios, the 4.4BSD 207 heuristics would fail, and therefore the connection request would 208 usually time out. By including the TCP timestamp option in the 209 heuristics described above, all these constraints are greatly 210 relaxed. 212 It is clear that the use of TCP timestamps for the heuristics 213 described above depends on the timestamps to be monotonically 214 increasing across connections between the same two TCP endpoints. 215 Therefore, we strongly advice to generate timestamps as described in 216 Section 2. 218 4. Security Considerations 220 This document describes an algorithm that can be used to obfuscate 221 the timestamp value used for new connections, such that the 222 possibility of an attacker guessing the exact value is reduced. 224 Some implementations are known to maintain a global timestamp clock, 225 which is used for all connections. This is undesirable, as an 226 attacker that can establish a connection with a host would learn the 227 timestamp used for all the other connections maintained by that host, 228 which could be useful for performing any attacks that require the 229 attacker to forge TCP segments. Some implementations are known to 230 initialize their global timestamp clock to zero when the system is 231 bootstrapped. This is undesirable, as the timestamp clock would 232 disclose the system uptime. 234 The algorithm discussed in this document for generating the TCP 235 timestamps avoids these problems by generating timestamps as 236 monotonically-increasing function with a per-connection-id random 237 offset. [CPNI-TCP] 239 5. IANA Considerations 241 This document has no actions for IANA. 243 6. Acknowledgements 245 Yet to be added 247 7. References 248 7.1. Normative References 250 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 251 RFC 793, September 1981. 253 [RFC1122] Braden, R., "Requirements for Internet Hosts - 254 Communication Layers", STD 3, RFC 1122, October 1989. 256 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 257 for High Performance", RFC 1323, May 1992. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 7.2. Informative References 264 [CPNI-TCP] 265 CPNI, "Security Assessment of the Transmission Control 266 Protocol (TCP)", (to be published) . 268 [Linux] The Linux Project, "http://www.kernel.org". 270 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 271 RFC 1948, May 1996. 273 Author's Address 275 Fernando Gont 276 Consultant 278 Email: fernando@gont.com.ar 279 URI: http://www.gont.com.ar 281 Full Copyright Statement 283 Copyright (C) The IETF Trust (2008). 285 This document is subject to the rights, licenses and restrictions 286 contained in BCP 78, and except as set forth therein, the authors 287 retain all their rights. 289 This document and the information contained herein are provided on an 290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 291 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 292 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 293 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 294 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 297 Intellectual Property 299 The IETF takes no position regarding the validity or scope of any 300 Intellectual Property Rights or other rights that might be claimed to 301 pertain to the implementation or use of the technology described in 302 this document or the extent to which any license under such rights 303 might or might not be available; nor does it represent that it has 304 made any independent effort to identify any such rights. Information 305 on the procedures with respect to rights in RFC documents can be 306 found in BCP 78 and BCP 79. 308 Copies of IPR disclosures made to the IETF Secretariat and any 309 assurances of licenses to be made available, or the result of an 310 attempt made to obtain a general license or permission for the use of 311 such proprietary rights by implementers or users of this 312 specification can be obtained from the IETF on-line IPR repository at 313 http://www.ietf.org/ipr. 315 The IETF invites any interested party to bring to its attention any 316 copyrights, patents or patent applications, or other proprietary 317 rights that may cover technology that may be required to implement 318 this standard. Please address the information to the IETF at 319 ietf-ipr@ietf.org.