idnits 2.17.00 (12 Aug 2021) /tmp/idnits47325/draft-eggert-gont-tcpm-tcp-uto-option-01.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 11) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2004) is 6413 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 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '7') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '13') (Obsoleted by RFC 4346) == Outdated reference: A later version (-04) exists of draft-eddy-tcp-loo-01 -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '16') (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor L. Eggert 3 Extensions (tcpm) NEC 4 Internet-Draft F. Gont 5 Expires: April 22, 2005 UTN/FRH 6 October 22, 2004 8 TCP User Timeout Option 9 draft-eggert-gont-tcpm-tcp-uto-option-01 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. This document may not be modified, and derivative works of 19 it may not be created, except to publish it as an RFC and to 20 translate it into languages other than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 22, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 The TCP user timeout controls how long transmitted data may remain 47 unacknowledged before a connection is aborted. TCP implementations 48 typically use a single, system-wide user timeout value. The TCP User 49 Timeout Option allows conforming TCP implementations to exchange 50 requests for individual, per-connection user timeouts. Lengthening 51 the system-wide default user timeout allows established TCP 52 connections to survive extended periods of disconnection. On the 53 other hand, shortening the default user timeout allows busy servers 54 to explicitly notify their clients they will maintain the connection 55 state information only accross short periods of disconnection. 57 1. Introduction 59 The Transmission Control Protocol (TCP) specification [1] defines a 60 "user timeout" parameter that specifies the maximum amount of time 61 that transmitted data may remain unacknowledged before TCP will abort 62 the corresponding connection. If a disconnection lasts longer than 63 the user timeout, no acknowledgments will be received for any 64 transmission attempt, including keep-alives [5], and the TCP 65 connection will be aborted when the user timeout occurs. 67 The TCP specification [1] does not constrain the permitted values for 68 user timeouts. However, the Host Requirements RFC [2] mandates a 69 timeout of at least three minutes for the SYN-SENT case. Many TCP 70 implementations default to user timeout values of a few minutes [5]. 71 Instead of a single user timeout, some TCP implementations offer 72 finer-grained policies. For example, Solaris supports different 73 timeouts depending on whether a TCP connection is in the SYN-SENT, 74 SYN-RECEIVED, or ESTABLISHED state [6]. 76 System-wide user timeouts are a useful basic policy. However, the 77 ability to selectively choose individual user timeout values for 78 different connections can improve TCP operation in scenarios that are 79 currently not well supported. One example of such scenarios are 80 mobile hosts that change network attachment points based on current 81 location. Such hosts, maybe using MobileIP [7], HIP [8] or 82 transport-layer mobility mechanisms [9], are only intermittently 83 connected to the Internet. In between connected periods, mobile 84 hosts may experience periods of disconnection during which no network 85 service is available [10][11][12]. Other factors that can cause 86 transient periods of disconnection are high levels of congestion as 87 well as link or routing failures inside the network. 89 In scenarios similar to the ones described above, a host may not know 90 exactly when or for how long it will be disconnected from the 91 network, but it might expect such events due to past mobility 92 patterns and thus benefit from using longer user timeouts. In other 93 scenarios, the length and time of a network disconnection may even be 94 predictable. For example, an orbiting node on a satellite might 95 experience disconnections due to line-of-sight blocking by other 96 planetary bodies. The disconnection periods of such a node may be 97 easily computable from orbital mechanics. 99 In the examples above, as well as in other cases, established TCP 100 connections between two peers may be aborted if a disconnection 101 exceeds the system-wide default user timeout. This document 102 specifies a new TCP option - the User Timeout Option - that allows 103 conforming hosts to exchange per-connection user timeout requests. 104 This allows, for example, mobile hosts to maintain TCP connections 105 across disconnected periods that are longer than their system's 106 default user timeout. A second use of the TCP User Timeout Option is 107 advertisement of shorter-than-default user timeouts. This can allow 108 busy servers to explicitly notify their clients that they will 109 maintain the state associated with established connections only 110 across short periods of disconnection. 112 A different approach to tolerate longer periods of disconnection is 113 simply increasing the system-wide user timeout on both peers. This 114 approach has the benefit of not requiring a new TCP option. However, 115 it can also significantly increase the amount of connection state 116 information a host must maintain, because a longer global timeout 117 value will apply to all its connections. The proposed User Timeout 118 Option, on the other hand, allows hosts to selectively manage the 119 user timeouts of individual connections. They must then only 120 maintain the state associated with selected connections across 121 disconnected periods. 123 A second benefit of the TCP User Timeout Option is that it allows 124 hosts to both request specific user timeouts for new connections and 125 to request changes to the effective user timeouts of established 126 connections. The latter allows connections to start with short 127 timeouts and only request longer timeouts when disconnection is 128 imminent, and only for connections considered important. The ability 129 to request changes to user timeouts of established connections is 130 also useful to raise the user timeout after in-band authentication 131 has occurred. For example, peers could request longer user timeouts 132 for the TCP connections underlying two-way authenticated TLS 133 connections [13] after their authentication handshakes have 134 succeeded. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [3]. 142 3. Operation 144 Sending a TCP User Timeout Option suggests to the remote peer to use 145 the indicated user timeout value for the corresponding connection. 146 Section 3.4 discusses the effects of different timeout values. 148 The user timeout value included in a TCP User Timeout Option 149 specifies the requested user timeout during a connection's 150 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 151 CLOSING, or LAST-ACK.) Connections in other states MUST use standard 152 timeout values [1][2]. [Comment.1] 154 When a host that supports the TCP User Timeout Option receives one, 155 it decides whether to change the connection's local user timeout 156 based on the received value. Generally, hosts SHOULD honor requests 157 for changes to the user timeout, unless security concerns or external 158 policies indicate otherwise (see Section 5.) If so, hosts MAY ignore 159 incoming TCP User Timeout Options and MAY use a different user 160 timeout for the connection. 162 It is important to note that the TCP User Timeout Option does not 163 change the semantics of the TCP protocol. Hosts remain free to abort 164 connections at any time for any reason, whether or not they use 165 custom user timeouts or have suggested the peer to use them. 167 Hosts SHOULD impose upper and lower limits on the user timeouts they 168 use. Section 3.4 discusses user timeout limits. A TCP User Timeout 169 Option with a value of zero (i.e., "now") is nonsensical and MUST NOT 170 be sent. If received, it MUST be ignored. Section 3.4 discusses 171 potentially problematic effects of other user timeout durations. 173 A TCP implementation that does not support the TCP User Timeout 174 Option SHOULD silently ignore it [2], thus ensuring interoperability. 176 3.1 Option Format 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Kind = X | Length = 4 |G| User Timeout | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 (One tick mark represents one bit.) 186 Figure 1: Format of the TCP User Timeout Option 188 Figure 1 shows the format of the TCP User Timeout Option. It 189 contains these fields: 191 Kind (8 bits) 192 A TCP option number [1] to be assigned by IANA upon publication of 193 this document (see Section 6.) 195 Length (8 bits) 196 Length of the TCP option in octets [1]; its value MUST be 4. 198 Granularity (1 bit) 199 Granularity bit, indicating the granularity of the "User Timeout" 200 field. When set (G = 1), the time interval in the "User Timeout" 201 field MUST be interpreted as minutes. Otherwise (G = 0), the time 202 interval in the "User Timeout" field MUST be interpreted as 203 seconds. 205 User Timeout (15 bits) 206 Specifies the user timeout suggestion for this connection. It 207 MUST be interpreted as a 15-bit unsigned integer. The granularity 208 of the timeout (minutes or seconds) depends on the "G" field. 210 3.2 Operation During the SYN Handshake 212 A host that supports the TCP User Timeout Option MUST include an 213 appropriate TCP User Timeout Option in its initial SYN segment to 214 indicate that it supports the option and to suggest an initial user 215 timeout for the connection. [Comment.2] 217 A host that supports the TCP User Timeout Option and receives a SYN 218 segment that includes one MUST respond with an appropriate TCP User 219 Timeout Option in its SYN-ACK segment. If an incoming SYN segment 220 does not include a TCP User Timeout Option, a host MUST NOT include 221 one in the SYN-ACK segment nor in any other segment, and it MUST 222 ignore the contents of any other received TCP User Timeout Option. 224 3.3 Operation During the Synchronized States 226 Unless both the SYN and SYN-ACK of a connection contained TCP User 227 Timeout Options, both hosts participating in the connection MUST NOT 228 send TCP User Timeout Options in any other segment. Additionally, 229 they both MUST ignore the contents of any received TCP User Timeout 230 Option. 232 If, however, both the SYN and SYN-ACK contained TCP User Timeout 233 Options, hosts MAY choose to include additional TCP User Timeout 234 Options in segments sent during the synchronized states (ESTABLISHED, 235 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). 237 Dynamically adapting the user timeout of a connection during its 238 lifetime could be useful in a number of scenarios, for example: 240 o TCP may adapt the user timeout based on observed network 241 characteristics. [Comment.3] 243 o TCP may use short timeouts when connections start and only suggest 244 longer timeouts when disconnection was imminent. 246 o TCP may use short user timeouts when connections start and only 247 raise them once in-band authentication has occurred, for example, 248 once a TLS handshake across the connection has succeeded [13]. 250 Generally, whenever a host decides to change the local user timeout 251 of a connection, it SHOULD include a TCP User Timeout Option 252 indicating the new user timeout in its next segment to the peer. 253 This allows the peer to adapt its local user timeout for the 254 connection accordingly. 256 TCP's SYN handshake has specific retransmission rules to guarantee 257 reliability. These mechanisms also guarantee that the exchange of 258 TCP User Timeout Options during the SYN handshake is reliable. This 259 is not the case for TCP User Timeout Option exchanges during the 260 synchronized states. When a segment carrying a TCP User Timeout 261 Option is lost, the peer will not update its local user timeout 262 accordingly. This draft does not currently describe mechanisms to 263 ensure the reliability of the option exchange in the synchronized 264 states, other than noting that periodic inclusion of the option may 265 be an appropriate interim mechanism for implementations concerned 266 with reliability. 268 3.4 Duration of the User Timeout 270 The TCP User Timeout Option allows hosts to exchange user timeout 271 values from zero seconds to over 9 hours at a granularity of seconds 272 and from zero minutes to over 22 days at a granularity of minutes. 274 Very short user timeout values can affect TCP transmissions over 275 high-delay paths. If the user timeout occurs before an 276 acknowledgment for an outstanding segment arrives, possibly due to 277 packet loss, the connection aborts. Many TCP implementations default 278 to user timeout values of a few minutes [5]. Although the TCP User 279 Timeout Option allows suggestion of short timeouts, applications 280 advertising them should consider these effects. 282 Long user timeout values allow hosts to tolerate extended periods of 283 disconnection. However, they also require hosts to maintain the TCP 284 state information associated with connections for long periods of 285 time. Section 5 discusses the security implications of long timeout 286 values. 288 To protect against these effects, implementations SHOULD impose 289 limits on the user timeout values they accept and use. The remainder 290 of this section describes a RECOMMENDED scheme to limit user timeouts 291 based on upper and lower limits. Under the RECOMMENDED scheme, each 292 TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection 293 according to this formula: 295 USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) 296 [Comment.4] 298 Each field is to be interpreted as follows: 300 USER_TIMEOUT 301 Resulting user timeout value to be adopted by the local TCP for a 302 connection. 304 U_LIMIT 305 Current upper limit imposed on the connection's user timeout by 306 the local host. 308 L_LIMIT 309 Current lower limit imposed on the connection's user timeout by 310 the local host. 312 LOCAL_UTO 313 Current local user timeout of the specific connection. 315 REMOTE_UTO 316 Last "user timeout" value suggested by the remote peer by means of 317 the TCP User Timeout Option. 319 This means that the maximum of the two announced values will be 320 adopted for the user timeout of the connection. The rationale is 321 that choosing the maximum of the two values will let the connection 322 survive transient periods of disconnection. If the TCP that 323 announced the lower of the two user timeout values did so in order to 324 reduce the amount of TCP state information that must be kept on the 325 host, it can, nevertheless, abort the connection whenever it wants. 327 Enforcing a lower limit (L_LIMIT) protects against connection aborts 328 due to transient network conditions, including temporary congestion, 329 mobility hand-offs and routing instabilities. 331 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 332 attacks. Section 5 discusses the details of these attacks. 334 Note that these limits MAY be specified as system-wide constants or 335 at other granularities, such as on per-host, per-user or even 336 per-connection basis. Furthermore, these limits need not be static. 337 For example, they MAY be a function of system resource utilization or 338 attack status and could be dynamically adapted. 340 The Host Requirements RFC [2] does not impose any limits on the 341 length of the user timeout. However, a time interval of at least 100 342 seconds is RECOMMENDED. Consequently, the lower limit (LLIMIT) 343 SHOULD be set to at least 100 seconds when following the RECOMMENDED 344 scheme described in this section. 346 4. Interoperability Issues 348 This section discusses interoperability issues related to introducing 349 the UTO option. 351 One meta-issue of introducing new TCP options is that header space 352 available for TCP options is currently limited to 40 bytes. All 353 negotiable options are exchanged during the SYN/SYN-ACK handshake, 354 where option space is becoming limited. Current proposals to extend 355 the available option space may mitigate this issue [14]. 357 4.1 Middleboxes 359 The large number of middleboxes (firewalls, proxies, protocol 360 scrubbers, etc.) currently present in the Internet pose some 361 difficulty for deploying new TCP options. Some firewalls may block 362 segments that carry unknown options, preventing connection 363 establishment when the SYN or SYN-ACK contains the UTO option. Some 364 recent results, however, indicate that for new TCP options, this may 365 not be a significant threat, with only 0.2% of web requests failing 366 when carrying an unknown option [15]. 368 Stateful firewalls usually reset connections after a period of 369 inactivity. If such a firewall exists along the path between two 370 peers, it may abort connections regardless of the use of the UTO 371 Option. In the future, such firewalls may learn to parse the UTO 372 option and modify their behavior accordingly. 374 4.2 TCP Keep-Alives 376 Some TCP implementations, such as the one in BSD systems, use a 377 different abort policy for TCP keepalives than for user data. Thus, 378 the TCP keep-alive mechanism might abort a connection that would 379 otherwise have survived the transient period of disconnection. 380 Therefore, if a TCP peer enables TCP keep-alives for a connection 381 that is using the UTO Option, then the keep-alive timer MUST be set 382 to a value larger than that of the adopted USER TIMEOUT (specified by 383 Equation 1). 385 5. Security Considerations 387 Lengthening user timeouts has obvious security implications. 389 Flooding attacks cause denial of service by forcing servers to commit 390 resources for maintaining the state of throw-away connections. TCP 391 implementations do not become more vulnerable to simple SYN flooding 392 by implementing the TCP User Timeout Option, because user timeouts 393 negotiated during the handshake only affect the synchronized states 394 (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), 395 which simple SYN floods never reach. 397 However, when an attacker completes the three-way handshakes of its 398 throw-away connections it can amplify the effects of resource 399 exhaustion attacks, because the attacked server must maintain the 400 connection state associated with the throw-away connections for 401 longer durations. Because connection state is kept longer, 402 lower-frequency attack traffic, which may be more difficult to 403 detect, can already cause resource exhaustion. [Comment.5] 405 Several approaches can help mitigate this issue. First, 406 implementations can require prior peer authentication, e.g., using 407 IPsec [16], before accepting long user timeouts for the peer's 408 connections. Similarly, a host can only start to accept long user 409 timeouts for an established connection after in-band authentication 410 has occurred, for example, after a TLS handshake across the 411 connection has succeeded [13]. Although these are arguably the most 412 complete solutions, they depend on external mechanisms to establish a 413 trust relationship. 415 A second alternative that does not depend on external mechanisms 416 would introduce a per-peer limit on the number of connections that 417 may use increased user timeouts. Several variants of this approach 418 are possible, such as fixed limits or shortening accepted user 419 timeouts with a rising number of connections. Although this 420 alternative does not eliminate resource exhaustion attacks from a 421 single peer, it can limit their effects. 423 Per-peer limits cannot protect against distributed denial of service 424 attacks, where multiple clients coordinate a resource exhaustion 425 attack that uses long user timeouts. To protect against such 426 attacks, TCP implementations could reduce the duration of accepted 427 user timeouts with increasing resource utilization. 429 TCP implementations under attack may be forced to shed load by 430 resetting established connections. Some load-shedding heuristics, 431 such as resetting connections with long idle times first, can 432 negatively affect service for intermittently connected, trusted peers 433 that have suggested long user timeouts. On the other hand, resetting 434 connections to untrusted peers that use long user timeouts may be 435 effective. In general, using the peers' level of trust as a 436 parameter during the load-shedding decision process may be useful. 438 Finally, upper and lower limits on user timeouts, discussed in 439 Section 3.4, can be an effective tool to limit the impact of these 440 sorts of attacks. 442 6. IANA Considerations 444 This section is to be interpreted according to [4]. 446 This document does not define any new namespaces. It uses an 8-bit 447 TCP option number maintained by IANA at 448 http://www.iana.org/assignments/tcp-parameters. 450 7. Acknowledgments 452 The following people have improved this document through thoughtful 453 suggestions: Mark Allmann, David Borman, Marcus Brunner, Wesley Eddy, 454 Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Phil Karn, 455 Michael Kerrisk, Kostas Pentikousis, Juergen Quittek, Joe Touch, 456 Stefan Schmid, Simon Schuetz and Martin Stiemerling. 458 Part of this work is a byproduct of the Ambient Networks project, 459 partially supported by the European Commission under its Sixth 460 Framework Programme. It is provided "as is" and without any express 461 or implied warranties, including, without limitation, the implied 462 warranties of fitness for a particular purpose. The views and 463 conclusions contained herein are those of the authors and should not 464 be interpreted as necessarily representing the official policies or 465 endorsements, either expressed or implied, of the Ambient Networks 466 project or the European Commission. 468 8. References 470 8.1 Normative References 472 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 473 September 1981. 475 [2] Braden, R., "Requirements for Internet Hosts - Communication 476 Layers", STD 3, RFC 1122, October 1989. 478 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 482 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 484 8.2 Informative References 486 [5] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley , 487 1994. 489 [6] Sun Microsystems, "Solaris Tunable Parameters Reference 490 Manual", Part No. 806-7009-10, 2002. 492 [7] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 493 2002. 495 [8] Moskowitz, R., "Host Identity Protocol Architecture", 496 draft-moskowitz-hip-arch-06 (work in progress), June 2004. 498 [9] Eddy, W., "Mobility Support For TCP", 499 draft-eddy-tcp-mobility-00 (work in progress), April 2004. 501 [10] Schuetz, S., "Network Support for Intermittently Connected 502 Mobile Nodes", M.S. Thesis, University of Mannheim, Germany, 503 June 2004. 505 [11] Schuetz, S., Eggert, L., Schmid, S. and M. Brunner, "Protocol 506 Enhancements for Intermittently Connected Hosts", under 507 submission (work in progress), July 2004. 509 [12] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for 510 Automobile Users", Proc. INFOCOM , March 2004. 512 [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 513 2246, January 1999. 515 [14] Eddy, W., "Extending the Space Available for TCP Options", 516 draft-eddy-tcp-loo-01 (work in progress), September 2004. 518 [15] Medina, A., Allman, M. and S. Floyd, "Measuring Interactions 519 Between Transport Protocols and Middleboxes", To appear: Proc. 520 ACM SIGCOMM/USENIX Internet Measurement Conference , October 521 2004. 523 [16] Kent, S. and R. Atkinson, "Security Architecture for the 524 Internet Protocol", RFC 2401, November 1998. 526 Editorial Comments 528 [Comment.1] LE: A future version of this document may extend 529 per-connection user timeouts to the SYN-SENT and 530 SYN-RECEIVED states in a way that conforms to the 531 required minimum timeouts. 533 [Comment.2] LE: My original proposal was to allow hosts to choose 534 whether or not to include the option. It's open for 535 discussion whether this flexibility is worth the 536 additional complexity. This is the corresponding text: 537 "A host that supports the TCP User Timeout Option MAY 538 omit the TCP User Timeout Option from the initial SYN if 539 it will not permit custom user timeouts for the specific 540 connection. It SHOULD omit the TCP User Timeout Option 541 from the initial SYN if there is evidence that the peer 542 does not support the TCP User Timeout Option, for 543 example, if a prior connection attempt including a TCP 544 User Timeout Option has failed. If a host does not 545 include a TCP User Timeout Option in its initial SYN, it 546 MUST NOT include it in any other segment either and MUST 547 ignore the contents of any received TCP User Timeout 548 Option." 550 [Comment.3] FG: My original proposal suggested that TCP might adapt 551 the user timeout when signalled of congestion by means 552 of ECN. 554 [Comment.4] LE: This formula takes the maximum of the two announced 555 values. I'd use USER_TIMEOUT = max(L_LIMIT, 556 min(LOCAL_UTO, REMOTE_UTO, U_LIMIT)), instead. This 557 version takes the minimum. My rationale is that the 558 party announcing the lower value probably had a reason 559 for it and may hence not be prepared to handle a longer 560 value that it originally indicated. 562 [Comment.5] FG: IMO, in practice the TCP User Timeout option does 563 not make the situation worse: the same type of attack 564 can be performed even if the default "USER TIMEOUT" is 565 used, since TCP requires no message exchange in order to 566 keep a connection open. 568 Authors' Addresses 570 Lars Eggert 571 NEC Network Laboratories 572 Kurfuerstenanlage 36 573 Heidelberg 69115 574 Germany 576 Phone: +49 6221 90511 43 577 Fax: +49 6221 90511 55 578 EMail: lars.eggert@netlab.nec.de 579 URI: http://www.netlab.nec.de/ 580 Fernando Gont 581 Universidad Tecnologica Nacional 582 Evaristo Carriego 2644 583 Haedo, Provincia de Buenos Aires 1706 584 Argentina 586 Phone: +54 11 4650 8472 587 EMail: fernando@gont.com.ar 588 URI: http://www.gont.com.ar/ 590 Appendix A. Document Revision History 592 +-----------+-------------------------------------------------------+ 593 | Revision | Comments | 594 +-----------+-------------------------------------------------------+ 595 | 00 | Initial version. | 596 | 01 | Merged the ATO and AUTO drafts. | 597 +-----------+-------------------------------------------------------+ 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Disclaimer of Validity 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Copyright Statement 635 Copyright (C) The Internet Society (2004). This document is subject 636 to the rights, licenses and restrictions contained in BCP 78, and 637 except as set forth therein, the authors retain all their rights. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.