idnits 2.17.1 draft-ietf-tcpm-tcp-timestamps-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (November 16, 2010) is 4909 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) ** Downref: Normative reference to an Informational RFC: RFC 1337 == Outdated reference: A later version (-21) exists of draft-ietf-tcpm-1323bis-01 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 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 November 16, 2010 5 Intended status: BCP 6 Expires: May 20, 2011 8 Reducing the TIME-WAIT state using TCP timestamps 9 draft-ietf-tcpm-tcp-timestamps-01.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 May 20, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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-00 . . . . . . 10 83 B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 84 B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 10 85 B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 86 B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 87 B.6. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 93 to include a timestamp value in its segments, that can be used to 94 perform two functions: Round-Trip Time Measurement (RTTM), and 95 Protection Against Wrapped Sequences (PAWS). 97 For the purpose of PAWS, the timestamps sent on a connection are 98 required to be monotonically increasing. While there is no 99 requirement that timestamps are monotonically increasing across TCP 100 connections, the generation of timestamps such that they are 101 monotonically increasing across connections between the same two 102 endpoints allows the use of timestamps for improving the handling of 103 SYN segments that are received while the corresponding four-tuple is 104 in the TIME-WAIT state. That is, the timestamp option could be used 105 to perform heuristics to determine whether to allow the creation of a 106 new incarnation of a connection that is in the TIME-WAIT state. 108 This use of TCP timestamps is simply an extrapolation of the use of 109 Initial Sequence Numbers (ISNs) for the same purpose, as allowed by 110 RFC 1122 [RFC1122], and it has been incorporated in a number of TCP 111 implementations, such as that included in the Linux kernel [Linux]. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Improved processing of incoming connection requests 119 In a number of scenarios a socket pair may need to be reused while 120 the corresponding four-tuple is still in the TIME-WAIT state in a 121 remote TCP peer. For example, a client accessing some service on a 122 host may try to create a new incarnation of a previous connection, 123 while the corresponding four-tuple is still in the TIME-WAIT state at 124 the remote TCP peer (the server). This may happen if the ephemeral 125 port numbers are being reused too quickly, either because of a bad 126 policy of selection of ephemeral ports, or simply because of a high 127 connection rate to the corresponding service. In such scenarios, the 128 establishment of new connections that reuse a four-tuple that is in 129 the TIME-WAIT state would fail. This problem is discussed in detail 130 in [INFOCOM-99]. 132 In order to avoid this problem, RFC 1122 [RFC1122] (in Section 133 4.2.2.13) states that when a connection request is received with a 134 four-tuple that is in the TIME-WAIT state, the connection request 135 could be accepted if the sequence number of the incoming SYN segment 136 is greater than the last sequence number seen on the previous 137 incarnation of the connection (for that direction of the data 138 transfer). This requirement aims at avoiding the sequence number 139 space of the new and old incarnations of the connection to overlap, 140 thus avoiding old segments from the previous incarnation of the 141 connection to be accepted as valid by the new connection. 143 The same policy may be extrapolated to TCP timestamps. That is, when 144 a connection request is received with a four-tuple that is in the 145 TIME-WAIT state, the connection request could be accepted if the 146 timestamp of the incoming SYN segment is greater than the last 147 timestamp seen on the previous incarnation of the connection (for 148 that direction of the data transfer). 150 The following paragraphs summarize the processing of SYN segments 151 received for connections in the TIME-WAIT state. The processing of 152 SYN segments received for connections in all other states is 153 unchanged. Both the ISN (Initial Sequence Number) and the timestamps 154 option (if present) of the incoming SYN segment are included in the 155 heuristics performed for allowing a high connection-establishment 156 rate. 158 Processing of SYN segments received for connections in the TIME-WAIT 159 state should occur as follows: 161 o If the previous incarnation of the connection used timestamps, 162 then, 164 * If TCP timestamps would be enabled for the new incarnation of 165 the connection, and the timestamp contained in the incoming SYN 166 segment is greater than the last timestamp seen on the previous 167 incarnation of the connection (for that direction of the data 168 transfer), honour the connection request (creating a connection 169 in the SYN-RECEIVED state). 171 * If TCP timestamps would be enabled for the new incarnation of 172 the connection, the timestamp contained in the incoming SYN 173 segment is equal to the last timestamp seen on the previous 174 incarnation of the connection (for that direction of the data 175 transfer), and the Sequence Number of the incoming SYN segment 176 is larger than the last sequence number seen on the previous 177 incarnation of the connection (for that direction of the data 178 transfer), then honour the connection request (creating a 179 connection in the SYN-RECEIVED state). 181 * If TCP timestamps would not be enabled for the new incarnation 182 of the connection, but the Sequence Number of the incoming SYN 183 segment is larger than the last sequence number seen on the 184 previous incarnation of the connection (for the same direction 185 of the data transfer), honour the connection request (creating 186 a connection in the SYN-RECEIVED state). 188 * Otherwise, silently drop the incoming SYN segment, thus leaving 189 the previous incarnation of the connection in the TIME-WAIT 190 state. 192 o If the previous incarnation of the connection did not use 193 timestamps, then, 195 * If TCP timestamps would be enabled for the new incarnation of 196 the connection, honour the incoming connection request. 198 * If TCP timestamps would not be enabled for the new incarnation 199 of the connection, but the Sequence Number of the incoming SYN 200 segment is larger than the last sequence number seen on the 201 previous incarnation of the connection (for the same direction 202 of the data transfer), then honour the incoming connection 203 request (even if the sequence number of the incoming SYN 204 segment falls within the receive window of the previous 205 incarnation of the connection). 207 * Otherwise, silently drop the incoming SYN segment, thus leaving 208 the previous incarnation of the connection in the TIME-WAIT 209 state. 211 Note: 213 In the above explanation, the phrase "TCP timestamps would be 214 enabled for the new incarnation for the connection" means that the 215 incoming SYN segment contains a TCP Timestamps option (i.e., the 216 client has enabled TCP timestamps), and that the SYN/ACK segment 217 that would be sent in response to it would also contain a 218 Timestamps option (i.e., the server has enabled TCP timestamps). 219 In such a scenario, TCP timestamps would be enabled for the new 220 incarnation of the connection. 222 The "last sequence number seen on the previous incarnation of the 223 connection (for the same direction of the data transfer)" refers 224 to the last sequence number used by the previous incarnation of 225 the connection (for the same direction of the data transfer), and 226 not to the last value seen in the Sequence Number field of the 227 corresponding segments. That is, it refers to the sequence number 228 corresponding to the FIN flag of the previous incarnation of the 229 connection, for that direction of the data transfer. 231 Many implementations do not include the TCP timestamp option when 232 performing the above heuristics, thus imposing stricter constraints 233 on the generation of Initial Sequence Numbers, the average data 234 transfer rate of the connections, and the amount of data transferred 235 with them. RFC 793 [RFC0793] states that the ISN generator should be 236 incremented roughly once every four microseconds (i.e., roughly 237 250000 times per second). As a result, any connection that transfers 238 more than 250000 bytes of data at more than 250 KB/s could lead to 239 scenarios in which the last sequence number seen on a connection that 240 moves into the TIME-WAIT state is still greater than the sequence 241 number of an incoming SYN segment that aims at creating a new 242 incarnation of the same connection. In those scenarios, the 4.4BSD 243 heuristics would fail, and therefore the connection request would 244 usually time out. By including the TCP timestamp option in the 245 heuristics described above, all these constraints are greatly 246 relaxed. 248 It is clear that the use of TCP timestamps for the heuristics 249 described above benefit from timestamps that are monotonically 250 increasing across connections between the same two TCP endpoints. 252 Note: 253 The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], 254 recommends the selection of timestamps such that they are 255 monotonically-increasing across connections. Specific 256 implementation details for such a Timestamps generation scheme can 257 be found in [I-D.gont-timestamps-generation]. 259 3. Interaction with various timestamps generation algorithms 261 The algorithm proposed in Section 2 clearly benefits of timestamps 262 that are monotonically-increasing across connections to the same end- 263 point. In particular, generation of timestamps such that they are 264 monotonically-increasing timestamps are important for TCPs that 265 perform the active open, as those are the timestamps that will be 266 used for the proposed algorithm. 268 While monotonically-increasing timestamps ensure that the proposed 269 algorithm will be able to reduce the TIME-WAIT state of a previous 270 incarnation of a connection, implementation of the algorithm does not 271 imply by itself a requirement on the timestamps generation algorithm 272 of other TCPs. 274 In the worst-case scenario, an incoming SYN corresponding to a new 275 incarnation of a connection in the TIME-WAIT contains a timestamp 276 that is smaller than the last timestamp seen on the previous 277 incarnation of the connection, the heuristics fail, and the result is 278 no worse than the current state-of-affairs. That is, the SYN segment 279 is ignored (as specified in [RFC1337]), and thus the connection 280 request times out, or is accepted after future retransmissions of the 281 SYN. 283 Some stacks may implement timestamps generation algorithms that do 284 not lead to monotonically-increasing timestamps across connections 285 with the same remote endpoint. An example of such algorithms is the 286 one described in [RFC4987] and [Opperman], that allows the 287 implementation of extended TCP SYN cookies. 289 Note: 290 It should be noted that the "extended TCP SYN cookies" could co- 291 exist with an algorithm for generating timestamps such that they 292 are monotonically-increasing. Monotonically increasing timestamps 293 could be generated for TCPs that perform the active open, while 294 timestamps for TCPs that perform the passive open could be 295 generated according to [Opperman]. 297 Some stacks (notably OpenBSD) implement timestamps randomization 298 algorithms which do not result in monotonically-increasing ISNs 299 across connections. As noted in [Silbersack], such randomization 300 schemes break prevent the mechanism proposed in this document from 301 recycling connections that are in the TIME-WAIT state. However, as 302 noted earlier in this section, in the worst-case scenario the 303 heuristics fail, and the result is no worse than the current state- 304 of-affairs. 306 4. Interaction with various ISN generation algorithms 308 [RFC0793] suggests that the ISNs of TCP conections be generated from 309 a global timer, such that they are monotonically-increasing across 310 connections. However, this ISN-generation scheme leads to 311 predictable ISNs, which have well-known security implications 312 [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme 313 which results in monotonically-increasing timestamps across 314 connections that are not easily-predictable by an off-path attacker. 316 Some stacks (notably OpenBSD) implement ISN randomization algorithms 317 which do not result in monotonically-increasing ISNs across 318 connections. As noted in [Silbersack], such ISN randomization 319 schemes break the BSD improved handling of SYN segments received for 320 connections that are in the TIME-WAIT state. 322 An implementation of the mechanism proposed in this document would 323 enable recycling of the TIME-WAIT state even in the presence of ISNs 324 that are not monotonically-increasing across connections, except when 325 the timestamp contained in the incoming SYN is equal to the last 326 timestamp seen on the connection in the TIME-WAIT state (for that 327 direction of the data transfer). 329 5. Security Considerations 331 While the algorithm described in this document for processing 332 incoming SYN segments would benefit from TCP timestamps that are 333 monotonically-increasing across connections, this document does not 334 propose any specific algorithm for generating timestamps, nor does it 335 require monotonically-increasing timestamps across conenctions. 337 [CPNI-TCP] contains a detailed discussion of the security 338 implications of TCP timestamps. 340 6. IANA Considerations 342 This document has no actions for IANA. 344 7. Acknowledgements 346 The author of this document would like to thank (in alphabetical 347 order) Mark Allman, Wesley Eddy, Alfred Hoenes, John Heffner, 348 Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann 349 for providing valuable feedback on an earlier version of this 350 document. 352 Additionally, the author would like to thank David Borman for a 353 fruitful discussion on TCP timestamps at IETF 73. 355 Finally, the author would like to thank the United Kingdom's Centre 356 for the Protection of National Infrastructure (UK CPNI) for their 357 continued support. 359 8. References 361 8.1. Normative References 363 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 364 RFC 793, September 1981. 366 [RFC1122] Braden, R., "Requirements for Internet Hosts - 367 Communication Layers", STD 3, RFC 1122, October 1989. 369 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 370 for High Performance", RFC 1323, May 1992. 372 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 373 RFC 1337, 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)", http://www.cpni.gov.uk/Docs/ 383 tn-03-09-security-assessment-TCP.pdf, 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 [INFOCOM-99] 396 Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in 397 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 398 1999, pp. 1573-1583 . 400 [Linux] The Linux Project, "http://www.kernel.org". 402 [Opperman] 403 Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- 404 current", Post to the tcpm mailing-list. Available at: ht 405 tp://www.ietf.org/mail-archive/web/tcpm/current/ 406 msg02251.html, 2006. 408 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 409 RFC 1948, May 1996. 411 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 412 Mitigations", RFC 4987, August 2007. 414 [Silbersack] 415 Silbersack, M., "Improving TCP/IP security through 416 randomization without sacrificing interoperability", 417 EuroBSDCon 2005 Conference . 419 Appendix A. Behavior of the proposed mechanism in specific scenarios 421 A.1. Connection request after system reboot 423 The question was raised on the tcpm mailing-list as to how this 424 algorithm would operate in case a computer reboots, keeps the same IP 425 address, looses memory of the previous time stamps, and then tries to 426 reestablish a previous connection. 428 Firstly, as specified in [RFC0793], hosts must not establish new 429 connections for a period of 2*MSL after they boot (this is the "quiet 430 time" concept). As a result, specs-wise, this scenario should never 431 occur. 433 If a host does not comply with the "quiet time concept", then the 434 possible scenarios are: 436 o If the selected timestamp for the new connection is monotonically- 437 increasing with respect to the last timestamp seen on the previous 438 incarnation of the connection, the TIME-WAIT state is tossed, and 439 the new connection request succeeds. 441 o Otherwise, the connection request may time out or be rejected 442 (depending on whether the workaround described in [RFC1337] is 443 implemented or not). This case corresponds to the current state- 444 of-affairs without the algorithm proposed in this document. 446 Appendix B. Changes from previous versions of the draft (to be removed 447 by the RFC Editor before publishing this document as an 448 RFC) 450 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00 452 o Addresses WG Last call comments received from Wesley Eddy, John 453 Heffner and Joe Touch. 455 o Minor editorial fix (reported by Wes Eddy). 457 B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 459 o Draft resubmitted as draft-ietf. 461 B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 463 o Changed the document title 464 o Removed all the text related to the algorithm earlier proposed for 465 timestamps generation. 467 o Addresses comments received from Alexander Zimmermann, Christian 468 Huitema, Joe Touch, and others. 470 B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 472 o Minor edits (the I-D was just about to expire, so it was 473 resubmitted with almost no changes). 475 B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 477 o Version -01 of the draft had expired, and hence the I-D is 478 resubmitted to make it available again (no changes). 480 B.6. Changes from draft-gont-tcpm-tcp-timestamps-00 482 o Fixed author's affiliation. 484 o Addressed feedback submitted by Alfred Hoenes (see: 485 http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), 486 plus nits sent by Alfred off-list. 488 Author's Address 490 Fernando Gont 491 UK Centre for the Protection of National Infrastructure 493 Email: fernando@gont.com.ar 494 URI: http://www.cpni.gov.uk