idnits 2.17.1 draft-ietf-tcpm-tcp-timestamps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2011) is 4822 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) == Outdated reference: A later version (-21) exists of draft-ietf-tcpm-1323bis-01 == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-security-02 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 4, 2011 5 Intended status: BCP 6 Expires: August 8, 2011 8 Reducing the TIME-WAIT state using TCP timestamps 9 draft-ietf-tcpm-tcp-timestamps-04.txt 11 Abstract 13 This document describes an algorithm for processing incoming SYN 14 segments that allows higher connection-establishment rates between 15 any two TCP endpoints when a TCP timestamps option is present in the 16 incoming SYN segment. This document only modifies processing of SYN 17 segments received for connections in the TIME-WAIT state; processing 18 in all other states is unchanged. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Improved processing of incoming connection requests . . . . . 3 68 3. Interaction with various timestamps generation algorithms . . 6 69 4. Interaction with various ISN generation algorithms . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Appendix A. Behavior of the proposed mechanism in specific 77 scenarios . . . . . . . . . . . . . . . . . . . . . . 10 78 A.1. Connection request after system reboot . . . . . . . . . . 10 79 Appendix B. Changes from previous versions of the draft (to 80 be removed by the RFC Editor before publishing 81 this document as an RFC) . . . . . . . . . . . . . . 10 82 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-03 . . . . . . 10 83 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-02 . . . . . . 10 84 B.3. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10 85 B.4. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 11 86 B.5. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 11 87 B.6. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11 88 B.7. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 89 B.8. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 90 B.9. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 96 to include a timestamp value in its segments, that can be used to 97 perform two functions: Round-Trip Time Measurement (RTTM), and 98 Protection Against Wrapped Sequences (PAWS). 100 For the purpose of PAWS, the timestamps sent on a connection are 101 required to be monotonically increasing. While there is no 102 requirement that timestamps are monotonically increasing across TCP 103 connections, the generation of timestamps such that they are 104 monotonically increasing across connections between the same two 105 endpoints allows the use of timestamps for improving the handling of 106 SYN segments that are received while the corresponding four-tuple is 107 in the TIME-WAIT state. That is, the timestamp option could be used 108 to perform heuristics to determine whether to allow the creation of a 109 new incarnation of a connection that is in the TIME-WAIT state. 111 This use of TCP timestamps is simply an extrapolation of the use of 112 Initial Sequence Numbers (ISNs) for the same purpose, as allowed by 113 RFC 1122 [RFC1122], and it has been incorporated in a number of TCP 114 implementations, such as that included in the Linux kernel [Linux]. 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. 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. This problem is discussed in detail 133 in [INFOCOM-99]. 135 In order to avoid this problem, RFC 1122 [RFC1122] (in Section 136 4.2.2.13) states that when a connection request is received with a 137 four-tuple that is in the TIME-WAIT state, the connection request 138 could be accepted if the sequence number of the incoming SYN segment 139 is greater than the last sequence number seen on the previous 140 incarnation of the connection (for that direction of the data 141 transfer). This requirement aims at avoiding the sequence number 142 space of the new and old incarnations of the connection to overlap, 143 thus avoiding old segments from the previous incarnation of the 144 connection to be accepted as valid by the new connection. 146 The same policy may be extrapolated to TCP timestamps. That is, when 147 a connection request is received with a four-tuple that is in the 148 TIME-WAIT state, the connection request could be accepted if the 149 timestamp of the incoming SYN segment is greater than the last 150 timestamp seen on the previous incarnation of the connection (for 151 that direction of the data transfer). 153 The following paragraphs summarize the processing of SYN segments 154 received for connections in the TIME-WAIT state. The processing of 155 SYN segments received for connections in all other states is 156 unchanged. Both the ISN (Initial Sequence Number) and the timestamps 157 option (if present) of the incoming SYN segment are included in the 158 heuristics performed for allowing a high connection-establishment 159 rate. 161 Processing of SYN segments received for connections in the TIME-WAIT 162 state SHOULD occur as follows: 164 o If the previous incarnation of the connection used timestamps, 165 then, 167 * If TCP timestamps would be enabled for the new incarnation of 168 the connection, and the timestamp contained in the incoming SYN 169 segment is greater than the last timestamp seen on the previous 170 incarnation of the connection (for that direction of the data 171 transfer), honour the connection request (creating a connection 172 in the SYN-RECEIVED state). 174 * If TCP timestamps would be enabled for the new incarnation of 175 the connection, the timestamp contained in the incoming SYN 176 segment is equal to the last timestamp seen on the previous 177 incarnation of the connection (for that direction of the data 178 transfer), and the Sequence Number of the incoming SYN segment 179 is greater than the last sequence number seen on the previous 180 incarnation of the connection (for that direction of the data 181 transfer), honour the connection request (creating a connection 182 in the SYN-RECEIVED state). 184 * If TCP timestamps would not be enabled for the new incarnation 185 of the connection, but the Sequence Number of the incoming SYN 186 segment is greater than the last sequence number seen on the 187 previous incarnation of the connection (for the same direction 188 of the data transfer), honour the connection request (creating 189 a connection in the SYN-RECEIVED state). 191 * Otherwise, silently drop the incoming SYN segment, thus leaving 192 the previous incarnation of the connection in the TIME-WAIT 193 state. 195 o If the previous incarnation of the connection did not use 196 timestamps, then, 198 * If TCP timestamps would be enabled for the new incarnation of 199 the connection, honour the incoming connection request 200 (creating a connection in the SYN-RECEIVED state). 202 * If TCP timestamps would not be enabled for the new incarnation 203 of the connection, but the Sequence Number of the incoming SYN 204 segment is greater than the last sequence number seen on the 205 previous incarnation of the connection (for the same direction 206 of the data transfer), honour the incoming connection request 207 (creating a connection in the SYN-RECEIVED state). 209 * Otherwise, silently drop the incoming SYN segment, thus leaving 210 the previous incarnation of the connection in the TIME-WAIT 211 state. 213 Note: 215 In the above explanation, the phrase "TCP timestamps would be 216 enabled for the new incarnation for the connection" means that the 217 incoming SYN segment contains a TCP Timestamps option (i.e., the 218 client has enabled TCP timestamps), and that the SYN/ACK segment 219 that would be sent in response to it would also contain a 220 Timestamps option (i.e., the server has enabled TCP timestamps). 221 In such a scenario, TCP timestamps would be enabled for the new 222 incarnation of the connection. 224 The "last sequence number seen on the previous incarnation of the 225 connection (for the same direction of the data transfer)" refers 226 to the last sequence number used by the previous incarnation of 227 the connection (for the same direction of the data transfer), and 228 not to the last value seen in the Sequence Number field of the 229 corresponding segments. That is, it refers to the sequence number 230 corresponding to the FIN flag of the previous incarnation of the 231 connection, for that direction of the data transfer. 233 Many implementations do not include the TCP timestamp option when 234 performing the above heuristics, thus imposing stricter constraints 235 on the generation of Initial Sequence Numbers, the average data 236 transfer rate of the connections, and the amount of data transferred 237 with them. RFC 793 [RFC0793] states that the ISN generator should be 238 incremented roughly once every four microseconds (i.e., roughly 239 250000 times per second). As a result, any connection that transfers 240 more than 250000 bytes of data at more than 250 kilobytes/second 241 could lead to scenarios in which the last sequence number seen on a 242 connection that moves into the TIME-WAIT state is still greater than 243 the sequence number of an incoming SYN segment that aims at creating 244 a new incarnation of the same connection. In those scenarios, the 245 4.4BSD heuristics would fail, and therefore the connection request 246 would usually time out. By including the TCP timestamp option in the 247 heuristics described above, all these constraints are greatly 248 relaxed. 250 It is clear that the use of TCP timestamps for the heuristics 251 described above benefit from timestamps that are monotonically 252 increasing across connections between the same two TCP endpoints. 254 Note: 255 The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], 256 recommends the selection of timestamps such that they are 257 monotonically-increasing across connections. An example of such a 258 Timestamps generation scheme can be found in 259 [I-D.gont-timestamps-generation]. 261 3. Interaction with various timestamps generation algorithms 263 The algorithm proposed in Section 2 clearly benefits of timestamps 264 that are monotonically-increasing across connections to the same end- 265 point. In particular, generation of timestamps such that they are 266 monotonically-increasing timestamps are important for TCPs that 267 perform the active open, as those are the timestamps that will be 268 used for the proposed algorithm. 270 While monotonically-increasing timestamps ensure that the proposed 271 algorithm will be able to reduce the TIME-WAIT state of a previous 272 incarnation of a connection, implementation of the algorithm does not 273 imply by itself a requirement on the timestamps generation algorithm 274 of other TCPs. 276 In the worst-case scenario, an incoming SYN corresponding to a new 277 incarnation of a connection in the TIME-WAIT contains a timestamp 278 that is smaller than the last timestamp seen on the previous 279 incarnation of the connection, the heuristics fail, and the result is 280 no worse than the current state-of-affairs. That is, the SYN segment 281 is ignored (as specified in [RFC1337]), and thus the connection 282 request times out, or is accepted after future retransmissions of the 283 SYN. 285 Some stacks may implement timestamps generation algorithms that do 286 not lead to monotonically-increasing timestamps across connections 287 with the same remote endpoint. An example of such algorithms is the 288 one described in [RFC4987] and [Opperman], that allows the 289 implementation of extended TCP SYN cookies. 291 Note: 292 It should be noted that the "extended TCP SYN cookies" could co- 293 exist with an algorithm for generating timestamps such that they 294 are monotonically-increasing. Monotonically increasing timestamps 295 could be generated for TCPs that perform the active open, while 296 timestamps for TCPs that perform the passive open could be 297 generated according to [Opperman]. 299 Some stacks (notably OpenBSD) implement timestamps randomization 300 algorithms which do not result in monotonically-increasing ISNs 301 across connections. As noted in [Silbersack], such randomization 302 schemes may prevent the mechanism proposed in this document from 303 recycling connections that are in the TIME-WAIT state. However, as 304 noted earlier in this section, in the worst-case scenario the 305 heuristics fail, and the result is no worse than the current state- 306 of-affairs. 308 4. Interaction with various ISN generation algorithms 310 [RFC0793] suggests that the ISNs of TCP connections be generated from 311 a global timer, such that they are monotonically-increasing across 312 connections. However, this ISN-generation scheme leads to 313 predictable ISNs, which have well-known security implications 314 [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme 315 which results in monotonically-increasing ISNs across connections 316 that are not easily-predictable by an off-path attacker. 318 Some stacks (notably OpenBSD) implement ISN randomization algorithms 319 which do not result in monotonically-increasing ISNs across 320 connections. As noted in [Silbersack], such ISN randomization 321 schemes break the BSD improved handling of SYN segments received for 322 connections that are in the TIME-WAIT state. 324 An implementation of the mechanism proposed in this document would 325 enable recycling of the TIME-WAIT state even in the presence of ISNs 326 that are not monotonically-increasing across connections, except when 327 the timestamp contained in the incoming SYN is equal to the last 328 timestamp seen on the connection in the TIME-WAIT state (for that 329 direction of the data transfer). 331 5. Security Considerations 333 [I-D.ietf-tcpm-tcp-security] contains a detailed discussion of the 334 security implications of TCP timestamps and of different Timestamps 335 generation algorithms. 337 6. IANA Considerations 339 This document has no actions for IANA. 341 7. Acknowledgements 343 This document is based on part of the contents of the technical 344 report "Security Assessment of the Transmission Control Protocol 345 (TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the United 346 Kingdom's Centre for the Protection of National Infrastructure (UK 347 CPNI). 349 The author of this document would like to thank (in alphabetical 350 order) Mark Allman, Francis Dupont, Wesley Eddy, Lars Eggert, Alfred 351 Hoenes, John Heffner, Christian Huitema, Eric Rescorla, Joe Touch, 352 and Alexander Zimmermann for providing valuable feedback on an 353 earlier version of this document. 355 Additionally, the author would like to thank David Borman for a 356 fruitful discussion on TCP timestamps at IETF 73. 358 Finally, the author would like to thank the United Kingdom's Centre 359 for the Protection of National Infrastructure (UK CPNI) for their 360 continued support. 362 8. References 364 8.1. Normative References 366 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 367 RFC 793, September 1981. 369 [RFC1122] Braden, R., "Requirements for Internet Hosts - 370 Communication Layers", STD 3, RFC 1122, October 1989. 372 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 373 for High Performance", RFC 1323, May 1992. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 8.2. Informative References 380 [CPNI-TCP] 381 CPNI, "Security Assessment of the Transmission Control 382 Protocol (TCP)", 2009, . 385 [I-D.gont-timestamps-generation] 386 Gont, F. and A. Oppermann, "On the generation of TCP 387 timestamps", draft-gont-timestamps-generation-00 (work in 388 progress), June 2010. 390 [I-D.ietf-tcpm-1323bis] 391 Borman, D., Braden, R., and V. Jacobson, "TCP Extensions 392 for High Performance", draft-ietf-tcpm-1323bis-01 (work in 393 progress), March 2009. 395 [I-D.ietf-tcpm-tcp-security] 396 Gont, F., "Security Assessment of the Transmission Control 397 Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in 398 progress), January 2011. 400 [INFOCOM-99] 401 Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in 402 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 403 1999, pp. 1573-1583 . 405 [Linux] The Linux Project, "http://www.kernel.org". 407 [Opperman] 408 Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- 409 current", Post to the tcpm mailing-list. Available at: ht 410 tp://www.ietf.org/mail-archive/web/tcpm/current/ 411 msg02251.html, 2006. 413 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 414 RFC 1337, May 1992. 416 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 417 RFC 1948, May 1996. 419 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 420 Mitigations", RFC 4987, August 2007. 422 [Silbersack] 423 Silbersack, M., "Improving TCP/IP security through 424 randomization without sacrificing interoperability", 425 EuroBSDCon 2005 Conference . 427 Appendix A. Behavior of the proposed mechanism in specific scenarios 429 A.1. Connection request after system reboot 431 This section clarifies how this algorithm would operate in case a 432 computer reboots, keeps the same IP address, looses memory of the 433 previous timestamps, and then tries to reestablish a previous 434 connection. 436 Firstly, as specified in [RFC0793], hosts must not establish new 437 connections for a period of 2*MSL (Maximum Segment Lifetime) after 438 they boot (this is the "quiet time" concept). As a result, specs- 439 wise, this scenario should never occur. 441 If a host does not comply with the "quiet time concept", a connection 442 request might be sent to a remote host while there is a previous 443 incarnation of the same connection in the TIME-WAIT state at the 444 remote host. In such a scenario, as a result of having lost memory 445 of previous time stamps, the resulting timestamps might not be 446 monotonically-increasing, and hence the proposed algorithm might be 447 unable to recycle the previous incarnation of the connection that is 448 in the TIME-WAIT state. This case corresponds to the current state- 449 of-affairs without the algorithm proposed in this document. 451 Appendix B. Changes from previous versions of the draft (to be removed 452 by the RFC Editor before publishing this document as an 453 RFC) 455 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-03 457 o Addresses Tim Polk's DISCUSS. 459 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-02 461 o Addresses COMMENTs received during IESG review, and maybe Tim 462 Polk's DISCUSS. 464 B.3. Changes from draft-ietf-tcpm-tcp-timestamps-01 466 o Addresses AD-review comments by Lars Eggert. 468 B.4. Changes from draft-ietf-tcpm-tcp-timestamps-00 470 o Addresses WG Last call comments received from Wesley Eddy, John 471 Heffner and Joe Touch. 473 o Minor editorial fix (reported by Wes Eddy). 475 B.5. Changes from draft-gont-tcpm-tcp-timestamps-04 477 o Draft resubmitted as draft-ietf. 479 B.6. Changes from draft-gont-tcpm-tcp-timestamps-03 481 o Changed the document title 483 o Removed all the text related to the algorithm earlier proposed for 484 timestamps generation. 486 o Addresses comments received from Alexander Zimmermann, Christian 487 Huitema, Joe Touch, and others. 489 B.7. Changes from draft-gont-tcpm-tcp-timestamps-02 491 o Minor edits (the I-D was just about to expire, so it was 492 resubmitted with almost no changes). 494 B.8. Changes from draft-gont-tcpm-tcp-timestamps-01 496 o Version -01 of the draft had expired, and hence the I-D is 497 resubmitted to make it available again (no changes). 499 B.9. Changes from draft-gont-tcpm-tcp-timestamps-00 501 o Fixed author's affiliation. 503 o Addressed feedback submitted by Alfred Hoenes (see: 504 http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), 505 plus nits sent by Alfred off-list. 507 Author's Address 509 Fernando Gont 510 UK Centre for the Protection of National Infrastructure 512 Email: fernando@gont.com.ar 513 URI: http://www.cpni.gov.uk