idnits 2.17.1 draft-ietf-tcpm-tcp-timestamps-03.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 20, 2010) is 4875 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 20, 2010 5 Intended status: BCP 6 Expires: June 23, 2011 8 Reducing the TIME-WAIT state using TCP timestamps 9 draft-ietf-tcpm-tcp-timestamps-03.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 23, 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 . . . . . . . . . . . . . . . . . . . . . . 9 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-02 . . . . . . 10 83 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10 84 B.3. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10 85 B.4. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 86 B.5. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11 87 B.6. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 88 B.7. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 89 B.8. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 95 to include a timestamp value in its segments, that can be used to 96 perform two functions: Round-Trip Time Measurement (RTTM), and 97 Protection Against Wrapped Sequences (PAWS). 99 For the purpose of PAWS, the timestamps sent on a connection are 100 required to be monotonically increasing. While there is no 101 requirement that timestamps are monotonically increasing across TCP 102 connections, the generation of timestamps such that they are 103 monotonically increasing across connections between the same two 104 endpoints allows the use of timestamps for improving the handling of 105 SYN segments that are received while the corresponding four-tuple is 106 in the TIME-WAIT state. That is, the timestamp option could be used 107 to perform heuristics to determine whether to allow the creation of a 108 new incarnation of a connection that is in the TIME-WAIT state. 110 This use of TCP timestamps is simply an extrapolation of the use of 111 Initial Sequence Numbers (ISNs) for the same purpose, as allowed by 112 RFC 1122 [RFC1122], and it has been incorporated in a number of TCP 113 implementations, such as that included in the Linux kernel [Linux]. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Improved processing of incoming connection requests 121 In a number of scenarios a socket pair may need to be reused while 122 the corresponding four-tuple is still in the TIME-WAIT state in a 123 remote TCP peer. For example, a client accessing some service on a 124 host may try to create a new incarnation of a previous connection, 125 while the corresponding four-tuple is still in the TIME-WAIT state at 126 the remote TCP peer (the server). This may happen if the ephemeral 127 port numbers are being reused too quickly, either because of a bad 128 policy of selection of ephemeral ports, or simply because of a high 129 connection rate to the corresponding service. In such scenarios, the 130 establishment of new connections that reuse a four-tuple that is in 131 the TIME-WAIT state would fail. This problem is discussed in detail 132 in [INFOCOM-99]. 134 In order to avoid this problem, RFC 1122 [RFC1122] (in Section 135 4.2.2.13) states that when a connection request is received with a 136 four-tuple that is in the TIME-WAIT state, the connection request 137 could be accepted if the sequence number of the incoming SYN segment 138 is greater than the last sequence number seen on the previous 139 incarnation of the connection (for that direction of the data 140 transfer). This requirement aims at avoiding the sequence number 141 space of the new and old incarnations of the connection to overlap, 142 thus avoiding old segments from the previous incarnation of the 143 connection to be accepted as valid by the new connection. 145 The same policy may be extrapolated to TCP timestamps. That is, when 146 a connection request is received with a four-tuple that is in the 147 TIME-WAIT state, the connection request could be accepted if the 148 timestamp of the incoming SYN segment is greater than the last 149 timestamp seen on the previous incarnation of the connection (for 150 that direction of the data transfer). 152 The following paragraphs summarize the processing of SYN segments 153 received for connections in the TIME-WAIT state. The processing of 154 SYN segments received for connections in all other states is 155 unchanged. Both the ISN (Initial Sequence Number) and the timestamps 156 option (if present) of the incoming SYN segment are included in the 157 heuristics performed for allowing a high connection-establishment 158 rate. 160 Processing of SYN segments received for connections in the TIME-WAIT 161 state SHOULD occur as follows: 163 o If the previous incarnation of the connection used timestamps, 164 then, 166 * If TCP timestamps would be enabled for the new incarnation of 167 the connection, and the timestamp contained in the incoming SYN 168 segment is greater than the last timestamp seen on the previous 169 incarnation of the connection (for that direction of the data 170 transfer), honour the connection request (creating a connection 171 in the SYN-RECEIVED state). 173 * If TCP timestamps would be enabled for the new incarnation of 174 the connection, the timestamp contained in the incoming SYN 175 segment is equal to the last timestamp seen on the previous 176 incarnation of the connection (for that direction of the data 177 transfer), and the Sequence Number of the incoming SYN segment 178 is greater than the last sequence number seen on the previous 179 incarnation of the connection (for that direction of the data 180 transfer), honour the connection request (creating a connection 181 in the SYN-RECEIVED state). 183 * If TCP timestamps would not be enabled for the new incarnation 184 of the connection, but the Sequence Number of the incoming SYN 185 segment is greater than the last sequence number seen on the 186 previous incarnation of the connection (for the same direction 187 of the data transfer), honour the connection request (creating 188 a connection in the SYN-RECEIVED state). 190 * Otherwise, silently drop the incoming SYN segment, thus leaving 191 the previous incarnation of the connection in the TIME-WAIT 192 state. 194 o If the previous incarnation of the connection did not use 195 timestamps, then, 197 * If TCP timestamps would be enabled for the new incarnation of 198 the connection, honour the incoming connection request 199 (creating a connection in the SYN-RECEIVED state). 201 * If TCP timestamps would not be enabled for the new incarnation 202 of the connection, but the Sequence Number of the incoming SYN 203 segment is greater than the last sequence number seen on the 204 previous incarnation of the connection (for the same direction 205 of the data transfer), honour the incoming connection request 206 (creating a connection in the SYN-RECEIVED state). 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 kilobytes/second 240 could lead to scenarios in which the last sequence number seen on a 241 connection that moves into the TIME-WAIT state is still greater than 242 the sequence number of an incoming SYN segment that aims at creating 243 a new incarnation of the same connection. In those scenarios, the 244 4.4BSD heuristics would fail, and therefore the connection request 245 would 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 may 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 ISNs across connections 315 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. 337 [CPNI-TCP] contains a detailed discussion of the security 338 implications of TCP timestamps and of different Timestamps generation 339 algorithms. 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, Francis Dupont, Wesley Eddy, Lars Eggert, Alfred 349 Hoenes, John Heffner, Christian Huitema, Eric Rescorla, Joe Touch, 350 and Alexander Zimmermann for providing valuable feedback on an 351 earlier version of 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 421 A.1. Connection request after system reboot 423 This section clarifies how this algorithm would operate in case a 424 computer reboots, keeps the same IP address, looses memory of the 425 previous timestamps, and then tries to reestablish a previous 426 connection. 428 Firstly, as specified in [RFC0793], hosts must not establish new 429 connections for a period of 2*MSL (Maximum Segment Lifetime) after 430 they boot (this is the "quiet time" concept). As a result, specs- 431 wise, this scenario should never occur. 433 If a host does not comply with the "quiet time concept", a connection 434 request might be sent to a remote host while there is a previous 435 incarnation of the same connection in the TIME-WAIT state at the 436 remote host. In such a scenario, as a result of having lost memory 437 of previous time stamps, the resulting timestamps might not be 438 monotonically-increasing, and hence the proposed algorithm might be 439 unable to recycle the previous incarnation of the connection that is 440 in the TIME-WAIT state. This case corresponds to the current state- 441 of-affairs without the algorithm proposed in this document. 443 Appendix B. Changes from previous versions of the draft (to be removed 444 by the RFC Editor before publishing this document as an 445 RFC) 447 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-02 449 o Addresses COMMENTs received during IESG review, and maybe Tim 450 Polk's DISCUSS. 452 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-01 454 o Addresses AD-review comments by Lars Eggert. 456 B.3. Changes from draft-ietf-tcpm-tcp-timestamps-00 458 o Addresses WG Last call comments received from Wesley Eddy, John 459 Heffner and Joe Touch. 461 o Minor editorial fix (reported by Wes Eddy). 463 B.4. Changes from draft-gont-tcpm-tcp-timestamps-04 465 o Draft resubmitted as draft-ietf. 467 B.5. Changes from draft-gont-tcpm-tcp-timestamps-03 469 o Changed the document title 471 o Removed all the text related to the algorithm earlier proposed for 472 timestamps generation. 474 o Addresses comments received from Alexander Zimmermann, Christian 475 Huitema, Joe Touch, and others. 477 B.6. Changes from draft-gont-tcpm-tcp-timestamps-02 479 o Minor edits (the I-D was just about to expire, so it was 480 resubmitted with almost no changes). 482 B.7. Changes from draft-gont-tcpm-tcp-timestamps-01 484 o Version -01 of the draft had expired, and hence the I-D is 485 resubmitted to make it available again (no changes). 487 B.8. Changes from draft-gont-tcpm-tcp-timestamps-00 489 o Fixed author's affiliation. 491 o Addressed feedback submitted by Alfred Hoenes (see: 492 http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), 493 plus nits sent by Alfred off-list. 495 Author's Address 497 Fernando Gont 498 UK Centre for the Protection of National Infrastructure 500 Email: fernando@gont.com.ar 501 URI: http://www.cpni.gov.uk