idnits 2.17.1 draft-ietf-tcpm-tcp-uto-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 22, 2009) is 5565 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 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-02 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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) Nokia 4 Internet-Draft F. Gont 5 Intended status: Standards Track UTN/FRH 6 Expires: July 26, 2009 January 22, 2009 8 TCP User Timeout Option 9 draft-ietf-tcpm-tcp-uto-11 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 26, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The TCP user timeout controls how long transmitted data may remain 49 unacknowledged before a connection is forcefully closed. It is a 50 local, per-connection parameter. This document specifies a new TCP 51 option - the TCP User Timeout Option - that allows one end of a TCP 52 connection to advertise its current user timeout value. This 53 information provides advice to the other end of the TCP connection to 54 adapt its user timeout accordingly. Increasing the user timeouts on 55 both ends of a TCP connection allows it to survive extended periods 56 without end-to-end connectivity. Decreasing the user timeouts allows 57 busy servers to explicitly notify their clients that they will 58 maintain the connection state only for a short time without 59 connectivity. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 67 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 68 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 69 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10 70 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 71 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 73 5. Programming and Manageability Considerations . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Appendix A. Document Revision History . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 The Transmission Control Protocol (TCP) specification [RFC0793] 86 defines a local, per-connection "user timeout" parameter that 87 specifies the maximum amount of time that transmitted data may remain 88 unacknowledged before TCP will forcefully close the corresponding 89 connection. Applications can set and change this parameter with OPEN 90 and SEND calls. If an end-to-end connectivity disruption lasts 91 longer than the user timeout, a sender will receive no 92 acknowledgments for any transmission attempt, including keep-alives, 93 and it will close the TCP connection when the user timeout occurs. 95 This document specifies a new TCP option - the TCP User Timeout 96 Option - that allows one end of a TCP connection to advertise its 97 current user timeout value. This information provides advice to the 98 other end of the connection to adapt its user timeout accordingly. 99 That is, TCP remains free to disregard the advice provided by the UTO 100 option if local policies suggest it to be appropriate. 102 Increasing the user timeouts on both ends of a TCP connection allows 103 it to survive extended periods without end-to-end connectivity. 104 Decreasing the user timeouts allows busy servers to explicitly notify 105 their clients that they will maintain the connection state only for a 106 short time without connectivity. 108 In the absence of an application-specified user timeout, the TCP 109 specification [RFC0793] defines a default user timeout of 5 minutes. 110 The Host Requirements RFC [RFC1122] refines this definition by 111 introducing two thresholds, R1 and R2 (R2 > R1), that control the 112 number of retransmission attempts for a single segment. It suggests 113 that TCP should notify applications when R1 is reached for a segment, 114 and close the connection when R2 is reached. [RFC1122] also defines 115 the recommended values for R1 (three retransmissions) and R2 (100 116 seconds), noting that R2 for SYN segments should be at least 3 117 minutes. Instead of a single user timeout, some TCP implementations 118 offer finer-grained policies. For example, Solaris supports 119 different timeouts depending on whether a TCP connection is in the 120 SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. 122 Although some TCP implementations allow applications to set their 123 local user timeout, TCP has no in-protocol mechanism to signal 124 changes to the local user timeout to the other end of a connection. 125 This causes local changes to be ineffective in allowing a connection 126 to survive extended periods without connectivity, because the other 127 end will still close the connection after its user timeout expires. 129 The ability to inform the other end of a connection about the local 130 user timeout can improve TCP operation in scenarios that are 131 currently not well supported. One example of such a scenario is 132 mobile hosts that change network attachment points. Such hosts, 133 maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer 134 mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently 135 connected to the Internet. In between connected periods, mobile 136 hosts may experience periods without end-to-end connectivity. Other 137 factors that can cause transient connectivity disruptions are high 138 levels of congestion or link or routing failures inside the network. 139 In these scenarios, a host may not know exactly when or for how long 140 connectivity disruptions will occur, but it might be able to 141 determine an increased likelihood for such events based on past 142 mobility patterns and thus benefit from using longer user timeouts. 143 In other scenarios, the time and duration of a connectivity 144 disruption may even be predictable. For example, a node in space 145 might experience connectivity disruptions due to line-of-sight 146 blocking by planetary bodies. The timing of these events may be 147 computable from orbital mechanics. 149 2. Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Operation 157 Use of the TCP User Timeout Option can be enabled either on a per- 158 connection basis, e.g., through an API option, or controlled by a 159 system-wide setting. TCP maintains four per-connection state 160 variables to control the operation of the UTO option, three of which 161 (ADV_UTO, ENABLED and CHANGEABLE) are new: 163 USER_TIMEOUT 164 TCP's USER TIMEOUT parameter, as specified in [RFC0793]. 166 ADV_UTO 167 UTO option advertised to the remote TCP peer. This is an 168 application-specified value, and may be specified on a system-wide 169 basis. If unspecified, it defaults to the default system-wide 170 USER TIMEOUT. 172 ENABLED (Boolean) 173 Flag that controls whether the UTO option is enabled for a 174 connection. This flag applies to both sending and receiving. 175 Defaults to false. 177 CHANGEABLE (Boolean) 178 Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT 179 parameter) may be changed based on an UTO option received from the 180 other end of the connection. Defaults to true and becomes false 181 when an application explicitly sets USER_TIMEOUT. 183 Note that an exchange of UTO options between both ends of a 184 connection is not a binding negotiation. Transmission of a UTO 185 option is a suggestion that the other end consider adapting its user 186 timeout. This adaptation only happens if the other end of the 187 connection has explicitly allowed it (both ENABLED and CHANGEABLE are 188 true). 190 Before opening a connection, an application that wishes to use the 191 UTO option enables its use by setting ENABLED to true. It may choose 192 an appropriate local UTO by explicitly setting ADV_UTO; otherwise, 193 UTO is set to the default USER TIMEOUT value. Finally, the 194 application should determine whether it will allow the local USER 195 TIMEOUT to change based on received UTO options from the other end of 196 a connection. The default is to allow this for connections that do 197 not have specific user timeout concerns. If an application 198 explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to 199 prevent UTO options from the other end to override local application 200 requests. Alternatively, applications can set or clear CHANGEABLE 201 directly through API calls. 203 Performing these steps before an active or passive open causes UTO 204 options to be exchanged in the SYN and SYN-ACK packets and is a 205 reliable way to initially exchange, and potentially adapt to, UTO 206 values. TCP implementations MAY provide system-wide default settings 207 for the ENABLED, ADV_UTO and CHANGEABLE connection parameters. 209 In addition to exchanging UTO options in the SYN segments, a 210 connection that has enabled UTO options SHOULD include a UTO option 211 in the first packet that does not have the SYN flag set. This helps 212 to minimize the amount of state information TCP must keep for 213 connections in non-synchronized states, and is particularly useful 214 when mechanisms such as "SYN cookies" [RFC4987] are implemented, 215 allowing a newly-established TCP connection to benefit from the 216 information advertised by the UTO option, even if the UTO contained 217 in the initial SYN segment was not recorded. 219 A host that supports the UTO option SHOULD include one in the next 220 possible outgoing segment whenever it starts using a new user timeout 221 for the connection. This allows the other end of the connection to 222 adapt its local user timeout accordingly. A TCP implementation that 223 does not support the UTO option MUST silently ignore it [RFC1122], 224 thus ensuring interoperability. 226 Hosts MUST impose upper and lower limits on the user timeouts they 227 use for a connection. Section 3.1 discusses user timeout limits and 228 potentially problematic effects of some user timeout settings. 230 Finally, it is worth noting that TCP's option space is limited to 40 231 bytes. As a result, if other TCP options are in use, they may 232 already consume all the available TCP option space, thus preventing 233 the use of the UTO option specified in this document. Therefore, TCP 234 option space issues should be considered before enabling the UTO 235 option. 237 3.1. Changing the Local User Timeout 239 When a host receives a TCP User Timeout Option, it must decide 240 whether to change the local user timeout of the corresponding 241 connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT 242 be changed, regardless of the received UTO option. Without this 243 restriction, the UTO option would modify TCP semantics, because an 244 application-requested USER TIMEOUT could be overridden by peer 245 requests. In this case TCP SHOULD, however, notify the application 246 about the user timeout value received from the other end system. 248 In general, unless the application on the local host has requested a 249 specific USER TIMEOUT for the connection, CHANGEABLE will be true and 250 hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in 251 response to receiving a UTO option, as described in the remainder of 252 this section. 254 The UTO option specifies the user timeout in seconds or minutes, 255 rather than in number of retransmissions or round-trip times (RTTs). 256 Thus, the UTO option allows hosts to exchange user timeout values 257 from 1 second to over 9 hours at a granularity of seconds, and from 1 258 minute to over 22 days at a granularity of minutes. 260 Very short USER TIMEOUT values can affect TCP transmissions over 261 high-delay paths. If the user timeout occurs before an 262 acknowledgment for an outstanding segment arrives, possibly due to 263 packet loss, the connection closes. Many TCP implementations default 264 to USER TIMEOUT values of a few minutes. Although the UTO option 265 allows suggestion of short timeouts, applications advertising them 266 should consider these effects. 268 Long USER TIMEOUT values allow hosts to tolerate extended periods 269 without end-to-end connectivity. However, they also require hosts to 270 maintain the TCP state information associated with connections for 271 long periods of time. Section 6 discusses the security implications 272 of long timeout values. 274 To protect against these effects, implementations MUST impose limits 275 on the user timeout values they accept and use. The remainder of 276 this section describes a RECOMMENDED scheme to limit TCP's USER 277 TIMEOUT based on upper and lower limits. 279 Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end 280 SHOULD compute the local USER TIMEOUT for a connection according to 281 this formula: 283 USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT)) 285 Each field is to be interpreted as follows: 287 USER_TIMEOUT 288 USER TIMEOUT value to be adopted by the local TCP for this 289 connection. 291 U_LIMIT 292 Current upper limit imposed on the user timeout of a connection by 293 the local host. 295 ADV_UTO 296 User timeout advertised to the remote TCP peer in a TCP User 297 Timeout Option. 299 REMOTE_UTO 300 Last user timeout value received from the other end in a TCP User 301 Timeout Option. 303 L_LIMIT 304 Current lower limit imposed on the user timeout of a connection by 305 the local host. 307 The RECOMMENDED formula results in the maximum of the two advertised 308 values, adjusted for the configured upper and lower limits, to be 309 adopted for the user timeout of the connection on both ends. The 310 rationale is that choosing the maximum of the two values will let the 311 connection survive longer periods without end-to-end connectivity. 312 If the end that announced the lower of the two user timeout values 313 did so in order to reduce the amount of TCP state information that 314 must be kept on the host, it can close or abort the connection 315 whenever it wants. 317 It must be noted that the two endpoints of the connection will not 318 necessarily adopt the same user timeout. 320 Enforcing a lower limit (L_LIMIT) prevents connections from closing 321 due to transient network conditions, including temporary congestion, 322 mobility hand-offs and routing instabilities. 324 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 325 attacks. Section 6 discusses the details of these attacks. 327 Note that these limits MAY be specified as system-wide constants or 328 at other granularities, such as on per-host, per-user, per-outgoing- 329 interface or even per-connection basis. Furthermore, these limits 330 need not be static. For example, they MAY be a function of system 331 resource utilization or attack status and could be dynamically 332 adapted. 334 The Host Requirements RFC [RFC1122] does not impose any limits on the 335 length of the user timeout. However, it recommends a time interval 336 of at least 100 seconds. Consequently, the lower limit (L_LIMIT) 337 SHOULD be set to at least 100 seconds when following the RECOMMENDED 338 scheme described in this section. Adopting a user timeout smaller 339 than the current retransmission timeout (RTO) for the connection 340 would likely cause the connection to be aborted unnecessarily. 341 Therefore, the lower limit (L_LIMIT) MUST be larger than the current 342 retransmission timeout (RTO) for the connection. It is worth noting 343 that an upper limit may be imposed on the RTO, provided it is at 344 least 60 seconds [RFC2988]. 346 3.2. UTO Option Reliability 348 The TCP User Timeout Option is an advisory TCP option that does not 349 change processing of subsequent segments. Unlike other TCP options, 350 it need not be exchanged reliably. Consequently, the specification 351 does not define a reliability handshake for UTO option exchanges. 352 When a segment that carries a UTO option is lost, the other end will 353 simply not have the opportunity to update its local UTO. 355 Implementations MAY implement local mechanisms to improve delivery 356 reliability, such as retransmitting a UTO option when they retransmit 357 a segment that originally carried it, or "attaching" the option to a 358 byte in the stream and retransmitting the option whenever that byte 359 or its ACK are retransmitted. 361 It is important to note that although these mechanisms can improve 362 transmission reliability for the UTO option, they do not guarantee 363 delivery (a three-way handshake would be required for this). 364 Consequently, implementations MUST NOT assume that UTO options are 365 transmitted reliably. 367 3.3. Option Format 369 Sending a TCP User Timeout Option informs the other end of the 370 connection of the current local user timeout and suggests that the 371 other end adapt its user timeout accordingly. The user timeout value 372 included in a UTO option contains the ADV_UTO value, that is expected 373 to be adopted for the TCP's USER TIMEOUT parameter during the 374 synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN- 375 WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other 376 states MUST use the default timeout values defined in [RFC0793] and 377 [RFC1122]. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Kind = TBD | Length = 4 |G| User Timeout | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 (One tick mark represents one bit.) 387 Figure 1: Format of the TCP User Timeout Option 389 Figure 1 shows the format of the TCP User Timeout Option. It 390 contains these fields: 392 Kind (8 bits) 393 This MUST be TBD, i.e., the TCP option number [RFC0793] assigned 394 by IANA upon publication of this document (see Section 7). [[Note 395 to the RFC Editor: Throughout this document, replace "TBD" with 396 the TCP option number that IANA has allocated and remove this 397 note.]] 399 Length (8 bits) 400 Length of the TCP option in octets [RFC0793]; its value MUST be 4. 402 Granularity (1 bit) 403 Granularity bit, indicating the granularity of the "User Timeout" 404 field. When set (G = 1), the time interval in the "User Timeout" 405 field MUST be interpreted as minutes. Otherwise (G = 0), the time 406 interval in the "User Timeout" field MUST be interpreted as 407 seconds. 409 User Timeout (15 bits) 410 Specifies the user timeout suggestion for this connection. It 411 MUST be interpreted as a 15-bit unsigned integer. The granularity 412 of the timeout (minutes or seconds) depends on the "G" field. 414 3.4. Reserved Option Values 416 An TCP User Timeout Option with a "User Timeout" field of zero and a 417 "Granularity" bit of either minutes (1) or seconds (0) is reserved 418 for future use. Current TCP implementations MUST NOT send it and 419 MUST ignore it upon reception. 421 4. Interoperability Issues 423 This section discusses interoperability issues related to introducing 424 the TCP User Timeout Option. 426 4.1. Middleboxes 428 A TCP implementation that does not support the TCP User Timeout 429 Option MUST silently ignore it [RFC1122], thus ensuring 430 interoperability. In a study of the effects of middleboxes on 431 transport protocols, Medina et al. have shown that the vast majority 432 of modern TCP stacks correctly handle unknown TCP options [MEDINA]. 433 In this study, 3% of connections failed when an unknown TCP option 434 appeared in the middle of a connection. Because the number of 435 failures caused by unknown options is small and they are a result of 436 incorrectly implemented TCP stacks that violate existing requirements 437 to ignore unknown options, they do not warrant special measures. 438 Thus, this document does not define a mechanism to negotiate support 439 of the TCP User Timeout Option during the three-way handshake. 441 Stateful firewalls usually time out connection state after a period 442 of inactivity. If such a firewall exists along the path, it may 443 close or abort connections regardless of the use of the TCP User 444 Timeout Option. In the future, such firewalls may learn to parse the 445 TCP User Timeout Option in unencrypted TCP segments and adapt 446 connection state management accordingly. 448 4.2. TCP Keep-Alives 450 Some TCP implementations, such as those in BSD systems, use a 451 different abort policy for TCP keep-alives than for user data. Thus, 452 the TCP keep-alive mechanism might abort a connection that would 453 otherwise have survived the transient period without connectivity. 454 Therefore, if a connection that enables keep-alives is also using the 455 TCP User Timeout Option, then the keep-alive timer MUST be set to a 456 value larger than that of the adopted USER TIMEOUT. 458 5. Programming and Manageability Considerations 460 The IETF specification for TCP [RFC0793] includes a simple, abstract 461 application programming interface (API). The API for the UTO 462 extension in Section 3 is kept similarly abstract. TCP 463 implementations, however, usually provide more complex and feature- 464 rich APIs. The "socket" API that originated with BSD Unix and is now 465 standardized by POSIX is one such example [POSIX]. It is expected 466 that TCP implementations that choose to include the UTO extension 467 will extend their API to allow applications to use and configure its 468 parameters. 470 The MIB objects defined in [RFC4022] and [RFC4898] allow management 471 of TCP connections. It is expected that revisions to these documents 472 will include definitions of objects for managing the UTO extension 473 defined in this document. 475 6. Security Considerations 477 Lengthening user timeouts has obvious security implications. 478 Flooding attacks cause denial of service by forcing servers to commit 479 resources for maintaining the state of throw-away connections. 480 However, TCP implementations do not become more vulnerable to simple 481 SYN flooding by implementing the TCP User Timeout Option, because 482 user timeouts exchanged during the handshake only affect the 483 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 484 CLOSING, LAST-ACK), which simple SYN floods never reach. 486 However, when an attacker completes the three-way handshakes of its 487 throw-away connections it can amplify the effects of resource 488 exhaustion attacks, because the attacked server must maintain the 489 connection state associated with the throw-away connections for 490 longer durations. Because connection state is kept longer, lower- 491 frequency attack traffic, which may be more difficult to detect, can 492 already exacerbate resource exhaustion. 494 Several approaches can help mitigate this issue. First, 495 implementations can require prior peer authentication, e.g., using 496 IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user 497 timeouts for the peer's connections. (Implementors that decide to 498 use TCP-MD5 for this purpose are encouraged to monitor the 499 development of TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], its designated 500 successor, and update their implementation when it is published as an 501 RFC.) A similar approach is for a host to start accepting long user 502 timeouts for an established connection only after in-band 503 authentication has occurred, for example, after a TLS handshake 504 across the connection has succeeded [RFC5246]. Although these are 505 arguably the most complete solutions, they depend on external 506 mechanisms to establish a trust relationship. 508 A second alternative that does not depend on external mechanisms 509 would introduce a per-peer limit on the number of connections that 510 may use increased user timeouts. Several variants of this approach 511 are possible, such as fixed limits or shortening accepted user 512 timeouts with a rising number of connections. Although this 513 alternative does not eliminate resource exhaustion attacks from a 514 single peer, it can limit their effects. Reducing the number of 515 high-UTO connections a server supports in the face of an attack turns 516 that attack into a denial-of-service attack against the service of 517 high-UTO connections. 519 Per-peer limits cannot protect against distributed denial of service 520 attacks, where multiple clients coordinate a resource exhaustion 521 attack that uses long user timeouts. To protect against such 522 attacks, TCP implementations could reduce the duration of accepted 523 user timeouts with increasing resource utilization. 525 TCP implementations under attack may be forced to shed load by 526 resetting established connections. Some load-shedding heuristics, 527 such as resetting connections with long idle times first, can 528 negatively affect service for intermittently connected, trusted peers 529 that have suggested long user timeouts. On the other hand, resetting 530 connections to untrusted peers that use long user timeouts may be 531 effective. In general, using the peers' level of trust as a 532 parameter during the load-shedding decision process may be useful. 533 Note that if TCP needs to close or abort connections with a long TCP 534 User Timeout Option to shed load, these connections are still no 535 worse off than without the option. 537 Finally, upper and lower limits on user timeouts, discussed in 538 Section 3.1, can be an effective tool to limit the impact of these 539 sorts of attacks. 541 7. IANA Considerations 543 This section is to be interpreted according to [RFC5226]. 545 This document does not define any new namespaces. It requests that 546 IANA allocate a new 8-bit TCP option number for the UTO option from 547 the registry maintained at 548 http://www.iana.org/assignments/tcp-parameters. 550 8. Acknowledgments 552 The following people have improved this document through thoughtful 553 suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, 554 Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade 555 Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, 556 Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, 557 Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha 558 Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and 559 Martin Stiemerling. 561 Lars Eggert is partly funded by [TRILOGY], a research project 562 supported by the European Commission under its Seventh Framework 563 Program. 565 9. References 567 9.1. Normative References 569 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 570 RFC 793, September 1981. 572 [RFC1122] Braden, R., "Requirements for Internet Hosts - 573 Communication Layers", STD 3, RFC 1122, October 1989. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 579 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 580 May 2008. 582 9.2. Informative References 584 [I-D.eddy-tcp-mobility] 585 Eddy, W., "Mobility Support For TCP", 586 draft-eddy-tcp-mobility-00 (work in progress), April 2004. 588 [I-D.ietf-tcpm-tcp-auth-opt] 589 Touch, J., Mankin, A., and R. Bonica, "The TCP 590 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02 591 (work in progress), November 2008. 593 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 594 Interactions Between Transport Protocols and Middleboxes", 595 Proc. 4th ACM SIGCOMM/USENIX Conference on Internet 596 Measurement , October 2004. 598 [POSIX] IEEE Std. 1003.1-2001, "Standard for Information 599 Technology - Portable Operating System Interface (POSIX)", 600 Open Group Technical Standard: Base Specifications Issue 601 6, ISO/IEC 9945:2002, December 2001. 603 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 604 Signature Option", RFC 2385, August 1998. 606 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 607 Timer", RFC 2988, November 2000. 609 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 610 August 2002. 612 [RFC4022] Raghunarayan, R., "Management Information Base for the 613 Transmission Control Protocol (TCP)", RFC 4022, 614 March 2005. 616 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 617 Internet Protocol", RFC 4301, December 2005. 619 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 620 (HIP) Architecture", RFC 4423, May 2006. 622 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 623 Extended Statistics MIB", RFC 4898, May 2007. 625 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 626 Mitigations", RFC 4987, August 2007. 628 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 629 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 631 [SOLARIS-MANUAL] 632 Sun Microsystems, "Solaris Tunable Parameters Reference 633 Manual", Part No. 806-7009-10, 2002. 635 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 637 Appendix A. Document Revision History 639 [[Note to the RFC Editor: Section to be removed upon publication.]] 640 +----------+--------------------------------------------------------+ 641 | Revision | Comments | 642 +----------+--------------------------------------------------------+ 643 | -11 | Addressing IESG review comments. | 644 | | | 645 | -10 | Addressing the gen-art review comments from Scott | 646 | | Brim. Updated reference to [RFC5246]. Added funding | 647 | | source acknowledgment. | 648 | | | 649 | -09 | Resubmission after expiration. Updated reference to | 650 | | [RFC5226]. | 651 | | | 652 | -08 | Addressed additional, minor working group last call | 653 | | comments. | 654 | | | 655 | -07 | Addressed working group last call comments. | 656 | | | 657 | -06 | Includes a note on the limited space for TCP options | 658 | | and miscellaneous editorial changes (suggested by | 659 | | Anantha Ramaiah). Includes possible enforcement of | 660 | | per-outgoing-interface limits for the UTO, and | 661 | | miscellaneous editorial changes (suggested by Alfred | 662 | | Hoenes). Includes relevant changes to reflect WG | 663 | | consensus how the local user timeout should be | 664 | | selected (i.e., record both the current user timeout, | 665 | | and the advertised UTO). | 666 | | | 667 | -05 | Made behavior on when to change/not change the local | 668 | | UTO in response to incoming options consistent through | 669 | | the document. This required some reshuffling of text | 670 | | and also removed the need for the special "don't care" | 671 | | option value. | 672 | | | 673 | -04 | Clarified the results obtained by Medina et al. Added | 674 | | text to suggest inclusion of the UTO in the first | 675 | | non-SYN segment by the TCP that sent a SYN in response | 676 | | to an active OPEN. | 677 | | | 678 | -03 | Corrected use of RFC2119 terminology. Clarified how | 679 | | use of the TCP UTO is triggered. Clarified reason for | 680 | | sending a UTO in the SYN and SYN/ACK segments. | 681 | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | 682 | | socket options. Removed text that suggested that a | 683 | | UTO should be sent upon receipt of an UTO from the | 684 | | other end. Required minimum value for the lower limit | 685 | | of the user timeout. Moved alternative solutions to | 686 | | appendix. Miscellaneous editorial changes. | 687 | | | 688 | -02 | Corrected terminology by replacing terms like | 689 | | "negotiate", "coordinate", etc. that were left from | 690 | | pre-WG-document times when the UTO was a more | 691 | | formalized exchange instead of the advisory one it is | 692 | | now. Application-requested UTOs take precedence over | 693 | | ones received from the peer (pointed out by Ted | 694 | | Faber). Added a brief mention of SO_SNDTIMEO and a | 695 | | slightly longer discussion of SO_RCVTIMEO. | 696 | | | 697 | -01 | Clarified and corrected the description of the | 698 | | existing user timeout in RFC793 and RFC1122. Removed | 699 | | distinction between operating during the 3WHS and the | 700 | | established states and introduced zero-second "don't | 701 | | care" UTOs in response to mailing list feedback. | 702 | | Updated references and addressed many other comments | 703 | | from the mailing list. | 704 | | | 705 | -00 | Resubmission of | 706 | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | 707 | | secretariat after WG adoption. Thus, permit | 708 | | derivative works. Updated Lars Eggert's funding | 709 | | attribution. Updated several references. No | 710 | | technical changes. | 711 +----------+--------------------------------------------------------+ 713 Authors' Addresses 715 Lars Eggert 716 Nokia Research Center 717 P.O. Box 407 718 Nokia Group 00045 719 Finland 721 Phone: +358 50 48 24461 722 Email: lars.eggert@nokia.com 723 URI: http://research.nokia.com/people/lars_eggert/ 724 Fernando Gont 725 Universidad Tecnologica Nacional / Facultad Regional Haedo 726 Evaristo Carriego 2644 727 Haedo, Provincia de Buenos Aires 1706 728 Argentina 730 Phone: +54 11 4650 8472 731 Email: fernando@gont.com.ar 732 URI: http://www.gont.com.ar/