idnits 2.17.1 draft-ietf-tcpm-tcp-timestamps-02.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 (December 7, 2010) is 4888 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 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 2 errors (**), 0 flaws (~~), 4 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 December 7, 2010 5 Intended status: BCP 6 Expires: June 10, 2011 8 Reducing the TIME-WAIT state using TCP timestamps 9 draft-ietf-tcpm-tcp-timestamps-02.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 June 10, 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-01 . . . . . . 10 83 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10 84 B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 85 B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11 86 B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 87 B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 88 B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 94 to include a timestamp value in its segments, that can be used to 95 perform two functions: Round-Trip Time Measurement (RTTM), and 96 Protection Against Wrapped Sequences (PAWS). 98 For the purpose of PAWS, the timestamps sent on a connection are 99 required to be monotonically increasing. While there is no 100 requirement that timestamps are monotonically increasing across TCP 101 connections, the generation of timestamps such that they are 102 monotonically increasing across connections between the same two 103 endpoints allows the use of timestamps for improving the handling of 104 SYN segments that are received while the corresponding four-tuple is 105 in the TIME-WAIT state. That is, the timestamp option could be used 106 to perform heuristics to determine whether to allow the creation of a 107 new incarnation of a connection that is in the TIME-WAIT state. 109 This use of TCP timestamps is simply an extrapolation of the use of 110 Initial Sequence Numbers (ISNs) for the same purpose, as allowed by 111 RFC 1122 [RFC1122], and it has been incorporated in a number of TCP 112 implementations, such as that included in the Linux kernel [Linux]. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Improved processing of incoming connection requests 120 In a number of scenarios a socket pair may need to be reused while 121 the corresponding four-tuple is still in the TIME-WAIT state in a 122 remote TCP peer. For example, a client accessing some service on a 123 host may try to create a new incarnation of a previous connection, 124 while the corresponding four-tuple is still in the TIME-WAIT state at 125 the remote TCP peer (the server). This may happen if the ephemeral 126 port numbers are being reused too quickly, either because of a bad 127 policy of selection of ephemeral ports, or simply because of a high 128 connection rate to the corresponding service. In such scenarios, the 129 establishment of new connections that reuse a four-tuple that is in 130 the TIME-WAIT state would fail. This problem is discussed in detail 131 in [INFOCOM-99]. 133 In order to avoid this problem, RFC 1122 [RFC1122] (in Section 134 4.2.2.13) states that when a connection request is received with a 135 four-tuple that is in the TIME-WAIT state, the connection request 136 could be accepted if the sequence number of the incoming SYN segment 137 is greater than the last sequence number seen on the previous 138 incarnation of the connection (for that direction of the data 139 transfer). This requirement aims at avoiding the sequence number 140 space of the new and old incarnations of the connection to overlap, 141 thus avoiding old segments from the previous incarnation of the 142 connection to be accepted as valid by the new connection. 144 The same policy may be extrapolated to TCP timestamps. That is, when 145 a connection request is received with a four-tuple that is in the 146 TIME-WAIT state, the connection request could be accepted if the 147 timestamp of the incoming SYN segment is greater than the last 148 timestamp seen on the previous incarnation of the connection (for 149 that direction of the data transfer). 151 The following paragraphs summarize the processing of SYN segments 152 received for connections in the TIME-WAIT state. The processing of 153 SYN segments received for connections in all other states is 154 unchanged. Both the ISN (Initial Sequence Number) and the timestamps 155 option (if present) of the incoming SYN segment are included in the 156 heuristics performed for allowing a high connection-establishment 157 rate. 159 Processing of SYN segments received for connections in the TIME-WAIT 160 state SHOULD occur as follows: 162 o If the previous incarnation of the connection used timestamps, 163 then, 165 * If TCP timestamps would be enabled for the new incarnation of 166 the connection, and the timestamp contained in the incoming SYN 167 segment is greater than the last timestamp seen on the previous 168 incarnation of the connection (for that direction of the data 169 transfer), honour the connection request (creating a connection 170 in the SYN-RECEIVED state). 172 * If TCP timestamps would be enabled for the new incarnation of 173 the connection, the timestamp contained in the incoming SYN 174 segment is equal to the last timestamp seen on the previous 175 incarnation of the connection (for that direction of the data 176 transfer), and the Sequence Number of the incoming SYN segment 177 is larger than the last sequence number seen on the previous 178 incarnation of the connection (for that direction of the data 179 transfer), then honour the connection request (creating a 180 connection in the SYN-RECEIVED state). 182 * If TCP timestamps would not be enabled for the new incarnation 183 of the connection, but the Sequence Number of the incoming SYN 184 segment is larger than the last sequence number seen on the 185 previous incarnation of the connection (for the same direction 186 of the data transfer), honour the connection request (creating 187 a connection in the SYN-RECEIVED state). 189 * Otherwise, silently drop the incoming SYN segment, thus leaving 190 the previous incarnation of the connection in the TIME-WAIT 191 state. 193 o If the previous incarnation of the connection did not use 194 timestamps, then, 196 * If TCP timestamps would be enabled for the new incarnation of 197 the connection, honour the incoming connection request. 199 * If TCP timestamps would not be enabled for the new incarnation 200 of the connection, but the Sequence Number of the incoming SYN 201 segment is larger than the last sequence number seen on the 202 previous incarnation of the connection (for the same direction 203 of the data transfer), then honour the incoming connection 204 request (even if the sequence number of the incoming SYN 205 segment falls within the receive window of the previous 206 incarnation of the connection). 208 * Otherwise, silently drop the incoming SYN segment, thus leaving 209 the previous incarnation of the connection in the TIME-WAIT 210 state. 212 Note: 214 In the above explanation, the phrase "TCP timestamps would be 215 enabled for the new incarnation for the connection" means that the 216 incoming SYN segment contains a TCP Timestamps option (i.e., the 217 client has enabled TCP timestamps), and that the SYN/ACK segment 218 that would be sent in response to it would also contain a 219 Timestamps option (i.e., the server has enabled TCP timestamps). 220 In such a scenario, TCP timestamps would be enabled for the new 221 incarnation of the connection. 223 The "last sequence number seen on the previous incarnation of the 224 connection (for the same direction of the data transfer)" refers 225 to the last sequence number used by the previous incarnation of 226 the connection (for the same direction of the data transfer), and 227 not to the last value seen in the Sequence Number field of the 228 corresponding segments. That is, it refers to the sequence number 229 corresponding to the FIN flag of the previous incarnation of the 230 connection, for that direction of the data transfer. 232 Many implementations do not include the TCP timestamp option when 233 performing the above heuristics, thus imposing stricter constraints 234 on the generation of Initial Sequence Numbers, the average data 235 transfer rate of the connections, and the amount of data transferred 236 with them. RFC 793 [RFC0793] states that the ISN generator should be 237 incremented roughly once every four microseconds (i.e., roughly 238 250000 times per second). As a result, any connection that transfers 239 more than 250000 bytes of data at more than 250 KB/s could lead to 240 scenarios in which the last sequence number seen on a connection that 241 moves into the TIME-WAIT state is still greater than the sequence 242 number of an incoming SYN segment that aims at creating a new 243 incarnation of the same connection. In those scenarios, the 4.4BSD 244 heuristics would fail, and therefore the connection request would 245 usually time out. By including the TCP timestamp option in the 246 heuristics described above, all these constraints are greatly 247 relaxed. 249 It is clear that the use of TCP timestamps for the heuristics 250 described above benefit from timestamps that are monotonically 251 increasing across connections between the same two TCP endpoints. 253 Note: 254 The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], 255 recommends the selection of timestamps such that they are 256 monotonically-increasing across connections. An example of such a 257 Timestamps generation scheme can be found in 258 [I-D.gont-timestamps-generation]. 260 3. Interaction with various timestamps generation algorithms 262 The algorithm proposed in Section 2 clearly benefits of timestamps 263 that are monotonically-increasing across connections to the same end- 264 point. In particular, generation of timestamps such that they are 265 monotonically-increasing timestamps are important for TCPs that 266 perform the active open, as those are the timestamps that will be 267 used for the proposed algorithm. 269 While monotonically-increasing timestamps ensure that the proposed 270 algorithm will be able to reduce the TIME-WAIT state of a previous 271 incarnation of a connection, implementation of the algorithm does not 272 imply by itself a requirement on the timestamps generation algorithm 273 of other TCPs. 275 In the worst-case scenario, an incoming SYN corresponding to a new 276 incarnation of a connection in the TIME-WAIT contains a timestamp 277 that is smaller than the last timestamp seen on the previous 278 incarnation of the connection, the heuristics fail, and the result is 279 no worse than the current state-of-affairs. That is, the SYN segment 280 is ignored (as specified in [RFC1337]), and thus the connection 281 request times out, or is accepted after future retransmissions of the 282 SYN. 284 Some stacks may implement timestamps generation algorithms that do 285 not lead to monotonically-increasing timestamps across connections 286 with the same remote endpoint. An example of such algorithms is the 287 one described in [RFC4987] and [Opperman], that allows the 288 implementation of extended TCP SYN cookies. 290 Note: 291 It should be noted that the "extended TCP SYN cookies" could co- 292 exist with an algorithm for generating timestamps such that they 293 are monotonically-increasing. Monotonically increasing timestamps 294 could be generated for TCPs that perform the active open, while 295 timestamps for TCPs that perform the passive open could be 296 generated according to [Opperman]. 298 Some stacks (notably OpenBSD) implement timestamps randomization 299 algorithms which do not result in monotonically-increasing ISNs 300 across connections. As noted in [Silbersack], such randomization 301 schemes break prevent the mechanism proposed in this document from 302 recycling connections that are in the TIME-WAIT state. However, as 303 noted earlier in this section, in the worst-case scenario the 304 heuristics fail, and the result is no worse than the current state- 305 of-affairs. 307 4. Interaction with various ISN generation algorithms 309 [RFC0793] suggests that the ISNs of TCP connections be generated from 310 a global timer, such that they are monotonically-increasing across 311 connections. However, this ISN-generation scheme leads to 312 predictable ISNs, which have well-known security implications 313 [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme 314 which results in monotonically-increasing timestamps across 315 connections that are not easily-predictable by an off-path attacker. 317 Some stacks (notably OpenBSD) implement ISN randomization algorithms 318 which do not result in monotonically-increasing ISNs across 319 connections. As noted in [Silbersack], such ISN randomization 320 schemes break the BSD improved handling of SYN segments received for 321 connections that are in the TIME-WAIT state. 323 An implementation of the mechanism proposed in this document would 324 enable recycling of the TIME-WAIT state even in the presence of ISNs 325 that are not monotonically-increasing across connections, except when 326 the timestamp contained in the incoming SYN is equal to the last 327 timestamp seen on the connection in the TIME-WAIT state (for that 328 direction of the data transfer). 330 5. Security Considerations 332 While the algorithm described in this document for processing 333 incoming SYN segments would benefit from TCP timestamps that are 334 monotonically-increasing across connections, this document does not 335 propose any specific algorithm for generating timestamps, nor does it 336 require monotonically-increasing timestamps across connections. 338 [CPNI-TCP] contains a detailed discussion of the security 339 implications of TCP timestamps. 341 6. IANA Considerations 343 This document has no actions for IANA. 345 7. Acknowledgements 347 The author of this document would like to thank (in alphabetical 348 order) Mark Allman, Wesley Eddy, Lars Eggert, Alfred Hoenes, John 349 Heffner, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander 350 Zimmermann for providing valuable feedback on an earlier version of 351 this document. 353 Additionally, the author would like to thank David Borman for a 354 fruitful discussion on TCP timestamps at IETF 73. 356 Finally, the author would like to thank the United Kingdom's Centre 357 for the Protection of National Infrastructure (UK CPNI) for their 358 continued support. 360 8. References 362 8.1. Normative References 364 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 365 RFC 793, September 1981. 367 [RFC1122] Braden, R., "Requirements for Internet Hosts - 368 Communication Layers", STD 3, RFC 1122, October 1989. 370 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 371 for High Performance", RFC 1323, May 1992. 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 8.2. Informative References 378 [CPNI-TCP] 379 CPNI, "Security Assessment of the Transmission Control 380 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 381 tn-03-09-security-assessment-TCP.pdf, 2009. 383 [I-D.gont-timestamps-generation] 384 Gont, F. and A. Oppermann, "On the generation of TCP 385 timestamps", draft-gont-timestamps-generation-00 (work in 386 progress), June 2010. 388 [I-D.ietf-tcpm-1323bis] 389 Borman, D., Braden, R., and V. Jacobson, "TCP Extensions 390 for High Performance", draft-ietf-tcpm-1323bis-01 (work in 391 progress), March 2009. 393 [INFOCOM-99] 394 Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in 395 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 396 1999, pp. 1573-1583 . 398 [Linux] The Linux Project, "http://www.kernel.org". 400 [Opperman] 401 Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- 402 current", Post to the tcpm mailing-list. Available at: ht 403 tp://www.ietf.org/mail-archive/web/tcpm/current/ 404 msg02251.html, 2006. 406 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 407 RFC 1337, May 1992. 409 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 410 RFC 1948, May 1996. 412 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 413 Mitigations", RFC 4987, August 2007. 415 [Silbersack] 416 Silbersack, M., "Improving TCP/IP security through 417 randomization without sacrificing interoperability", 418 EuroBSDCon 2005 Conference . 420 Appendix A. Behavior of the proposed mechanism in specific scenarios 422 A.1. Connection request after system reboot 424 This section clarifies how this algorithm would operate in case a 425 computer reboots, keeps the same IP address, looses memory of the 426 previous time stamps, and then tries to reestablish a previous 427 connection. 429 Firstly, as specified in [RFC0793], hosts must not establish new 430 connections for a period of 2*MSL after they boot (this is the "quiet 431 time" concept). As a result, specs-wise, this scenario should never 432 occur. 434 If a host does not comply with the "quiet time concept", then the 435 possible scenarios are: 437 o If the selected timestamp for the new connection is monotonically- 438 increasing with respect to the last timestamp seen on the previous 439 incarnation of the connection, the TIME-WAIT state is tossed, and 440 the new connection request succeeds. 442 o Otherwise, the connection request may time out or be rejected 443 (depending on whether the workaround described in [RFC1337] is 444 implemented or not). This case corresponds to the current state- 445 of-affairs without the algorithm proposed in this document. 447 Appendix B. Changes from previous versions of the draft (to be removed 448 by the RFC Editor before publishing this document as an 449 RFC) 451 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-01 453 o Addresses AD-review comments by Lars Eggert. 455 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 457 o Addresses WG Last call comments received from Wesley Eddy, John 458 Heffner and Joe Touch. 460 o Minor editorial fix (reported by Wes Eddy). 462 B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 464 o Draft resubmitted as draft-ietf. 466 B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 468 o Changed the document title 470 o Removed all the text related to the algorithm earlier proposed for 471 timestamps generation. 473 o Addresses comments received from Alexander Zimmermann, Christian 474 Huitema, Joe Touch, and others. 476 B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 478 o Minor edits (the I-D was just about to expire, so it was 479 resubmitted with almost no changes). 481 B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 483 o Version -01 of the draft had expired, and hence the I-D is 484 resubmitted to make it available again (no changes). 486 B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 488 o Fixed author's affiliation. 490 o Addressed feedback submitted by Alfred Hoenes (see: 491 http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), 492 plus nits sent by Alfred off-list. 494 Author's Address 496 Fernando Gont 497 UK Centre for the Protection of National Infrastructure 499 Email: fernando@gont.com.ar 500 URI: http://www.cpni.gov.uk