idnits 2.17.1 draft-ietf-tcpm-tcp-uto-02.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 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. ** 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 (October 24, 2005) is 6757 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) == Unused Reference: 'I-D.eddy-tcp-mobility' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-hip-arch' is defined on line 577, but no explicit reference was found in the text ** 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) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: April 27, 2006 UTN/FRH 6 October 24, 2005 8 TCP User Timeout Option 9 draft-ietf-tcpm-tcp-uto-02 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 April 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The TCP user timeout controls how long transmitted data may remain 43 unacknowledged before a connection is forcefully closed. It is a 44 local, per-connection parameter. The advisory TCP User Timeout 45 Option allows conforming TCP implementations to exchange their local 46 user timeouts. This is an in-protocol mechanism to allow a host to 47 modify its local user timeout for a connection based on knowledge of 48 the peer's user timeout. Increasing the user timeouts allows 49 established TCP connections to survive extended periods of 50 disconnection. Decreasing user timeouts allows busy servers to 51 explicitly notify their clients that they will maintain the 52 connection state only across short periods of disconnection. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Additional Considerations . . . . . . . . . . . . . . . . . . 9 64 5. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 65 5.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 74 Appendix A. Document Revision History . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 Intellectual Property and Copyright Statements . . . . . . . . . . 17 78 1. Introduction 80 The Transmission Control Protocol (TCP) specification [RFC0793] 81 defines a local, per-connection "user timeout" parameter that 82 specifies the maximum amount of time that transmitted data may remain 83 unacknowledged before TCP will forcefully close the corresponding 84 connection. Applications can set and change this parameter with OPEN 85 and SEND calls. If a network disconnection lasts longer than the 86 user timeout, no acknowledgments will be received for any 87 transmission attempt, including keep-alives [TCP-ILLU], and the TCP 88 connection will close when the user timeout occurs. In the absence 89 of an application-specified user timeout, the TCP specification 90 [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, e.g., through the SO_SNDTIMEO socket option, 106 there is no in-protocol mechanism to signal changes in the local user 107 timeout to remote peers. This causes local changes to be 108 ineffective, because the peer will still close the connection after 109 its user timeout expires, even when a host has raised its local user 110 timeout. The ability to modify the two user timeouts associated with 111 a connection can improve TCP operation in scenarios that are 112 currently not well supported. One example of such scenarios are 113 mobile hosts that change network attachment points based on current 114 location. Such hosts, maybe using MobileIP [RFC3344], HIP [I-D.ietf- 115 hip-arch] or transport-layer mobility mechanisms [I-D.eddy-tcp- 116 mobility], are only intermittently connected to the Internet. In 117 between connected periods, mobile hosts may experience periods of 118 disconnection during which no network service is available [SCHUETZ- 119 THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other factors that can cause 120 transient periods of disconnection are high levels of congestion as 121 well as link or routing failures inside the network. 123 In scenarios similar to the ones described above, a host may not know 124 exactly when or for how long it will be disconnected from the 125 network, but it might expect such events due to past mobility 126 patterns and thus benefit from using longer user timeouts. In other 127 scenarios, the length and time of a network disconnection may even be 128 predictable. For example, an orbiting node on a satellite might 129 experience disconnections due to line-of-sight blocking by other 130 planetary bodies. The disconnection periods of such a node may be 131 easily computable from orbital mechanics. 133 This document specifies a new TCP option - the User Timeout Option 134 (UTO) - that allows conforming hosts to exchange their local, per- 135 connection user timeout information. This allows, for example, 136 mobile hosts to maintain TCP connections across disconnected periods 137 that are longer than their peer's default user timeout. A second use 138 of the TCP User Timeout Option is advertisement of shorter-than- 139 default user timeouts. This can allow busy servers to explicitly 140 notify their clients that they will maintain the state associated 141 with established connections only across short periods of 142 disconnection. 144 The same benefits can be obtained through an application-layer 145 mechanism, i.e., exchanging user timeout information via application 146 messages and having the application adjust the user timeouts through 147 the TCP API on both sides of a connection. This approach does not 148 require a new TCP option, but requires changing all application 149 implementations that desire to tolerate extended periods of 150 disconnection, and in most cases also requires a modification to the 151 corresponding application layer protocol. With the proposed TCP 152 option, application changes may not be necessary at all, or may be 153 restricted to sender- or receiver-side only, and there is no need to 154 modify the corresponding application protocol. 156 A different approach to tolerate longer periods of disconnection is 157 to simply increase the system-wide user timeout on both peers. This 158 approach has the benefit of not requiring a new TCP option or 159 application changes. However, it can also significantly increase the 160 amount of connection state a busy server must maintain, because a 161 longer global timeout value will apply to all its connections. The 162 proposed TCP User Timeout Option, on the other hand, allows hosts to 163 selectively manage the user timeouts of individual connections, 164 reducing the amount of state they must maintain across disconnected 165 periods. 167 2. Conventions 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 3. Operation 175 Sending a TCP User Timeout Option informs the remote peer of the 176 current local user timeout and suggests that the remote peer SHOULD 177 start using the indicated user timeout value for the corresponding 178 connection. The user timeout value included in a TCP User Timeout 179 Option specifies the requested user timeout during the synchronized 180 states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE- 181 WAIT, CLOSING, or LAST-ACK). Connections in other states MUST the 182 default timeout values defined in [RFC0793][RFC1122].[anchor3] 184 Note that an exchange of TCP User Timeout Options between peers is 185 not a binding negotiation. Transmission of a TCP User Timeout Option 186 is an advisory suggestion that the peer consider adapting its local 187 user timeout. Hosts remain free to forcefully close or abort 188 connections at any time for any reason, whether or not they use 189 custom user timeouts or have suggested the peer to use them. 191 A host that supports the TCP User Timeout Option SHOULD include one 192 in each packet that carries a SYN flag, but need not. [MEDINA] has 193 shown that unknown options are correctly handled by the vast majority 194 of modern TCP stacks. It is thus not necessary to require 195 negotiation of the use of the TCP User Timeout Option during the 196 three-way handshake of a connection. 198 A host that supports the TCP User Timeout Option SHOULD include it in 199 the next possible segment to its peer whenever it starts using a new 200 user timeout for the connection. This allows the peer to adapt its 201 local user timeout for the connection accordingly. 203 When a host that supports the TCP User Timeout Option receives one, 204 it decides whether to change its local user timeout of the connection 205 based on the received value. Generally, hosts should honor requests 206 for changes to the user timeout (see Section 3.1), unless security 207 concerns, resource constraints or external policies indicate 208 otherwise (see Section 6). If so, hosts may ignore incoming TCP User 209 Timeout Options and use a different user timeout for the connection. 211 When a host receives a TCP User Timeout Option, it first decides 212 whether to change its local user timeout for the connection - 213 Section 3.1 discusses the specifics of this choice - and then decides 214 whether to send a TCP User Timeout Option to its peer in response. 215 If a host has never sent a TCP User Timeout Option to its peer during 216 the lifetime of the connection, or if it has changed its local user 217 timeout, it SHOULD send TCP User Timeout Option with its current 218 local user timeout to its peer. [anchor4] 220 A TCP implementation that does not support the TCP User Timeout 221 Option MUST silently ignore it [RFC1122], thus ensuring 222 interoperability. 224 Hosts SHOULD impose upper and lower limits on the user timeouts they 225 use. Section 3.1 discusses user timeout limits, and describes a 226 recommended scheme to apply them. A TCP User Timeout Option with a 227 value of zero (i.e., "now") is nonsensical and is used for a special 228 purpose, see Section 3.4. Section 3.1 discusses potentially 229 problematic effects of other user timeout durations. 231 3.1. Changing the Local User Timeout 233 When a host receives a TCP User Timeout Option, it MUST decide 234 whether to change the local user timeout of the corresponding 235 connection. Application-requested user timeout values always take 236 precedence over timeout values received from the peer in a TCP User 237 Timeout Option. [anchor5] Consequently, unless the application on the 238 local host has requested a specific user timeout for the connection, 239 e.g., through a socket API call, hosts SHOULD adjust their local user 240 timeout in response to receiving a TCP User Timeout Option, as 241 described in the remainder of this section. If the local application 242 has requested a specific local user timeout, TCP implementations MUST 243 NOT change it in response to receiving a TCP User Timeout Option. In 244 this case, they SHOULD, however, notify the application about the 245 user timeout value received from the peer. 247 The User Timeout Option specifies the user timeout in terms of time 248 units, rather than in terms of number of retransmissions or round- 249 trip times (RTTs), as in most cases the periods of disconnection have 250 to do with operation and mobility patterns, rather than with the 251 current network conditions [anchor6][anchor7]. Thus, the TCP User 252 Timeout Option allows hosts to exchange user timeout values from 1 253 second to over 9 hours at a granularity of seconds, and from 1 minute 254 to over 22 days at a granularity of minutes. (An option value of 255 zero is reserved for a special purpose, see Section 3.4.) 257 Very short user timeout values can affect TCP transmissions over 258 high-delay paths. If the user timeout occurs before an 259 acknowledgment for an outstanding segment arrives, possibly due to 260 packet loss, the connection closes. Many TCP implementations default 261 to user timeout values of a few minutes [TCP-ILLU]. Although the TCP 262 User Timeout Option allows suggestion of short timeouts, applications 263 advertising them SHOULD consider these effects. 265 Long user timeout values allow hosts to tolerate extended periods of 266 disconnection. However, they also require hosts to maintain the TCP 267 state information associated with connections for long periods of 268 time. Section 6 discusses the security implications of long timeout 269 values. 271 To protect against these effects, implementations SHOULD impose 272 limits on the user timeout values they accept and use. The remainder 273 of this section describes a RECOMMENDED scheme to limit user timeouts 274 based on upper and lower limits. Under the RECOMMENDED scheme, each 275 TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection 276 according to this formula: 278 USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) 280 Each field is to be interpreted as follows: 282 USER_TIMEOUT 283 Resulting user timeout value to be adopted by the local TCP for a 284 connection. 286 U_LIMIT 287 Current upper limit imposed on the user timeout of a connection by 288 the local host. 290 L_LIMIT 291 Current lower limit imposed on the user timeout of a connection by 292 the local host. 294 LOCAL_UTO 295 Current local user timeout of this specific connection. 297 REMOTE_UTO 298 Last "user timeout" value suggested by the remote peer by means of 299 the TCP User Timeout Option. 301 This means that the maximum of the two announced values will be 302 adopted for the user timeout of the connection. The rationale is 303 that choosing the maximum of the two values will let the connection 304 survive longer periods of disconnection. If the TCP that announced 305 the lower of the two user timeout values did so in order to reduce 306 the amount of TCP state information that must be kept on the host, it 307 can, nevertheless, close or abort the connection whenever it wants. 309 Enforcing a lower limit (L_LIMIT) prevents connections from closing 310 due to transient network conditions, including temporary congestion, 311 mobility hand-offs and routing instabilities. 313 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 314 attacks. Section 6 discusses the details of these attacks. 316 Note that these limits MAY be specified as system-wide constants or 317 at other granularities, such as on per-host, per-user or even per- 318 connection basis. Furthermore, these limits need not be static. For 319 example, they MAY be a function of system resource utilization or 320 attack status and could be dynamically adapted. 322 The Host Requirements RFC [RFC1122] does not impose any limits on the 323 length of the user timeout. However, a time interval of at least 100 324 seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) 325 SHOULD be set to at least 100 seconds when following the RECOMMENDED 326 scheme described in this section. 328 3.2. Reliability Considerations 330 The TCP User Timeout Option is an advisory TCP option that does not 331 change processing of subsequent segments. Unlike other TCP options, 332 it need not be exchanged reliably. Consequently, the specification 333 in this section does not define a reliability handshake for TCP User 334 Timeout Option exchanges. When a segment that carries a TCP User 335 Timeout Option is lost, the option may never reach the intended peer. 337 Implementations MAY implement local mechanisms to improve delivery 338 reliability, such as retransmitting the TCP User Timeout Option when 339 they retransmit the segment that originally carried it, or 340 "attaching" the option to a byte in the stream and retransmitting the 341 option whenever that byte or its ACK are retransmitted. 343 It is important to note that although these mechanisms can improve 344 transmission reliability for the TCP User Timeout Option, they do not 345 guarantee delivery (a three-way handshake would be required for 346 this). Consequently, implementations MUST NOT assume that a TCP User 347 Timeout Option is reliably transmitted. 349 3.3. Option Format 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Kind = X | Length = 4 |G| User Timeout | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 (One tick mark represents one bit.) 359 Figure 1: Format of the TCP User Timeout Option 361 Figure 1 shows the format of the TCP User Timeout Option. It 362 contains these fields: 364 Kind (8 bits) 365 A TCP option number [RFC0793] to be assigned by IANA upon 366 publication of this document (see Section 7). 368 Length (8 bits) 369 Length of the TCP option in octets [RFC0793]; its value MUST be 4. 371 Granularity (1 bit) 372 Granularity bit, indicating the granularity of the "User Timeout" 373 field. When set (G = 1), the time interval in the "User Timeout" 374 field MUST be interpreted as minutes. Otherwise (G = 0), the time 375 interval in the "User Timeout" field MUST be interpreted as 376 seconds. 378 User Timeout (15 bits) 379 Specifies the user timeout suggestion for this connection. It 380 MUST be interpreted as a 15-bit unsigned integer. The granularity 381 of the timeout (minutes or seconds) depends on the "G" field. 383 3.4. Special Option Values 385 Whenever it is legal to do so according to the specification in the 386 previous sections, TCP implementations MAY send a zero-second TCP 387 User Timeout Option, i.e, with a "User Timeout" field of zero and a 388 "Granularity" of zero. This signals their peers that they support 389 the option, but do not suggest a specific user timeout value at that 390 time. Essentially, a zero-second TCP User Timeout Option acts as a 391 "don't care" value. 393 Thus, the sender SHOULD adapt its local user timeout according to the 394 peer's UTO, and the receiver SHOULD continue using its local user 395 timeout. In order to achieve this, the receiver of a zero-second TCP 396 User Timeout Option SHOULD perform the RECOMMENDED strategy for 397 calculating a new local USER_TIMEOUT described in Section 3.1, with a 398 numeric value of zero seconds for REMOTE_UTO. The sender SHOULD 399 perform the same calculation as described in Section 3.1, with a 400 numeric value of zero seconds for LOCAL_UTO. 402 A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" 403 field of zero and a "Granularity" bit of one, is reserved for future 404 use. TCP implementations MUST NOT send it and MUST ignore it upon 405 reception. 407 4. Additional Considerations 409 Section 1 described that although [RFC0793] defines the API mechanism 410 to change the user timeout as an optional parameter for TCP's OPEN 411 and SEND calls, many implementations provide a different API. 412 Several popular TCP implementations offer the SO_SNDTIMEO socket 413 option, either in addition or instead of the RFC-defined OPEN and 414 SEND user timeout parameter. 416 Many implementations that offer the SO_SNDTIMEO socket option also 417 implement a corresponding SO_RCVTIMEO socket option. Whereas the 418 user timout (SO_SNDTIMEO), specifies how long data may remain 419 unacknowledged by the peer, i.e., how long a SEND call may take, the 420 SO_RCVTIMEO specifies how long a RECV call may take. 422 Even when two TCPs implement the TCP User Timeout Option and decide 423 to lengthen their local UTOs for a connection, RECV operations during 424 a disconnection can trigger the SO_RCVTIMEO timeout. Note that 425 [RFC0793] does not specify this receive timeout or how TCP reacts 426 when it occurs. If implementations close a connection when its 427 SO_RCVTIMEO times out, they SHOULD modify this parameter similarly to 428 how they modify SO_SNDTIMEO upon reception of a TCP User Timeout 429 option. [anchor10] 431 5. Interoperability Issues 433 This section discusses interoperability issues related to introducing 434 the TCP User Timeout Option. 436 5.1. Middleboxes 438 The large number of middleboxes (firewalls, proxies, protocol 439 scrubbers, etc.) currently present in the Internet pose some 440 difficulty for deploying new TCP options. Some firewalls may block 441 segments that carry unknown options, preventing connection 442 establishment when the SYN or SYN-ACK contains a TCP User Timeout 443 Option. Some recent results, however, indicate that for new TCP 444 options, this may not be a significant threat, with only 0.2% of web 445 requests failing when carrying an unknown option [MEDINA]. 447 Stateful firewalls usually reset connections after a period of 448 inactivity. If such a firewall exists along the path between two 449 peers, it may close or abort connections regardless of the use of the 450 TCP User Timeout Option. In the future, such firewalls may learn to 451 parse the TCP User Timeout Option and modify their behavior or the 452 option accordingly. 454 5.2. TCP Keep-Alives 456 Some TCP implementations, such as the one in BSD systems, use a 457 different abort policy for TCP keep-alives than for user data. Thus, 458 the TCP keep-alive mechanism might abort a connection that would 459 otherwise have survived the transient period of disconnection. 460 Therefore, if a TCP peer enables TCP keep-alives for a connection 461 that is using the TCP User Timeout Option, then the keep-alive timer 462 MUST be set to a value larger than that of the adopted USER TIMEOUT. 464 6. Security Considerations 466 Lengthening user timeouts has obvious security implications. 467 Flooding attacks cause denial of service by forcing servers to commit 468 resources for maintaining the state of throw-away connections. 469 However, TCP implementations do not become more vulnerable to simple 470 SYN flooding by implementing the TCP User Timeout Option, because 471 user timeouts exchanged during the handshake only affect the 472 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 473 CLOSING, LAST-ACK), which simple SYN floods never reach. 475 However, when an attacker completes the three-way handshakes of its 476 throw-away connections it can amplify the effects of resource 477 exhaustion attacks, because the attacked server must maintain the 478 connection state associated with the throw-away connections for 479 longer durations. Because connection state is kept longer, lower- 480 frequency attack traffic, which may be more difficult to detect, can 481 already cause resource exhaustion. 483 Several approaches can help mitigate this issue. First, 484 implementations can require prior peer authentication, e.g., using 485 IPsec [I-D.ietf-ipsec-rfc2401bis], before accepting long user 486 timeouts for the peer's connections. Similarly, a host can start to 487 accept long user timeouts for an established connection only after 488 in-band authentication has occurred, for example, after a TLS 489 handshake across the connection has succeeded [RFC2246]. Although 490 these are arguably the most complete solutions, they depend on 491 external mechanisms to establish a trust relationship. 493 A second alternative that does not depend on external mechanisms 494 would introduce a per-peer limit on the number of connections that 495 may use increased user timeouts. Several variants of this approach 496 are possible, such as fixed limits or shortening accepted user 497 timeouts with a rising number of connections. Although this 498 alternative does not eliminate resource exhaustion attacks from a 499 single peer, it can limit their effects. Reducing the number of 500 high-UTO connections a server supports in the face of an attack turns 501 that attack into a denial-of-service attack against the service of 502 high-UTO connections. 504 Per-peer limits cannot protect against distributed denial of service 505 attacks, where multiple clients coordinate a resource exhaustion 506 attack that uses long user timeouts. To protect against such 507 attacks, TCP implementations could reduce the duration of accepted 508 user timeouts with increasing resource utilization. 510 TCP implementations under attack may be forced to shed load by 511 resetting established connections. Some load-shedding heuristics, 512 such as resetting connections with long idle times first, can 513 negatively affect service for intermittently connected, trusted peers 514 that have suggested long user timeouts. On the other hand, resetting 515 connections to untrusted peers that use long user timeouts may be 516 effective. In general, using the peers' level of trust as a 517 parameter during the load-shedding decision process may be useful. 518 Note that if TCP needs to close or abort connections with a long TCP 519 User Timeout Option to shed load, these connections are still no 520 worse off than without the option. 522 Finally, upper and lower limits on user timeouts, discussed in 523 Section 3.1, can be an effective tool to limit the impact of these 524 sorts of attacks. 526 7. IANA Considerations 528 This section is to be interpreted according to [RFC2434]. 530 This document does not define any new namespaces. It uses an 8-bit 531 TCP option number maintained by IANA at 532 http://www.iana.org/assignments/tcp-parameters. 534 8. Acknowledgments 536 The following people have improved this document through thoughtful 537 suggestions: Mark Allmann, David Borman, Bob Braden, Marcus Brunner, 538 Wesley Eddy, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom 539 Henderson, Joseph Ishac, Jeremy Harris, Phil Karn, Michael Kerrisk, 540 Dan Krejsa, Kostas Pentikousis, Juergen Quittek, Joe Touch, Stefan 541 Schmid, Simon Schuetz, Tim Shepard and Martin Stiemerling. 543 Lars Eggert is partly funded by Ambient Networks, a research project 544 supported by the European Commission under its Sixth Framework 545 Program. The views and conclusions contained herein are those of the 546 authors and should not be interpreted as necessarily representing the 547 official policies or endorsements, either expressed or implied, of 548 the Ambient Networks project or the European Commission. 550 9. References 552 9.1. Normative References 554 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 555 RFC 793, September 1981. 557 [RFC1122] Braden, R., "Requirements for Internet Hosts - 558 Communication Layers", STD 3, RFC 1122, October 1989. 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 564 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 565 October 1998. 567 9.2. Informative References 569 [DRIVE-THRU] 570 Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 571 802.11b for Automobile Users", Proc. Infocom , March 2004. 573 [I-D.eddy-tcp-mobility] 574 Eddy, W., "Mobility Support For TCP", 575 draft-eddy-tcp-mobility-00 (work in progress), April 2004. 577 [I-D.ietf-hip-arch] 578 Moskowitz, R. and P. Nikander, "Host Identity Protocol 579 Architecture", draft-ietf-hip-arch-03 (work in progress), 580 August 2005. 582 [I-D.ietf-ipsec-rfc2401bis] 583 Kent, S. and K. Seo, "Security Architecture for the 584 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 585 in progress), April 2005. 587 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 588 Interactions Between Transport Protocols and Middleboxes", 589 Proc. 4th ACM SIGCOMM/USENIX Conference on Internet 590 Measurement , October 2004. 592 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 593 RFC 2246, January 1999. 595 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 596 August 2002. 598 [SCHUETZ-CCR] 599 Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, 600 "Protocol Enhancements for Intermittently Connected 601 Hosts", To appear: ACM Computer Communication Review, Vol. 602 35, No. 3, July 2005. 604 [SCHUETZ-THESIS] 605 Schuetz, S., "Network Support for Intermittently Connected 606 Mobile Nodes", Diploma Thesis, University of Mannheim, 607 Germany, June 2004. 609 [SOLARIS-MANUAL] 610 Sun Microsystems, "Solaris Tunable Parameters Reference 611 Manual", Part No. 806-7009-10, 2002. 613 [TCP-ILLU] 614 Stevens, W., "TCP/IP Illustrated, Volume 1: The 615 Protocols", Addison-Wesley , 1994. 617 Editorial Comments 619 [anchor3] A future version of this document may extend per- 620 connection user timeouts to the SYN-SENT and SYN-RECEIVED 621 states in a way that conforms to the required minimum 622 timeouts. 624 [anchor4] Should it really always send UTO when it changes the 625 local timeout? I can imagine some ping-pong effect when 626 two hosts user different UTO adoption strategies. But 627 maybe that's OK? Additionally, when -01 was presented in 628 Paris, Joe Touch has suggested that an "UTO-ACK" should 629 be sent when a UTO is received. I have not seen consensus 630 for this on the mailing list, hence -02 does not include 631 this suggestion. 633 [anchor5] Without this, UTO would modify TCP semantics, because 634 application-requested UTOs could be overridden by peer 635 requests. 637 [anchor6] When -01 was presented in Paris, Bob Braden suggested to 638 specify the UTO in terms of multiples of the RTT. Others 639 disagreed, hence -02 does not include this suggestion. 640 One reason this may be problematic is that the RTT may 641 change for one direction of the connection, sort of 642 defeating the process of exchanging UTOs. 644 [anchor7] Let's suppose a host is intermittently connected to a 645 network, and the disconnected periods last for, say, 646 about 15 minutes each. Let's suppose the attachment 647 points range from low-bandwidth/high-delay/congested 648 networks to high-bandwidth/low-delay networks. If the UTO 649 specified the user timeout in terms of number of 650 retransmissions or round-trip times, an UTO that is 651 appropriate for the high-bandwith/low-delay networks 652 would be too small for the low-bandwidth/high-delay/ 653 congested networks. Also, even if the host kept connected 654 to the same network, if the network conditions changed, 655 UTO opions would need to be re-sent (as n*RTO and n*RTT 656 would change), unnecesarily. 658 [anchor10] Can we even say this much about an API that's not in the 659 TCP spec? Or should the SO_RCVTIMEO discussion be 660 removed? 662 Appendix A. Document Revision History 664 To be removed upon publication 666 +----------+--------------------------------------------------------+ 667 | Revision | Comments | 668 +----------+--------------------------------------------------------+ 669 | 02 | Corrected terminology by replacing terms like | 670 | | "negotiate", "coordinate", etc. that were left from | 671 | | pre-WG-document times when the UTO was a more | 672 | | formalized exchange instead of the advisory one it is | 673 | | now. Application-requested UTOs take precedence over | 674 | | ones received from the peer (pointed out by Ted | 675 | | Faber). Added a brief mention of SO_SNDTIMEO and a | 676 | | slightly longer discussion of SO_RCVTIMEO. | 677 | 01 | Clarified and corrected the description of the | 678 | | existing user timeout in RFC793 and RFC1122. Removed | 679 | | distinction between operating during the 3WHS and the | 680 | | established states and introduced zero-second "don't | 681 | | care" UTOs in response to mailing list feedback. | 682 | | Updated references and addressed many other comments | 683 | | from the mailing list. | 684 | 00 | Resubmission of | 685 | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | 686 | | secretariat after WG adoption. Thus, permit | 687 | | derivative works. Updated Lars Eggert's funding | 688 | | attribution. Updated several references. No | 689 | | technical changes. | 690 +----------+--------------------------------------------------------+ 692 Authors' Addresses 694 Lars Eggert 695 NEC Network Laboratories 696 Kurfuerstenanlage 36 697 Heidelberg 69115 698 Germany 700 Phone: +49 6221 90511 43 701 Fax: +49 6221 90511 55 702 Email: lars.eggert@netlab.nec.de 703 URI: http://www.netlab.nec.de/ 705 Fernando Gont 706 Universidad Tecnologica Nacional 707 Evaristo Carriego 2644 708 Haedo, Provincia de Buenos Aires 1706 709 Argentina 711 Phone: +54 11 4650 8472 712 Email: fernando@gont.com.ar 713 URI: http://www.gont.com.ar/ 715 Intellectual Property Statement 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org. 739 Disclaimer of Validity 741 This document and the information contained herein are provided on an 742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 744 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 745 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 746 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Copyright Statement 751 Copyright (C) The Internet Society (2005). This document is subject 752 to the rights, licenses and restrictions contained in BCP 78, and 753 except as set forth therein, the authors retain all their rights. 755 Acknowledgment 757 Funding for the RFC Editor function is currently provided by the 758 Internet Society.