idnits 2.17.1 draft-ietf-tcpm-tcp-uto-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2006) is 6491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor L. Eggert 3 Extensions (tcpm) NEC 4 Internet-Draft F. Gont 5 Expires: January 20, 2007 UTN/FRH 6 July 19, 2006 8 TCP User Timeout Option 9 draft-ietf-tcpm-tcp-uto-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 20, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies a new TCP option - the TCP User Timeout 43 Option - that allows a TCP to advertise its current user timeout for 44 a connection. Thus, the remote TCP may modify its local user timeout 45 based on knowledge of the peer's user timeout. The TCP user timeout 46 controls how long transmitted data may remain unacknowledged before a 47 connection is forcefully closed. It is a local, per-connection 48 parameter. Increasing the user timeouts allows established TCP 49 connections to survive extended periods of disconnection. Decreasing 50 the user timeouts allows busy servers to explicitly notify their 51 clients that they will maintain the connection state only across 52 short periods of disconnection. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 60 3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8 61 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 63 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9 64 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 73 Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 13 74 Appendix B. Document Revision History . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 The Transmission Control Protocol (TCP) specification 81 [RFC0793]defines a local, per-connection "user timeout" parameter 82 that specifies the maximum amount of time that transmitted data may 83 remain unacknowledged before TCP will forcefully close the 84 corresponding connection. Applications can set and change this 85 parameter with OPEN and SEND calls. If a network disconnection lasts 86 longer than the user timeout, no acknowledgments will be received for 87 any transmission attempt, including keep-alives [TCP-ILLU], and the 88 TCP connection will close when the user timeout occurs. In the 89 absence of an application-specified user timeout, the TCP 90 specification [RFC0793] defines a default user timeout of 5 minutes. 92 The Host Requirements RFC [RFC1122] refines this definition by 93 introducing two thresholds, R1 and R2 (R2 > R1), on the number of 94 retransmissions of a single segment. It suggests that TCP should 95 notify applications when R1 is reached for a segment, and close the 96 connection once R2 is reached. [RFC1122] also defines the 97 recommended values for R1 (three retransmissions) and R2 (100 98 seconds), noting that R2 for SYN segments should be at least 3 99 minutes. Instead of a single user timeout, some TCP implementations 100 offer finer-grained policies. For example, Solaris supports 101 different timeouts depending on whether a TCP connection is in the 102 SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. 104 Although some TCP implementations allow applications to set their 105 local user timeout, there is no in-protocol mechanism to signal 106 changes in the local user timeout to remote peers. This causes local 107 changes to be ineffective, because the peer will still close the 108 connection after its user timeout expires, even when the host has 109 raised its local user timeout. The ability to suggest the remote 110 peer a user timeout to be used for the connection can improve TCP's 111 operation in scenarios that are currently not well supported. One 112 example of such scenarios are mobile hosts that change network 113 attachment points based on current location. Such hosts, maybe using 114 MobileIP [RFC3344], HIP [RFC4423]or transport-layer mobility 115 mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected 116 to the Internet. In between connected periods, mobile hosts may 117 experience periods of disconnection during which no network service 118 is available. Other factors that can cause transient periods of 119 disconnection are high levels of congestion as well as link or 120 routing failures inside the network. 122 In scenarios similar to the ones described above, a host may not know 123 exactly when or for how long it will be disconnected from the 124 network, but it might expect such events due to past mobility 125 patterns and thus benefit from using longer user timeouts. In other 126 scenarios, the length and time of a network disconnection may even be 127 predictable. For example, an orbiting node on a non-geostationary 128 satellite might experience disconnections due to line-of-sight 129 blocking by other planetary bodies. The disconnection periods of 130 such a node may be easily computable from orbital mechanics. 132 This document specifies a new TCP option - the User Timeout Option 133 (UTO) - that allows a TCP to advertise its current local user timeout 134 parameter. Thus, based on the information advertised by the remote 135 TCP peer, a TCP may modify its own user timeout accordingly. This 136 allows, for example, mobile hosts to maintain TCP connections across 137 disconnected periods that are longer than their peer's default user 138 timeout. A second use of the TCP User Timeout Option is 139 advertisement of shorter-than-default user timeouts. This can allow 140 busy servers to explicitly notify their clients that they will 141 maintain the state associated with established connections only 142 across short periods of disconnection. 144 Use of the TCP User Timeout Option could be triggered either by an 145 API call or by a system-wide toggle. The API could be, for example, 146 a Socket option that would need to be explicitly set by the 147 corresponding application. This option would default to "off". A 148 system-wide toggle would allow a system administrator to enable the 149 use of the TCP User Timeout Option on a system-wide basis, and set 150 the option a desired value. This system-wide toggle would allow the 151 use of the option by application programs that have not been 152 explicitly coded to do so. If such a system-wide toggle were 153 provided, it would default to "off". 155 In all cases, use of the TCP User Timeout Option would depend on an 156 active decision, either by the application programmer (by means of an 157 API call), or by a system administrator (by means of a system-wide 158 toggle). 160 2. Conventions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. Operation 168 Sending a TCP User Timeout Option informs the remote peer of the 169 current local user timeout for the connection, and suggests the TCP 170 peer to adapt its user timeout accordingly. The user timeout value 171 included in a TCP User Timeout Option specifies the requested user 172 timeout during the synchronized states of a connection (ESTABLISHED, 173 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). 174 Connections in other states MUST the default timeout values defined 175 in [RFC0793] [RFC1122]. 177 Note that an exchange of TCP User Timeout Options between peers is 178 not a binding negotiation. Transmission of a TCP User Timeout Option 179 is an advisory suggestion that the peer consider adapting its local 180 user timeout. Hosts remain free to adopt a different user timeout, 181 or to forcefully close or abort connections at any time for any 182 reason, whether or not they use custom user timeouts or have 183 suggested the peer to use them. 185 A host that supports the TCP User Timeout Option SHOULD include one 186 in each packet that carries a SYN flag, but need not. [MEDINA] has 187 shown that unknown options are correctly handled by the vast majority 188 of modern TCP stacks. It is thus not necessary to require 189 negotiation of the use of the TCP User Timeout Option during the 190 three-way handshake of a connection. However, including a TCP User 191 Timeout Option in each segment that has the SYN flag set will result 192 in TCP being able to adopt a user timeout with knowledge of that used 193 by the peer TCP, since the beginning of the data transfer phase. 195 A host that supports the TCP User Timeout Option SHOULD include it in 196 the next possible segment to its peer whenever it starts using a new 197 user timeout for the connection. This allows the peer to adapt its 198 local user timeout for the connection accordingly. 200 When a host that supports the TCP User Timeout Option receives one, 201 it will use the received value to compute the local user timeout for 202 the connection. Generally, hosts should honor requests for changes 203 to the user timeout (see Section 3.1), unless security concerns, 204 resource constraints or external policies indicate otherwise (see 205 Section 5). If so, hosts may use a different user timeout for the 206 connection. 208 A TCP implementation that does not support the TCP User Timeout 209 Option MUST silently ignore it [RFC1122], thus ensuring 210 interoperability. 212 Hosts MUST impose upper and lower limits on the user timeouts they 213 use. Section 3.1 discusses user timeout limits, and describes a 214 RECOMMENDED scheme to apply them. A TCP User Timeout Option with a 215 value of zero (i.e., "now") is nonsensical and is used for a special 216 purpose, see Section 3.4. Section 3.1 discusses potentially 217 problematic effects of other user timeout durations. 219 3.1. Changing the Local User Timeout 221 When a host receives a TCP User Timeout Option, it must decide 222 whether to change the local user timeout of the corresponding 223 connection. Application-requested user timeout values always take 224 precedence over timeout values received from the peer in a TCP User 225 Timeout Option. [anchor3] Consequently, unless the application on the 226 local host has requested a specific user timeout for the connection, 227 e.g., through the OPEN or SEND calls, hosts SHOULD adjust their local 228 user timeout in response to receiving a TCP User Timeout Option, as 229 described in the remainder of this section. If the local application 230 has requested a specific local user timeout, TCP implementations MUST 231 NOT change it in response to receiving a TCP User Timeout Option. In 232 this case, they SHOULD, however, notify the application about the 233 user timeout value received from the peer. 235 The User Timeout Option specifies the user timeout in terms of time 236 units, rather than in terms of number of retransmissions or round- 237 trip times (RTTs), as in most cases the periods of disconnection have 238 to do with operation and mobility patterns, rather than with the 239 current network conditions. Thus, the TCP User Timeout Option allows 240 hosts to exchange user timeout values from 1 second to over 9 hours 241 at a granularity of seconds, and from 1 minute to over 22 days at a 242 granularity of minutes. (An option value of zero is reserved for a 243 special purpose, see Section 3.4.) 245 Very short user timeout values can affect TCP transmissions over 246 high-delay paths. If the user timeout occurs before an 247 acknowledgment for an outstanding segment arrives, possibly due to 248 packet loss, the connection closes. Many TCP implementations default 249 to user timeout values of a few minutes [TCP-ILLU]. Although the TCP 250 User Timeout Option allows suggestion of short timeouts, applications 251 advertising them should consider these effects. 253 Long user timeout values allow hosts to tolerate extended periods of 254 disconnection. However, they also require hosts to maintain the TCP 255 state information associated with connections for long periods of 256 time. Section 5 discusses the security implications of long timeout 257 values. 259 To protect against these effects, implementations MUST impose limits 260 on the user timeout values they accept and use. The remainder of 261 this section describes a RECOMMENDED scheme to limit user timeouts 262 based on upper and lower limits. Under the RECOMMENDED scheme, each 263 TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection 264 according to this formula: 266 USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) 267 Each field is to be interpreted as follows: 269 USER_TIMEOUT 270 Resulting user timeout value to be adopted by the local TCP for a 271 connection. 273 U_LIMIT 274 Current upper limit imposed on the user timeout of a connection by 275 the local host. 277 L_LIMIT 278 Current lower limit imposed on the user timeout of a connection by 279 the local host. 281 LOCAL_UTO 282 Current local user timeout of this specific connection. 284 REMOTE_UTO 285 Last "user timeout" value suggested by the remote peer by means of 286 the TCP User Timeout Option. 288 This means that, provided they are within the upper and lower limits, 289 the maximum of the two announced values will be adopted for the user 290 timeout of the connection. The rationale is that choosing the 291 maximum of the two values will let the connection survive longer 292 periods of disconnection. If the TCP that announced the lower of the 293 two user timeout values did so in order to reduce the amount of TCP 294 state information that must be kept on the host, it can, 295 nevertheless, close or abort the connection whenever it wants. 297 It must be noted that the two endpoints of the connection will not 298 necesarilly adopt the same user timeout. 300 Enforcing a lower limit (L_LIMIT) prevents connections from closing 301 due to transient network conditions, including temporary congestion, 302 mobility hand-offs and routing instabilities. 304 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 305 attacks. Section 5discusses the details of these attacks. 307 Note that these limits MAY be specified as system-wide constants or 308 at other granularities, such as on per-host, per-user or even per- 309 connection basis. Furthermore, these limits need not be static. For 310 example, they MAY be a function of system resource utilization or 311 attack status and could be dynamically adapted. 313 The Host Requirements RFC [RFC1122] does not impose any limits on the 314 length of the user timeout. However, a time interval of at least 100 315 seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) 316 SHOULD be set to at least 100 seconds when following the RECOMMENDED 317 scheme described in this section. Adopting a user timeout smaller 318 than the current retransmission timeout (RTO) for the connection 319 would likely cause the connection to be aborted unnecesarily. 320 Therefore, the lower limit (L_LIMIT) MUST be larger than the current 321 retransmission timeout (RTO) for the connection. 323 3.2. Reliability Considerations 325 The TCP User Timeout Option is an advisory TCP option that does not 326 change processing of subsequent segments. Unlike other TCP options, 327 it need not be exchanged reliably. Consequently, the specification 328 in this section does not define a reliability handshake for TCP User 329 Timeout Option exchanges. When a segment that carries a TCP User 330 Timeout Option is lost, the option may never reach the intended peer. 332 Implementations MAY implement local mechanisms to improve delivery 333 reliability, such as retransmitting the TCP User Timeout Option when 334 they retransmit the segment that originally carried it, or 335 "attaching" the option to a byte in the stream and retransmitting the 336 option whenever that byte or its ACK are retransmitted. 338 It is important to note that although these mechanisms can improve 339 transmission reliability for the TCP User Timeout Option, they do not 340 guarantee delivery (a three-way handshake would be required for 341 this). Consequently, implementations should not assume that a TCP 342 User Timeout Option is reliably transmitted. 344 3.3. Option Format 346 0 1 2 3 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Kind = X | Length = 4 |G| User Timeout | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 (One tick mark represents one bit.) 354 Figure 1: Format of the TCP User Timeout Option 356 Figure 1 shows the format of the TCP User Timeout Option. It 357 contains these fields: 359 Kind (8 bits) 360 A TCP option number [RFC0793] to be assigned by IANA upon 361 publication of this document (see Section 6). 363 Length (8 bits) 364 Length of the TCP option in octets [RFC0793]; its value MUST be 4. 366 Granularity (1 bit) 367 Granularity bit, indicating the granularity of the "User Timeout" 368 field. When set (G = 1), the time interval in the "User Timeout" 369 field MUST be interpreted as minutes. Otherwise (G = 0), the time 370 interval in the "User Timeout" field MUST be interpreted as 371 seconds. 373 User Timeout (15 bits) 374 Specifies the user timeout suggestion for this connection. It 375 MUST be interpreted as a 15-bit unsigned integer. The granularity 376 of the timeout (minutes or seconds) depends on the "G" field. 378 3.4. Special Option Values 380 Whenever it is legal to do so according to the specification in the 381 previous sections, TCP implementations MAY send a zero-second TCP 382 User Timeout Option, i.e, with a "User Timeout" field of zero and a 383 "Granularity" of zero. This signals their peers that they support 384 the option, but do not suggest a specific user timeout value at that 385 time. Essentially, a zero-second TCP User Timeout Option acts as a 386 "don't care" value. 388 Thus, the sender SHOULD adapt its local user timeout according to the 389 peer's UTO, and the receiver SHOULD continue using its local user 390 timeout. In order to achieve this, the receiver of a zero-second TCP 391 User Timeout Option SHOULD perform the RECOMMENDED strategy for 392 calculating a new local USER_TIMEOUT described in Section 3.1, with a 393 numeric value of zero seconds for REMOTE_UTO. The sender SHOULD 394 perform the same calculation as described in Section 3.1, with a 395 numeric value of zero seconds for LOCAL_UTO. 397 A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" 398 field of zero and a "Granularity" bit of one, is reserved for future 399 use. TCP implementations MUST NOT send it and MUST ignore it upon 400 reception. 402 4. Interoperability Issues 404 This section discusses interoperability issues related to introducing 405 the TCP User Timeout Option. 407 4.1. Middleboxes 409 The large number of middleboxes (firewalls, proxies, protocol 410 scrubbers, etc.) currently present in the Internet pose some 411 difficulty for deploying new TCP options. Some firewalls may block 412 segments that carry unknown options, preventing connection 413 establishment when the SYN or SYN-ACK segment contain a TCP User 414 Timeout Option. Some recent results, however, indicate that for new 415 TCP options, this may not be a significant threat, with only 0.2% of 416 web requests failing when carrying an unknown option [MEDINA]. 418 Stateful firewalls usually reset connections after a period of 419 inactivity. If such a firewall exists along the path between two 420 peers, it may close or abort connections regardless of the use of the 421 TCP User Timeout Option. In the future, such firewalls may learn to 422 parse the TCP User Timeout Option and modify their behavior or the 423 option accordingly. 425 4.2. TCP Keep-Alives 427 Some TCP implementations, such as the one in BSD systems, use a 428 different abort policy for TCP keep-alives than for user data. Thus, 429 the TCP keep-alive mechanism might abort a connection that would 430 otherwise have survived the transient period of disconnection. 431 Therefore, if a TCP peer enables TCP keep-alives for a connection 432 that is using the TCP User Timeout Option, then the keep-alive timer 433 MUST be set to a value larger than that of the adopted USER TIMEOUT. 435 5. Security Considerations 437 Lengthening user timeouts has obvious security implications. 438 Flooding attacks cause denial of service by forcing servers to commit 439 resources for maintaining the state of throw-away connections. 440 However, TCP implementations do not become more vulnerable to simple 441 SYN flooding by implementing the TCP User Timeout Option, because 442 user timeouts exchanged during the handshake only affect the 443 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 444 CLOSING, LAST-ACK), which simple SYN floods never reach. 446 However, when an attacker completes the three-way handshakes of its 447 throw-away connections it can amplify the effects of resource 448 exhaustion attacks, because the attacked server must maintain the 449 connection state associated with the throw-away connections for 450 longer durations. Because connection state is kept longer, lower- 451 frequency attack traffic, which may be more difficult to detect, can 452 already cause resource exhaustion. 454 Several approaches can help mitigate this issue. First, 455 implementations can require prior peer authentication, e.g., using 456 IPsec [RFC4301], before accepting long user timeouts for the peer's 457 connections. Similarly, a host can start to accept long user 458 timeouts for an established connection only after in-band 459 authentication has occurred, for example, after a TLS handshake 460 across the connection has succeeded [RFC2246]. Although these are 461 arguably the most complete solutions, they depend on external 462 mechanisms to establish a trust relationship. 464 A second alternative that does not depend on external mechanisms 465 would introduce a per-peer limit on the number of connections that 466 may use increased user timeouts. Several variants of this approach 467 are possible, such as fixed limits or shortening accepted user 468 timeouts with a rising number of connections. Although this 469 alternative does not eliminate resource exhaustion attacks from a 470 single peer, it can limit their effects. Reducing the number of 471 high-UTO connections a server supports in the face of an attack turns 472 that attack into a denial-of-service attack against the service of 473 high-UTO connections. 475 Per-peer limits cannot protect against distributed denial of service 476 attacks, where multiple clients coordinate a resource exhaustion 477 attack that uses long user timeouts. To protect against such 478 attacks, TCP implementations could reduce the duration of accepted 479 user timeouts with increasing resource utilization. 481 TCP implementations under attack may be forced to shed load by 482 resetting established connections. Some load-shedding heuristics, 483 such as resetting connections with long idle times first, can 484 negatively affect service for intermittently connected, trusted peers 485 that have suggested long user timeouts. On the other hand, resetting 486 connections to untrusted peers that use long user timeouts may be 487 effective. In general, using the peers' level of trust as a 488 parameter during the load-shedding decision process may be useful. 489 Note that if TCP needs to close or abort connections with a long TCP 490 User Timeout Option to shed load, these connections are still no 491 worse off than without the option. 493 Finally, upper and lower limits on user timeouts, discussed in 494 Section 3.1, can be an effective tool to limit the impact of these 495 sorts of attacks. 497 6. IANA Considerations 499 This section is to be interpreted according to [RFC2434]. 501 This document does not define any new namespaces. It uses an 8-bit 502 TCP option number maintained by IANA at 503 http://www.iana.org/assignments/tcp-parameters. 505 7. Acknowledgments 507 The following people have improved this document through thoughtful 508 suggestions: Mark Allman, David Borman, Bob Braden, Marcus Brunner, 509 Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, 510 Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Phil 511 Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, Juergen 512 Quittek, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and 513 Martin Stiemerling. 515 Lars Eggert is partly funded by Ambient Networks, a research project 516 supported by the European Commission under its Sixth Framework 517 Program. The views and conclusions contained herein are those of the 518 authors and should not be interpreted as necessarily representing the 519 official policies or endorsements, either expressed or implied, of 520 the Ambient Networks project or the European Commission. 522 8. References 524 8.1. Normative References 526 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 527 RFC 793, September 1981. 529 [RFC1122] Braden, R., "Requirements for Internet Hosts - 530 Communication Layers", STD 3, RFC 1122, October 1989. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 536 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 537 October 1998. 539 8.2. Informative References 541 [I-D.eddy-tcp-mobility] 542 Eddy, W., "Mobility Support For TCP", 543 draft-eddy-tcp-mobility-00 (work in progress), April 2004. 545 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 546 Interactions Between Transport Protocols and Middleboxes", 547 Proc. 4th ACM SIGCOMM/USENIX Conference on Internet 548 Measurement , October 2004. 550 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 551 RFC 2246, January 1999. 553 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 554 August 2002. 556 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 557 Internet Protocol", RFC 4301, December 2005. 559 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 560 (HIP) Architecture", RFC 4423, May 2006. 562 [SOLARIS-MANUAL] 563 Sun Microsystems, "Solaris Tunable Parameters Reference 564 Manual", Part No. 806-7009-10, 2002. 566 [TCP-ILLU] 567 Stevens, W., "TCP/IP Illustrated, Volume 1: The 568 Protocols", Addison-Wesley , 1994. 570 Editorial Comments 572 [anchor3] Without this, UTO would modify TCP semantics, because 573 application-requested UTOs could be overridden by peer 574 requests. 576 Appendix A. Alternative solutions 578 The same benefits could be obtained through an application-layer 579 mechanism, i.e., exchanging user timeout information via application 580 messages and having the application adjust the user timeouts through 581 the TCP API on both sides of a connection. This approach would not 582 require a new TCP option, but would require changing all application 583 implementations that desire to tolerate extended periods of 584 disconnection, and in most cases would also require a modification to 585 the corresponding application layer protocol. With the proposed TCP 586 option, application changes may not be necessary at all, or may be 587 restricted to sender- or receiver-side only, and there is no need to 588 modify the corresponding application protocol. 590 A different approach to tolerate longer periods of disconnection 591 would be to simply increase the system-wide user timeout on both 592 peers. This approach has the benefit of not requiring a new TCP 593 option or application changes. However, it can also significantly 594 increase the amount of connection state a busy server must maintain, 595 because a longer global timeout value would apply to all its 596 connections. 598 The proposed TCP User Timeout Option, on the other hand, allows hosts 599 to selectively manage the user timeouts of individual connections, 600 reducing the amount of state they must maintain across disconnected 601 periods. 603 Appendix B. Document Revision History 605 To be removed upon publication 607 +----------+--------------------------------------------------------+ 608 | Revision | Comments | 609 +----------+--------------------------------------------------------+ 610 | 03 | Corrected use of RFC2119 terminology. Clarified how | 611 | | use of the TCP UTO is triggered. Clarified reason for | 612 | | sending a UTO in the SYN and SYN/ACK segments. | 613 | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | 614 | | options. Removed text that suggested that a UTO | 615 | | should be sent upon receipt of an UTO from the remote | 616 | | peer. Required minimum value for the lower limit of | 617 | | the user timeout. Moved alternative solutions to | 618 | | appendix. Miscellaneous editorial changes. | 619 | 02 | Corrected terminology by replacing terms like | 620 | | "negotiate", "coordinate", etc. that were left from | 621 | | pre-WG-document times when the UTO was a more | 622 | | formalized exchange instead of the advisory one it is | 623 | | now. Application-requested UTOs take precedence over | 624 | | ones received from the peer (pointed out by Ted | 625 | | Faber). Added a brief mention of SO_SNDTIMEO and a | 626 | | slightly longer discussion of SO_RCVTIMEO. | 627 | 01 | Clarified and corrected the description of the | 628 | | existing user timeout in RFC793 and RFC1122. Removed | 629 | | distinction between operating during the 3WHS and the | 630 | | established states and introduced zero-second "don't | 631 | | care" UTOs in response to mailing list feedback. | 632 | | Updated references and addressed many other comments | 633 | | from the mailing list. | 634 | 00 | Resubmission of | 635 | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | 636 | | secretariat after WG adoption. Thus, permit | 637 | | derivative works. Updated Lars Eggert's funding | 638 | | attribution. Updated several references. No | 639 | | technical changes. | 640 +----------+--------------------------------------------------------+ 642 Authors' Addresses 644 Lars Eggert 645 NEC Network Laboratories 646 Kurfuerstenanlage 36 647 Heidelberg 69115 648 Germany 650 Phone: +49 6221 90511 43 651 Fax: +49 6221 90511 55 652 Email: lars.eggert@netlab.nec.de 653 URI: http://www.netlab.nec.de/ 655 Fernando Gont 656 Universidad Tecnologica Nacional 657 Evaristo Carriego 2644 658 Haedo, Provincia de Buenos Aires 1706 659 Argentina 661 Phone: +54 11 4650 8472 662 Email: fernando@gont.com.ar 663 URI: http://www.gont.com.ar/ 665 Intellectual Property Statement 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Disclaimer of Validity 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Copyright Statement 701 Copyright (C) The Internet Society (2006). This document is subject 702 to the rights, licenses and restrictions contained in BCP 78, and 703 except as set forth therein, the authors retain all their rights. 705 Acknowledgment 707 Funding for the RFC Editor function is currently provided by the 708 Internet Society.