idnits 2.17.1 draft-ietf-tcpm-tcp-uto-10.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, updated by RFC 4748 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 723. 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 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 (December 1, 2008) is 5597 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) -- 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 (~~), 1 warning (==), 12 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: June 4, 2009 December 1, 2008 8 TCP User Timeout Option 9 draft-ietf-tcpm-tcp-uto-10 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 June 4, 2009. 36 Abstract 38 The TCP user timeout controls how long transmitted data may remain 39 unacknowledged before a connection is forcefully closed. It is a 40 local, per-connection parameter. This document specifies a new TCP 41 option - the TCP User Timeout Option - that allows one end of a TCP 42 connection to advertise its current user timeout value. This 43 information provides advice to the other end of the TCP connection to 44 adapt its user timeout accordingly. Increasing the user timeouts on 45 both ends of a TCP connection allows it to survive extended periods 46 without end-to-end connectivity. Decreasing the user timeouts allows 47 busy servers to explicitly notify their clients that they will 48 maintain the connection state only for a short time without 49 connectivity. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 57 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 58 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 59 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10 60 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 61 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Document Revision History . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 17 73 1. Introduction 75 The Transmission Control Protocol (TCP) specification [RFC0793] 76 defines a local, per-connection "user timeout" parameter that 77 specifies the maximum amount of time that transmitted data may remain 78 unacknowledged before TCP will forcefully close the corresponding 79 connection. Applications can set and change this parameter with OPEN 80 and SEND calls. If an end-to-end connectivity disruption lasts 81 longer than the user timeout, a sender will receive no 82 acknowledgments for any transmission attempt, including keep-alives, 83 and it will close the TCP connection when the user timeout occurs. 85 This document specifies a new TCP option - the TCP User Timeout 86 Option - that allows one end of a TCP connection to advertise its 87 current user timeout value. This information provides advice to the 88 other end of the connection to adapt its user timeout accordingly. 89 That is, TCP remains free to disregard the advice provided by the UTO 90 option if local policies suggest it to be appropriate. 92 Increasing the user timeouts on both ends of a TCP connection allows 93 it to survive extended periods without end-to-end connectivity. 94 Decreasing the user timeouts allows busy servers to explicitly notify 95 their clients that they will maintain the connection state only for a 96 short time without connectivity. 98 In the absence of an application-specified user timeout, the TCP 99 specification [RFC0793] defines a default user timeout of 5 minutes. 100 The Host Requirements RFC [RFC1122] refines this definition by 101 introducing two thresholds, R1 and R2 (R2 > R1), that control the 102 number of retransmission attempts for a single segment. It suggests 103 that TCP should notify applications when R1 is reached for a segment, 104 and close the connection when R2 is reached. [RFC1122] also defines 105 the recommended values for R1 (three retransmissions) and R2 (100 106 seconds), noting that R2 for SYN segments should be at least 3 107 minutes. Instead of a single user timeout, some TCP implementations 108 offer finer-grained policies. For example, Solaris supports 109 different timeouts depending on whether a TCP connection is in the 110 SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. 112 Although some TCP implementations allow applications to set their 113 local user timeout, TCP has no in-protocol mechanism to signal 114 changes to the local user timeout to the other end of a connection. 115 This causes local changes to be ineffective in allowing a connection 116 to survive extended periods without connectivity, because the other 117 end will still close the connection after its user timeout expires. 119 The ability to inform the other end of a connection about the local 120 user timeout can improve TCP operation in scenarios that are 121 currently not well supported. One example of such a scenario is 122 mobile hosts that change network attachment points. Such hosts, 123 maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer 124 mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently 125 connected to the Internet. In between connected periods, mobile 126 hosts may experience periods without end-to-end connectivity. Other 127 factors that can cause transient connectivity disruptions are high 128 levels of congestion or link or routing failures inside the network. 129 In these scenarios, a host may not know exactly when or for how long 130 connectivity disruptions will occur, but it might be able to 131 determine an increased likelihood for such events based on past 132 mobility patterns and thus benefit from using longer user timeouts. 133 In other scenarios, the time and duration of a connectivity 134 disruption may even be predictable. For example, a node in space 135 might experience connectivity disruptions due to line-of-sight 136 blocking by planetary bodies. The timing of these events may be 137 computable from orbital mechanics. 139 2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Operation 147 Use of the TCP User Timeout Option can be enabled either on a per- 148 connection basis, e.g., through a socket option, or controlled by a 149 system-wide setting. TCP maintains four per-connection state 150 variables to control the operation of the UTO option, three of which 151 (ADV_UTO, ENABLED and CHANGEABLE) are new: 153 USER_TIMEOUT 154 TCP's USER TIMEOUT parameter, as specified in [RFC0793]. 156 ADV_UTO 157 UTO option advertised to the remote TCP peer. This is an 158 application-specified value, and may be specified on a system-wide 159 basis. If unspecified, it defaults to the default system-wide 160 USER TIMEOUT. 162 ENABLED (Boolean) 163 Flag that controls whether the UTO option is enabled for a 164 connection. This flag applies to both sending and receiving. 165 Defaults to false. 167 CHANGEABLE (Boolean) 168 Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT 169 parameter) may be changed based on an UTO option received from the 170 other end of the connection. Defaults to true and becomes false 171 when an application explicitly sets USER_TIMEOUT. 173 Note that an exchange of UTO options between both ends of a 174 connection is not a binding negotiation. Transmission of a UTO 175 option is a suggestion that the other end consider adapting its user 176 timeout. This adaptation only happens if the other end of the 177 connection has explicitly allowed it (both ENABLED and CHANGEABLE are 178 true). 180 Before opening a connection, an application that wishes to use the 181 UTO option enables its use by setting ENABLED to true. It may choose 182 an appropriate local UTO by explicitly setting ADV_UTO; otherwise, 183 UTO is set to the default USER TIMEOUT value. Finally, the 184 application should determine whether it will allow the local USER 185 TIMEOUT to change based on received UTO options from the other end of 186 a connection. The default is to allow this for connections that do 187 not have specific user timeout concerns. If an application 188 explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to 189 prevent UTO options from the other end to override local application 190 requests. Alternatively, applications can set or clear CHANGEABLE 191 directly through socket API calls. 193 Performing these steps before an active or passive open causes UTO 194 options to be exchanged in the SYN and SYN-ACK packets and is a 195 reliable way to initially exchange, and potentially adapt to, UTO 196 values. TCP implementations MAY provide system-wide default settings 197 for the ENABLED, ADV_UTO and CHANGEABLE connection parameters. 199 In addition to exchanging UTO options in the SYN segments, a 200 connection that has enabled UTO options SHOULD include a UTO option 201 in the first packet that does not have the SYN flag set. This helps 202 to minimize the amount of state information TCP must keep for 203 connections in non-synchronized states, and is particularly useful 204 when mechanisms such as "SYN cookies" [RFC4987] are implemented, 205 allowing a newly-established TCP connection to benefit from the 206 information advertised by the UTO option, even if the UTO contained 207 in the initial SYN segment was not recorded. 209 A host that supports the UTO option SHOULD include one in the next 210 possible outgoing segment whenever it starts using a new user timeout 211 for the connection. This allows the other end of the connection to 212 adapt its local user timeout accordingly. A TCP implementation that 213 does not support the UTO option MUST silently ignore it [RFC1122], 214 thus ensuring interoperability. 216 Hosts MUST impose upper and lower limits on the user timeouts they 217 use for a connection. Section 3.1 discusses user timeout limits and 218 potentially problematic effects of some user timeout settings. 220 Finally, it is worth noting that TCP's option space is limited to 40 221 bytes. As a result, if other TCP options are in use, they may 222 already consume all the available TCP option space, thus preventing 223 the use of the UTO option specified in this document. Therefore, TCP 224 option space issues should be considered before enabling the UTO 225 option. 227 3.1. Changing the Local User Timeout 229 When a host receives a TCP User Timeout Option, it must decide 230 whether to change the local user timeout of the corresponding 231 connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT 232 be changed, regardless of the received UTO option. Without this 233 restriction, the UTO option would modify TCP semantics, because an 234 application-requested USER TIMEOUT could be overridden by peer 235 requests. In this case TCP SHOULD, however, notify the application 236 about the user timeout value received from the other end system. 238 In general, unless the application on the local host has requested a 239 specific USER TIMEOUT for the connection, CHANGEABLE will be true and 240 hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in 241 response to receiving a UTO option, as described in the remainder of 242 this section. 244 The UTO option specifies the user timeout in seconds or minutes, 245 rather than in number of retransmissions or round-trip times (RTTs). 246 Thus, the UTO option allows hosts to exchange user timeout values 247 from 1 second to over 9 hours at a granularity of seconds, and from 1 248 minute to over 22 days at a granularity of minutes. 250 Very short USER TIMEOUT values can affect TCP transmissions over 251 high-delay paths. If the user timeout occurs before an 252 acknowledgment for an outstanding segment arrives, possibly due to 253 packet loss, the connection closes. Many TCP implementations default 254 to USER TIMEOUT values of a few minutes. Although the UTO option 255 allows suggestion of short timeouts, applications advertising them 256 should consider these effects. 258 Long USER TIMEOUT values allow hosts to tolerate extended periods 259 without end-to-end connectivity. However, they also require hosts to 260 maintain the TCP state information associated with connections for 261 long periods of time. Section 5 discusses the security implications 262 of long timeout values. 264 To protect against these effects, implementations MUST impose limits 265 on the user timeout values they accept and use. The remainder of 266 this section describes a RECOMMENDED scheme to limit TCP's USER 267 TIMEOUT based on upper and lower limits. 269 Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end 270 SHOULD compute the local USER TIMEOUT for a connection according to 271 this formula: 273 USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT)) 275 Each field is to be interpreted as follows: 277 USER_TIMEOUT 278 USER TIMEOUT value to be adopted by the local TCP for this 279 connection. 281 U_LIMIT 282 Current upper limit imposed on the user timeout of a connection by 283 the local host. 285 ADV_UTO 286 User timeout advertised to the remote TCP peer in a TCP User 287 Timeout Option. 289 REMOTE_UTO 290 Last user timeout value received from the other end in a TCP User 291 Timeout Option. 293 L_LIMIT 294 Current lower limit imposed on the user timeout of a connection by 295 the local host. 297 The RECOMMENDED formula results in the maximum of the two advertised 298 values, adjusted for the configured upper and lower limits, to be 299 adopted for the user timeout of the connection on both ends. The 300 rationale is that choosing the maximum of the two values will let the 301 connection survive longer periods without end-to-end connectivity. 302 If the end that announced the lower of the two user timeout values 303 did so in order to reduce the amount of TCP state information that 304 must be kept on the host, it can close or abort the connection 305 whenever it wants. 307 It must be noted that the two endpoints of the connection will not 308 necessarily adopt the same user timeout. 310 Enforcing a lower limit (L_LIMIT) prevents connections from closing 311 due to transient network conditions, including temporary congestion, 312 mobility hand-offs and routing instabilities. 314 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 315 attacks. Section 5 discusses the details of these attacks. 317 Note that these limits MAY be specified as system-wide constants or 318 at other granularities, such as on per-host, per-user, per-outgoing- 319 interface or even per-connection basis. Furthermore, these limits 320 need not be static. For example, they MAY be a function of system 321 resource utilization or attack status and could be dynamically 322 adapted. 324 The Host Requirements RFC [RFC1122] does not impose any limits on the 325 length of the user timeout. However, it recommends a time interval 326 of at least 100 seconds. Consequently, the lower limit (L_LIMIT) 327 SHOULD be set to at least 100 seconds when following the RECOMMENDED 328 scheme described in this section. Adopting a user timeout smaller 329 than the current retransmission timeout (RTO) for the connection 330 would likely cause the connection to be aborted unnecessarily. 331 Therefore, the lower limit (L_LIMIT) MUST be larger than the current 332 retransmission timeout (RTO) for the connection. It is worth noting 333 that an upper limit may be imposed on the RTO, provided it is at 334 least 60 seconds [RFC2988]. 336 3.2. UTO Option Reliability 338 The TCP User Timeout Option is an advisory TCP option that does not 339 change processing of subsequent segments. Unlike other TCP options, 340 it need not be exchanged reliably. Consequently, the specification 341 does not define a reliability handshake for UTO option exchanges. 342 When a segment that carries a UTO option is lost, the other end will 343 simply not have the opportunity to update its local UTO. 345 Implementations MAY implement local mechanisms to improve delivery 346 reliability, such as retransmitting a UTO option when they retransmit 347 a segment that originally carried it, or "attaching" the option to a 348 byte in the stream and retransmitting the option whenever that byte 349 or its ACK are retransmitted. 351 It is important to note that although these mechanisms can improve 352 transmission reliability for the UTO option, they do not guarantee 353 delivery (a three-way handshake would be required for this). 354 Consequently, implementations MUST NOT assume that UTO options are 355 transmitted reliably. 357 3.3. Option Format 359 Sending a TCP User Timeout Option informs the other end of the 360 connection of the current local user timeout and suggests that the 361 other end adapt its user timeout accordingly. The user timeout value 362 included in a UTO option contains the ADV_UTO value, that is expected 363 to be adopted for the TCP's USER TIMEOUT parameter during the 364 synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN- 365 WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other 366 states MUST use the default timeout values defined in [RFC0793] and 367 [RFC1122]. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Kind = TBD | Length = 4 |G| User Timeout | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 (One tick mark represents one bit.) 377 Figure 1: Format of the TCP User Timeout Option 379 Figure 1 shows the format of the TCP User Timeout Option. It 380 contains these fields: 382 Kind (8 bits) 383 This MUST be TBD, i.e., the TCP option number [RFC0793] assigned 384 by IANA upon publication of this document (see Section 6). [[Note 385 to the RFC Editor: Throughout this document, replace "TBD" with 386 the TCP option number that IANA has allocated and remove this 387 note.]] 389 Length (8 bits) 390 Length of the TCP option in octets [RFC0793]; its value MUST be 4. 392 Granularity (1 bit) 393 Granularity bit, indicating the granularity of the "User Timeout" 394 field. When set (G = 1), the time interval in the "User Timeout" 395 field MUST be interpreted as minutes. Otherwise (G = 0), the time 396 interval in the "User Timeout" field MUST be interpreted as 397 seconds. 399 User Timeout (15 bits) 400 Specifies the user timeout suggestion for this connection. It 401 MUST be interpreted as a 15-bit unsigned integer. The granularity 402 of the timeout (minutes or seconds) depends on the "G" field. 404 3.4. Reserved Option Values 406 An TCP User Timeout Option with a "User Timeout" field of zero and a 407 "Granularity" bit of either minutes (1) or seconds (0) is reserved 408 for future use. Current TCP implementations MUST NOT send it and 409 MUST ignore it upon reception. 411 4. Interoperability Issues 413 This section discusses interoperability issues related to introducing 414 the TCP User Timeout Option. 416 4.1. Middleboxes 418 A TCP implementation that does not support the TCP User Timeout 419 Option MUST silently ignore it [RFC1122], thus ensuring 420 interoperability. In a study of the effects of middleboxes on 421 transport protocols, Medina et al. have shown that the vast majority 422 of modern TCP stacks correctly handle unknown TCP options [MEDINA]. 423 In this study, 3% of connections failed when an unknown TCP option 424 appeared in the middle of a connection. Because the number of 425 failures caused by unknown options is small and they are a result of 426 incorrectly implemented TCP stacks that violate existing requirements 427 to ignore unknown options, they do not warrant special measures. 428 Thus, this document does not define a mechanism to negotiate support 429 of the TCP User Timeout Option during the three-way handshake. 431 Stateful firewalls usually time out connection state after a period 432 of inactivity. If such a firewall exists along the path, it may 433 close or abort connections regardless of the use of the TCP User 434 Timeout Option. In the future, such firewalls may learn to parse the 435 TCP User Timeout Option in unencrypted TCP segments and adapt 436 connection state management accordingly. 438 4.2. TCP Keep-Alives 440 Some TCP implementations, such as those in BSD systems, use a 441 different abort policy for TCP keep-alives than for user data. Thus, 442 the TCP keep-alive mechanism might abort a connection that would 443 otherwise have survived the transient period without connectivity. 444 Therefore, if a connection that enables keep-alives is also using the 445 TCP User Timeout Option, then the keep-alive timer MUST be set to a 446 value larger than that of the adopted USER TIMEOUT. 448 5. Security Considerations 450 Lengthening user timeouts has obvious security implications. 451 Flooding attacks cause denial of service by forcing servers to commit 452 resources for maintaining the state of throw-away connections. 453 However, TCP implementations do not become more vulnerable to simple 454 SYN flooding by implementing the TCP User Timeout Option, because 455 user timeouts exchanged during the handshake only affect the 456 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 457 CLOSING, LAST-ACK), which simple SYN floods never reach. 459 However, when an attacker completes the three-way handshakes of its 460 throw-away connections it can amplify the effects of resource 461 exhaustion attacks, because the attacked server must maintain the 462 connection state associated with the throw-away connections for 463 longer durations. Because connection state is kept longer, lower- 464 frequency attack traffic, which may be more difficult to detect, can 465 already exacerbate resource exhaustion. 467 Several approaches can help mitigate this issue. First, 468 implementations can require prior peer authentication, e.g., using 469 IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user 470 timeouts for the peer's connections. Similarly, a host can start to 471 accept long user timeouts for an established connection only after 472 in-band authentication has occurred, for example, after a TLS 473 handshake across the connection has succeeded [RFC5246]. Although 474 these are arguably the most complete solutions, they depend on 475 external mechanisms to establish a trust relationship. 477 A second alternative that does not depend on external mechanisms 478 would introduce a per-peer limit on the number of connections that 479 may use increased user timeouts. Several variants of this approach 480 are possible, such as fixed limits or shortening accepted user 481 timeouts with a rising number of connections. Although this 482 alternative does not eliminate resource exhaustion attacks from a 483 single peer, it can limit their effects. Reducing the number of 484 high-UTO connections a server supports in the face of an attack turns 485 that attack into a denial-of-service attack against the service of 486 high-UTO connections. 488 Per-peer limits cannot protect against distributed denial of service 489 attacks, where multiple clients coordinate a resource exhaustion 490 attack that uses long user timeouts. To protect against such 491 attacks, TCP implementations could reduce the duration of accepted 492 user timeouts with increasing resource utilization. 494 TCP implementations under attack may be forced to shed load by 495 resetting established connections. Some load-shedding heuristics, 496 such as resetting connections with long idle times first, can 497 negatively affect service for intermittently connected, trusted peers 498 that have suggested long user timeouts. On the other hand, resetting 499 connections to untrusted peers that use long user timeouts may be 500 effective. In general, using the peers' level of trust as a 501 parameter during the load-shedding decision process may be useful. 502 Note that if TCP needs to close or abort connections with a long TCP 503 User Timeout Option to shed load, these connections are still no 504 worse off than without the option. 506 Finally, upper and lower limits on user timeouts, discussed in 507 Section 3.1, can be an effective tool to limit the impact of these 508 sorts of attacks. 510 6. IANA Considerations 512 This section is to be interpreted according to [RFC5226]. 514 This document does not define any new namespaces. It requests that 515 IANA allocate a new 8-bit TCP option number for the UTO option from 516 the registry maintained at 517 http://www.iana.org/assignments/tcp-parameters. 519 7. Acknowledgments 521 The following people have improved this document through thoughtful 522 suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, 523 Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade 524 Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, 525 Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, 526 Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha 527 Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and 528 Martin Stiemerling. 530 Lars Eggert is partly funded by [TRILOGY], a research project 531 supported by the European Commission under its Seventh Framework 532 Program. 534 8. References 536 8.1. Normative References 538 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 539 RFC 793, September 1981. 541 [RFC1122] Braden, R., "Requirements for Internet Hosts - 542 Communication Layers", STD 3, RFC 1122, October 1989. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 548 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 549 May 2008. 551 8.2. Informative References 553 [I-D.eddy-tcp-mobility] 554 Eddy, W., "Mobility Support For TCP", 555 draft-eddy-tcp-mobility-00 (work in progress), April 2004. 557 [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring 558 Interactions Between Transport Protocols and Middleboxes", 559 Proc. 4th ACM SIGCOMM/USENIX Conference on Internet 560 Measurement , October 2004. 562 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 563 Signature Option", RFC 2385, August 1998. 565 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 566 Timer", RFC 2988, November 2000. 568 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 569 August 2002. 571 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 572 Internet Protocol", RFC 4301, December 2005. 574 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 575 (HIP) Architecture", RFC 4423, May 2006. 577 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 578 Mitigations", RFC 4987, August 2007. 580 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 581 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 583 [SOLARIS-MANUAL] 584 Sun Microsystems, "Solaris Tunable Parameters Reference 585 Manual", Part No. 806-7009-10, 2002. 587 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 589 Appendix A. Document Revision History 591 [[Note to the RFC Editor: Section to be removed upon publication.]] 593 +----------+--------------------------------------------------------+ 594 | Revision | Comments | 595 +----------+--------------------------------------------------------+ 596 | -10 | Addressing the gen-art review comments from Scott | 597 | | Brim. Updated reference to [RFC5246]. Added funding | 598 | | source acknowledgment. | 599 | | | 600 | -09 | Resubmission after expiration. Updated reference to | 601 | | [RFC5226]. | 602 | | | 603 | -08 | Addressed additional, minor working group last call | 604 | | comments. | 605 | | | 606 | -07 | Addressed working group last call comments. | 607 | | | 608 | -06 | Includes a note on the limited space for TCP options | 609 | | and miscellaneous editorial changes (suggested by | 610 | | Anantha Ramaiah). Includes possible enforcement of | 611 | | per-outgoing-interface limits for the UTO, and | 612 | | miscellaneous editorial changes (suggested by Alfred | 613 | | Hoenes). Includes relevant changes to reflect WG | 614 | | consensus how the local user timeout should be | 615 | | selected (i.e., record both the current user timeout, | 616 | | and the advertised UTO). | 617 | | | 618 | -05 | Made behavior on when to change/not change the local | 619 | | UTO in response to incoming options consistent through | 620 | | the document. This required some reshuffling of text | 621 | | and also removed the need for the special "don't care" | 622 | | option value. | 623 | | | 624 | -04 | Clarified the results obtained by Medina et al. Added | 625 | | text to suggest inclusion of the UTO in the first | 626 | | non-SYN segment by the TCP that sent a SYN in response | 627 | | to an active OPEN. | 628 | | | 629 | -03 | Corrected use of RFC2119 terminology. Clarified how | 630 | | use of the TCP UTO is triggered. Clarified reason for | 631 | | sending a UTO in the SYN and SYN/ACK segments. | 632 | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | 633 | | socket options. Removed text that suggested that a | 634 | | UTO should be sent upon receipt of an UTO from the | 635 | | other end. Required minimum value for the lower limit | 636 | | of the user timeout. Moved alternative solutions to | 637 | | appendix. Miscellaneous editorial changes. | 638 | | | 639 | -02 | Corrected terminology by replacing terms like | 640 | | "negotiate", "coordinate", etc. that were left from | 641 | | pre-WG-document times when the UTO was a more | 642 | | formalized exchange instead of the advisory one it is | 643 | | now. Application-requested UTOs take precedence over | 644 | | ones received from the peer (pointed out by Ted | 645 | | Faber). Added a brief mention of SO_SNDTIMEO and a | 646 | | slightly longer discussion of SO_RCVTIMEO. | 647 | | | 648 | -01 | Clarified and corrected the description of the | 649 | | existing user timeout in RFC793 and RFC1122. Removed | 650 | | distinction between operating during the 3WHS and the | 651 | | established states and introduced zero-second "don't | 652 | | care" UTOs in response to mailing list feedback. | 653 | | Updated references and addressed many other comments | 654 | | from the mailing list. | 655 | | | 656 | -00 | Resubmission of | 657 | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | 658 | | secretariat after WG adoption. Thus, permit | 659 | | derivative works. Updated Lars Eggert's funding | 660 | | attribution. Updated several references. No | 661 | | technical changes. | 662 +----------+--------------------------------------------------------+ 664 Authors' Addresses 666 Lars Eggert 667 Nokia Research Center 668 P.O. Box 407 669 Nokia Group 00045 670 Finland 672 Phone: +358 50 48 24461 673 Email: lars.eggert@nokia.com 674 URI: http://research.nokia.com/people/lars_eggert/ 675 Fernando Gont 676 Universidad Tecnologica Nacional / Facultad Regional Haedo 677 Evaristo Carriego 2644 678 Haedo, Provincia de Buenos Aires 1706 679 Argentina 681 Phone: +54 11 4650 8472 682 Email: fernando@gont.com.ar 683 URI: http://www.gont.com.ar/ 685 Full Copyright Statement 687 Copyright (C) The IETF Trust (2008). 689 This document is subject to the rights, licenses and restrictions 690 contained in BCP 78, and except as set forth therein, the authors 691 retain all their rights. 693 This document and the information contained herein are provided on an 694 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 695 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 696 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 697 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 698 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 699 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 Intellectual Property 703 The IETF takes no position regarding the validity or scope of any 704 Intellectual Property Rights or other rights that might be claimed to 705 pertain to the implementation or use of the technology described in 706 this document or the extent to which any license under such rights 707 might or might not be available; nor does it represent that it has 708 made any independent effort to identify any such rights. Information 709 on the procedures with respect to rights in RFC documents can be 710 found in BCP 78 and BCP 79. 712 Copies of IPR disclosures made to the IETF Secretariat and any 713 assurances of licenses to be made available, or the result of an 714 attempt made to obtain a general license or permission for the use of 715 such proprietary rights by implementers or users of this 716 specification can be obtained from the IETF on-line IPR repository at 717 http://www.ietf.org/ipr. 719 The IETF invites any interested party to bring to its attention any 720 copyrights, patents or patent applications, or other proprietary 721 rights that may cover technology that may be required to implement 722 this standard. Please address the information to the IETF at 723 ietf-ipr@ietf.org.