idnits 2.17.1 draft-gont-tcpm-tcp-timestamps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication 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 and authors 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 (February 2, 2009) is 5554 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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) UK CPNI 4 Internet-Draft February 2, 2009 5 Intended status: BCP 6 Expires: August 6, 2009 8 On the generation of TCP timestamps 9 draft-gont-tcpm-tcp-timestamps-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may not be modified, 15 and derivative works of it may not be created, and it may not be 16 published except as an Internet-Draft. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 6, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document describes an algorithm for selecting the timestamps (TS 51 value) used for TCP connections that use the TCP timestamp option, 52 such that the resulting timestamps are monotonically-increasing 53 across connections that involve the same four-tuple {local IP 54 address, local TCP port, remote IP address, remote TCP port}. The 55 properties of the algorithm are such that it reduces the possibility 56 of an attacker of guessing the exact value. Additionally, it 57 describes an algorithm for processing incoming SYN segments that 58 allows higher connection-establishment rates between any two TCP 59 endpoints when a TCP timestamps option is present in the incoming SYN 60 segment. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Improved processing of incoming connection requests . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Appendix A. Changes from previous versions of the draft (to 74 be removed by the RFC Editor before publishing 75 this document as an RFC) . . . . . . . . . . . . . . . 8 76 A.1. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 8 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 82 to include a timestamp value in its segments, that can be used used 83 to perform two functions: Round-Trip Time Measurement (RTTM), and 84 Protection Against Wrapped Sequences (PAWS). 86 For the purpose of PAWS, the timestamps sent on a connection are 87 required to be monotonically increasing. While there is no 88 requirement that timestamps are monotonically increasing across TCP 89 connections, the generation of timestamps such that they are 90 monotonically increasing across connections between the same two 91 endpoints allows the use of timestamps for improving the handling of 92 SYN segments that are received while the corresponding four-tuple is 93 in the TIME-WAIT state. That is, the timestamp option could be used 94 to perform heuristics to determine whether to allow the creation of a 95 new incarnation of a connection that is in the TIME-WAIT state. 97 This use of TCP timestamps is simply an extrapolation of the use of 98 Initial Sequence Numbers (ISNs) for the same purpose, as allowed by 99 RFC 1122 [RFC1122], and it has been incorporated in a number of TCP 100 implementations, such as that included in the Linux kernel [Linux]. 102 In order to avoid the security implications of predictable 103 timestamps, the proposed algorithm generates timestamps such that the 104 possibility of an attacker guessing the exact value is reduced. 106 Section 2 proposes the aforementioned algorithm for generating TCP 107 timestamps. Section 3 describes an improved processing of incoming 108 connection requests, that may allow higher connection-establishment 109 rates to any TCP end-point. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Proposed algorithm 117 It is RECOMMENDED that timestamps are generated with a similar 118 algorithm to that introduced by RFC 1948 [RFC1948] for the generation 119 of Initial Sequence Numbers (ISNs). That is, 121 timestamp = T() + F(localhost, localport, remotehost, remoteport, 122 secret_key) 124 where the result of T() is a global system clock that complies with 125 the requirements of Section 4.2.2 of RFC 1323 [RFC1323], and F() is a 126 function that should not be computable from the outside without 127 knowledge of the secret key (secret_key). Therefore, we suggest F() 128 to be a cryptographic hash function of the connection-id and some 129 secret data (which could be chosen randomly). 131 F() provides an offset that will be the same for all incarnations of 132 a connection between the same two endpoints, while T() provides the 133 monotonically increasing values that are needed for PAWS. 135 3. Improved processing of incoming connection requests 137 In a number of scenarios a socket pair may need to be reused while 138 the corresponding four-tuple is still in the TIME-WAIT state in a 139 remote TCP peer. For example, a client accessing some service on a 140 host may try to create a new incarnation of a previous connection, 141 while the corresponding four-tuple is still in the TIME-WAIT state at 142 the remote TCP peer (the server). This may happen if the ephemeral 143 port numbers are being reused too quickly, either because of a bad 144 policy of selection of ephemeral ports, or simply because of a high 145 connection rate to the corresponding service. In such scenarios, the 146 establishment of new connections that reuse a four-tuple that is in 147 the TIME-WAIT state would fail. In order to avoid this problem, RFC 148 1122 [RFC1122] (in Section 4.2.2.13) states that when a connection 149 request is received with a four-tuple that is in the TIME-WAIT state, 150 the connection request could be accepted if the sequence number of 151 the incoming SYN segment is greater than the last sequence number 152 seen on the previous incarnation of the connection (for that 153 direction of the data transfer). 155 This requirement aims at avoiding the sequence number space of the 156 new and old incarnations of the connection to overlap, thus avoiding 157 old segments from the previous incarnation of the connection to be 158 accepted as valid by the new connection. 160 The following paragraphs summarize the processing of SYN segments 161 received for connections in the TIME-WAIT state. Both the ISN 162 (Initial Sequence Number) and the timestamp option (if present) of 163 the incoming SYN segment are included in the heuristics performed for 164 allowing a high connection-establishment rate. 166 Processing of SYN segments received for connections in the 167 synchronized states should occur as follows: 169 o If a SYN segment is received for a connection in any synchronized 170 state other than TIME-WAIT, respond with an ACK, applying rate- 171 throttling. 173 o If the corresponding connection is in the TIME-WAIT state, then, 175 * If the previous incarnation of the connection used timestamps, 176 then, 178 + If TCP timestamps would be enabled for the new incarnation 179 of the connection, and the timestamp contained in the 180 incoming SYN segment is greater than the last timestamp seen 181 on the previous incarnation of the connection (for that 182 direction of the data transfer), honour the connection 183 request (creating a connection in the SYN-RECEIVED state). 185 + If TCP timestamps would be enabled for the new incarnation 186 of the connection, the timestamp contained in the incoming 187 SYN segment is equal to the last timestamp seen on the 188 previous incarnation of the connection (for that direction 189 of the data transfer), and the Sequence Number of the 190 incoming SYN segment is larger than the last sequence number 191 seen on the previous incarnation of the connection (for that 192 direction of the data transfer), then honour the connection 193 request (creating a connection in the SYN-RECEIVED state). 195 + If TCP timestamps would not be enabled for the new 196 incarnation of the connection, but the Sequence Number of 197 the incoming SYN segment is larger than the last sequence 198 number seen on the previous incarnation of the connection 199 (for the same direction of the data transfer), honour the 200 connection request (creating a connection in the SYN- 201 RECEIVED state). 203 + Otherwise, silently drop the incoming SYN segment, thus 204 leaving the previous incarnation of the connection in the 205 TIME-WAIT state. 207 * If the previous incarnation of the connection did not use 208 timestamps, then, 210 + If TCP timestamps would be enabled for the new incarnation 211 of the connection, honour the incoming connection request. 213 + If TCP timestamps would not be enabled for the new 214 incarnation of the connection, but the Sequence Number of 215 the incoming SYN segment is larger than the last sequence 216 number seen on the previous incarnation of the connection 217 (for the same direction of the data transfer), then honour 218 the incoming connection request (even if the sequence number 219 of the incoming SYN segment falls within the receive window 220 of the previous incarnation of the connection). 222 + Otherwise, silently drop the incoming SYN segment, thus 223 leaving the previous incarnation of the connection in the 224 TIME-WAIT state. 226 Note: 228 In the above explanation, the phrase "TCP timestamps would be 229 enabled for the new incarnation for the connection" means that the 230 incoming SYN segment contains a TCP Timestamps option (i.e., the 231 client has enabled TCP timestamps), and that the SYN/ACK segment 232 that would be sent in response to it would also contain a 233 Timestamps option (i.e., the server has enabled TCP timestamps). 234 In such a scenario, TCP timestamps would be enabled for the new 235 incarnation of the connection. 237 The "last sequence number seen on the previous incarnation of the 238 connection (for the same direction of the data transfer)" refers 239 to the last sequence number used by the previous incarnation of 240 the connection (for the same direction of the data transfer), and 241 not to the last value seen in the Sequence Number field of the 242 corresponding segments. That is, it refers to the sequence number 243 corresponding to the FIN flag of the previous incarnation of the 244 connection, for that direction of the data transfer. 246 Many implementations do not include the TCP timestamp option when 247 performing the above heuristics, thus imposing stricter constraints 248 on the generation of Initial Sequence Numbers, the average data 249 transfer rate of the connections, and the amount of data transferred 250 with them. RFC 793 [RFC0793] states that the ISN generator should be 251 incremented roughly once every four microseconds (i.e., roughly 252 250000 times per second). As a result, any connection that transfers 253 more than 250000 bytes of data at more than 250 KB/s could lead to 254 scenarios in which the last sequence number seen on a connection that 255 moves into the TIME-WAIT state is still greater than the sequence 256 number of an incoming SYN segment that aims at creating a new 257 incarnation of the same connection. In those scenarios, the 4.4BSD 258 heuristics would fail, and therefore the connection request would 259 usually time out. By including the TCP timestamp option in the 260 heuristics described above, all these constraints are greatly 261 relaxed. 263 It is clear that the use of TCP timestamps for the heuristics 264 described above depends on the timestamps to be monotonically 265 increasing across connections between the same two TCP endpoints. 266 Therefore, we strongly advice to generate timestamps as described in 267 Section 2. 269 4. Security Considerations 271 This document describes an algorithm that can be used to obfuscate 272 the timestamp value used for new connections, such that the 273 possibility of an attacker guessing the exact value is reduced. 275 Some implementations are known to maintain a global timestamp clock, 276 which is used for all connections. This is undesirable, as an 277 attacker that can establish a connection with a host would learn the 278 timestamp used for all the other connections maintained by that host, 279 which could be useful for performing any attacks that require the 280 attacker to forge TCP segments. Some implementations are known to 281 initialize their global timestamp clock to zero when the system is 282 bootstrapped. This is undesirable, as the timestamp clock would 283 disclose the system uptime. 285 The algorithm discussed in this document for generating the TCP 286 timestamps avoids these problems by generating timestamps as 287 monotonically-increasing function with a per-connection-id random 288 offset. [CPNI-TCP] 290 5. IANA Considerations 292 This document has no actions for IANA. 294 6. Acknowledgements 296 The author of this document would like to thank (in alphabetical 297 order) Alfred Hoenes and Eric Rescorla providing valuable feedback on 298 an earlier version of this document. 300 Additionally, the author would like to thank David Borman for a 301 fruitful discussion on TCP timestamps at IETF 73. 303 Finally, the author would like to thank the United Kingdom's Centre 304 for the Protection of National Infrastructure (UK CPNI) for their 305 continued support. 307 7. References 309 7.1. Normative References 311 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 312 RFC 793, September 1981. 314 [RFC1122] Braden, R., "Requirements for Internet Hosts - 315 Communication Layers", STD 3, RFC 1122, October 1989. 317 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 318 for High Performance", RFC 1323, May 1992. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 7.2. Informative References 325 [CPNI-TCP] 326 CPNI, "Security Assessment of the Transmission Control 327 Protocol (TCP)", (to be published) . 329 [Linux] The Linux Project, "http://www.kernel.org". 331 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 332 RFC 1948, May 1996. 334 Appendix A. Changes from previous versions of the draft (to be removed 335 by the RFC Editor before publishing this document as an 336 RFC) 338 A.1. Changes from draft-gont-tcpm-tcp-timestamps-00 340 o Fixed author's affiliation. 342 o Addressed feedback submitted by Alfred Hoenes (see: 343 http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), 344 plus nits sent by Alfred off-list. 346 Author's Address 348 Fernando Gont 349 UK Centre for the Protection of National Infrastructure 351 Email: fernando@gont.com.ar 352 URI: http://www.cpni.gov.uk