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