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