idnits 2.17.00 (12 Aug 2021) /tmp/idnits55039/draft-eddy-tcp-mobility-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 582), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 7, 2004) is 6611 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 3220 (ref. '3') (Obsoleted by RFC 3344) ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- No information found for draft-sjkok-sctp-mobility - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2581 (ref. '13') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (ref. '14') (Obsoleted by RFC 6298) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '15') ** Obsolete normative reference: RFC 1323 (ref. '16') (Obsoleted by RFC 7323) Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft NASA GRC/Verizon FNS 4 Expires: October 6, 2004 April 7, 2004 6 Mobility Support For TCP 7 draft-eddy-tcp-mobility-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 6, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 Once a TCP connection is established, there are no mechanisms for 40 dynamically rebinding the connection to new IP addresses or port 41 numbers. During the lifetime of a TCP connection, a mobile host's 42 transition between networks (and the corresponding change in its IP 43 address) will break any established TCP connections. As a remedy, 44 this document presents an extension of TCP with support for dynamic 45 bindings of IP addresses and port numbers. Compatibility with 46 existing TCP implementations is maintained, and reasonable steps are 47 taken to prevent remote-redirction attacks. 49 1. Requirements Notation 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119. 55 2. Introduction 57 A TCP connection is an association between two pairs of IP address 58 and TCP port number identifiers [1]. None of these four values may 59 change at any point over the lifetime of a TCP connection. Host 60 mobility across networks is a problem that motivates a change to this 61 policy, so that a connection end may be rebound to a new IP addresses 62 and TCP port number without requiring re-establishment. While this 63 feature might also be useful in load balancing scenarios, enabling a 64 busy host to shed some of its connections to another host [2], only 65 the mobility problem is specifically dealt with here. 67 This document describes a set of TCP options for dynamic rebinding of 68 TCP connection ends. This is accomplished without breaking 69 compatibility with TCP implementations that do not implement these 70 options, and in a manner robust against connection hijacking or 71 remote-redirection attacks, in which some malicious host attempts to 72 change the address bindings of a connection belonging to another 73 host. 75 For mobility in today's Internet, simply using Mobile IP [3] 76 underneath TCP is not an adequate solution. The Home and Foreign 77 Agents (HAs and FAs) that constitute the Mobile IP infrastructure are 78 not ubiquitously deployed, leaving helpless mobile hosts that either 79 originate in networks lacking an HA or move into networks lacking an 80 FA. Although the need for an FA is mitigated by using colocated 81 care-of addresses in Mobile IP. this document presents a solution 82 that removes the need for both HAs and FAs. Furthermore, the current 83 Mobile IP standard has no provisions for route-optimization, which 84 would remove the less-efficient side of the triangle routes 85 constructed by Mobile IP. Current Internet security practices at 86 many locations actually require the use of Mobile IP's 87 topologically-correct tunnel extension [4], which uses the less 88 efficient indirect route through the HA in both directions. This 89 document describes a solution of which route optimization is an 90 inherrent property. Stateful firewalls and Network Address 91 translators (NATs) [5] also do not pose problems to the mobility 92 mechanism presented here. 94 The Mobility Support options for TCP described here allow a host 95 whose IP address has changed to identify itself with a cryptographic 96 cookie and have its TCP connections redirected to the new address. 97 The use of Elliptic Curve Diffie Hellman key exchange [6] to create 98 the cookie secures this technique against remote-redirection attacks. 100 3. Transport Layer Mobility Architecture 102 The term "transport layer mobility" is used to describe an 103 architecture for mobility where there is no need for additional 104 network infrastructure beyond traditional IP routers, an automated 105 method of acquiring IP addresses such as the Dynamic Host 106 Configuration Protocol (DHCP) [7] (which is widely deployed), and a 107 means for maintaining host reachability across address changes such 108 as dynamic DNS [8]. 110 A host employing tranport layer mobility may have either a single 111 network interface or multiple interfaces. The host must have some 112 means of knowing when it has moved onto a new IP network. This might 113 be accomplished by receiving a router advertisement from the new 114 network. The mobile host may then use a means such as DHCP to obtain 115 an IP address on the new network. At some point when either the 116 signal strength on the new network is stronger than that on the old 117 network, or a router advertisement on the new network is received, 118 while communications with the old network's router time out, the host 119 should initiate the proceedures this document describes to transition 120 its existing connections to its IP address on the new network, update 121 its reachability bindings via a system such as dynamic DNS, and 122 release its old IP address. 124 Since there is never any indirection, as through a Mobile IP HA, 125 route optimization is implicit. There are also no concerns about 126 outgoing packets being filtered due to seemingly-spoofed source 127 addresses as in Mobile IP. as only topologically correct addresses 128 are used with transport layer mobility. 130 In flight packets sent to the mobile host before its address binding 131 update was received and after it has released its old IP address may 132 be lost and require retransmission. The problem of packets being 133 lost during the handoff between networks exists in Mobile IP as well. 134 We present a way to mitigate the problems this phenomenon causes for 135 transport layer mobility. 137 While existing connections are maintained, the host's reachability 138 for new connections must be provided by a service like dynamic DNS, 139 as in contrast to Mobile IP, a redirection agent like the HA is not 140 part of the transport layer mobility architecture. Slow convergence 141 of DNS records to new values might pose temporary reachability 142 problems for new connections attempting to reach the mobile host. 144 The TCP-based transport layer mobility solution described here only 145 allows one of the hosts in a TCP connection to move at a time, and 146 the moving host must either be in the ESTABLISHED or FIN-WAIT states 147 to do so. 149 A major advantage of using Mobile IP for mobility is that all 150 transport layer protocols using IP will transparently inherit 151 mobility support without modifications. The mobility method 152 presented in this document applies only to TCP, applications using 153 other transport protocols will not benefit from it. Proposals like 154 Mobile SCTP [9] are needed to give mobility support to other 155 transports. This is somewhat of a replication of effort that simply 156 using Mobile IP avoids. The transparency of Mobile IP handoffs and 157 triangle routes however may cause problems for transport layer 158 protocols that are not designed with the possibility of such 159 occurances in mind. The TCP extension presented here builds on 160 similar works such as the Migrate Internet Mobility Project [10] and 161 TCP-R [11]. 163 4. Mobility Negotiation 165 During TCP connection initiation, hosts negotiate whether or not the 166 mobility extension this document presents will be supported for use 167 during the connection. This is accomplished via exchange of the 168 connection key (Conn-Key) option (Figure 1) in the initial SYN and 169 SYN-ACK segments. The Conn-Key option is used to begin the exchange 170 of a 200 bit cryptographic key using the Elliptic Curve 171 Diffie-Hellman (ECDH) method [6]. The Conn-Key option carries the 172 first 9 bytes of the public key data, while the Conn-Key-Cont option 173 (Figure 2) on subsequent segments carries the remaining 16. The 174 public keys are split up over multiple segments in this way because 175 of the tight space limitations on TCP options (see Appendix A). ECDH 176 is used because it generates relatively short and strong keys. 178 The 200-bit public key is generated by selecting one of the 179 standardized sets of elliptic curve domain parameters (containing a 180 generating point P), and a secret random number X. The key, k, is 181 generated by scalar multiplication over the field specified by the 182 domain parameters via: k = X * P. The encoding of k should be 183 left-padded with zeros to reach 200 bits. The security of the key is 184 baed on the randomness in X's selection. The control block of the 185 connection should store X for use throughout the connection. Hosts 186 that use the SYN cookie technique [12] may not be able to use the 187 mobility methods presented here while they are under attack. Appendix 188 B lists some ways of reducing the overhead of the cryptographic 189 operations used by the mobility options presented in this document. 191 If a SYN segment initiating a connection does not carry the Conn-Key 192 option, then the SYN-ACK sent in response MUST NOT either, and the 193 mobility extension described in this document MUST be disabled for 194 the connection. Likewise if a host sends a SYN with the Conn-Key 195 option but receives a responding SYN-ACK without the Conn-Key option, 196 the mobility extension MUST be disabled and the Conn-Key-Cont option 197 MUST NOT be used to finish transmitting the key bits. 199 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Kind: # | Length = 12 | Curve ID | Key Data | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Key Data (cont.) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Key Data (cont.) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 TCP Connection Key (Conn-Key) Option 211 Figure 1 213 The Conn-Key option shown in Figure 1 has a kind field indicating it 214 is of type Conn-Key, a fixed length of 12 bytes, and a one-byte curve 215 ID used to specify a set of elliptic curve domain parameters per ANSI 216 X9.62 [6]. The first 9 bytes of key data are then included. The 217 remaining 16 bytes of the key data are transferred using 218 Conn-Key-Cont options as shown in Figure 2. 220 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Kind: # | Offset | Length | Key Data | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Key Data (cont.) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 ... 228 ... 230 TCP Connection Key Continued (Conn-Key-Cont) Option 232 Figure 2 234 The offset field in the Conn-Key-Cont option indicates the number of 235 bytes from the beginning of the key data at which the portion of key 236 data contained in this particular option begins. Since 9 bytes of 237 key data are always placed in the Conn-Key option, offset should 238 always be greater than eight. The Conn-Key-Cont options may be of 239 variable length to accomodate room for other TCP options. Ideally, 240 the 19 bytes required to transfer the entire remaining portion of the 241 key data would be available in the first segment after the one 242 carrying the Conn-Key option. In this case only a single 243 Conn-Key-Cont option need be sent. Otherwise, the remaining data can 244 be broken up amongst multiple Conn-Key-Cont options. If any segments 245 carrying either Conn-Key or Conn-Key-Cont options are retransmitted, 246 the retransmissions MUST include identical options to the original 247 transmissions. If a host receives inconsistent overlapping key data, 248 it MUST reset the connection. 250 After 200 bits of key data, k, have been received, a host can 251 generate the connection's shared secret key, K, via the scalar 252 multiplication over the selected field: K = k * X. When both sides 253 have finished the exchange, a shared secret cryptographic key is then 254 available for use in any number of TCP extensions. For transport 255 layer mobility, it is used to authenticate that a location update 256 indeed comes from the host that originally made the connection and is 257 not an attempted remote redirection attack. Potentially, the 258 exchanged key might be useful in other domains as well. 260 5. Location Updates 262 Once the full exchange of key data is successfully completed, either 263 host may change IP addresses freely without breaking the connection, 264 so long as they do not both do so simultaneously. 266 To minimize any problems with segments and acknowledgements being 267 sent by the remote host in time between when the old address is fully 268 released and the new one aquired, a host MAY anticipatorily pause the 269 transmission of any data segments its buffers hold and send an 270 advertised receive window of zero to pause the other host. This 271 technique could significantly reduce the possibility of lost segments 272 during the handover. 274 After a host changes addresses, it resets its congestion control 275 state to the intial slow-start conditions, [13], and resets its 276 estimates of RTT, RTTVAR, and RTO [14]. The mobile host then sends a 277 TCP segment with the SYN bit set and the Location Update (Loc-Update) 278 option. The SYN bit is set in order to allow the segment to pass 279 through NATs and stateful firewalls that will see the segment as 280 invalid because they haven't seen a SYN seeming to initiate the 281 connection yet. The sequence number of the segment should be that of 282 the last acknowledgement received. Any data transmitted above the 283 last acknowledgement before the address change will require 284 retransmission if not covered by SACK blocks. The acknowledgement 285 field in the SYN should indicate the last byte of data received. The 286 format of the Loc-Update option is shown in Figure 3. 288 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |///////////////| Kind: # | Length = 19 | ReqNo | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Token | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Token (cont.) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Request | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Request (cont.) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 TCP Location Update (Loc-Update) Option 304 Figure 3 306 Loc-Update options are fixed at 19 bytes. They contain a request 307 number (ReqNo), a token used to lookup the connection to be updated, 308 and a request that authenticates it. The token (T) consists of the 309 upper 64 bits of the SHA-1 hash [15] over the initial sequence number 310 of the original SYN segment that begun the connection (N_i), the 311 sequence number in the corresponding SYN-ACK (N_a), and the shared 312 secret key (K). It can be computed via: T = upper64(SHA-1(N_i, N_a, 313 K)), where upper64() selects the 64 most significant bits in the 314 160-bit value computed by the hash function SHA-1(). If observed by 315 a malicious host, this value is replayable, although since we do not 316 use it for authentication, but only for identification of a candidate 317 mobile connection, this is not a problem. The request (R) is 318 computed in a similar manner, except with the hash also covering the 319 sequence number of the SYN (S), and the request number, such that: R 320 = upper64(SHA-1(N_i, N_a, K, S, ReqNo)). The initial request number 321 may be chosen by the host sending the option in any manner desired, 322 so long as it is incremented by one every time that a location update 323 is sent. The request number rolls back to zero after reaching its 324 maximum value. 326 Upon receiving a SYN carrying a location update, a host first 327 attempts to look up the token it contains. If the token does not 328 belong to any known connections, the segment is immediately rejected 329 and no response is sent. If the token does match a known connection, 330 then the request can be validated by computing the hash and comparing 331 it to the received value. If the values match, then the host resets 332 its state in the same manner specified for the sender of the 333 Loc-Update option, and the remote host's address and port number are 334 updated in the control block. The SYN should be acknowledged with a 335 SYN-ACK carrying the sequence number of the acknowledgment field in 336 the SYN segment. Data above this point will require retransmission 337 if not covered by a SACK block. Updating the remote port number 338 normally shouldn't be necessary, however it might be required in case 339 the new IP address is behind a NAT, and it doesn't cause any 340 additional difficult, so we do it by default. 342 On receiving the SYN-ACK, the host that sent the location update 343 resumes normal operation. Either side may change addresses again at 344 this point. 346 6. State Machine Changes 348 There is a possibility of connections from being accidentally closed 349 by stray segments sent during a mobile host's handover between 350 networks. To prevent this, when the mobility options are used on a 351 connection, then a transition is added between the ESTABLISHED state 352 and TIME-WAIT on the reception of a RST. and the TIME-WAIT state is 353 slightly modified to contain a transition back to ESTABLISHED if a 354 valid request in a Loc-Update option is received before the timeout, 355 These transitions need not be added for connections that do not use 356 the mobility options defined in this document. To motivate these 357 changes, we provide an example. 359 Consider the scenario where a mobile host, MH, is temporarily bound 360 to address A and has an active connection with a corresponding host 361 CH. MH moves off of the network A belongs to, and before it is able 362 to get a new address, A is reaped and reassigned to another host. 363 Since CH hasn't seen a location update from MH, it still sends 364 segments addressed to A. The new host now bound to A has no 365 knowledge of the connection and replies with a RST. This would 366 normally cause CH to immediately close the connection. CH should, 367 however, instead take the RST as meaning that the MH has possibly 368 moved and go into the TIME-WAIT state. The transition to the 369 modified TIME-WAIT state SHOULD occur if the mobility extensions 370 described in this document are enabled. 372 7. Security Considerations 374 The authentication mechanism used for location updates is based on 375 the initial ECDH key exchange and a SHA-1 hash. Any presently 376 unknown vulnerabilities in ECDH or SHA-1 may make the source of 377 location updates less certain and open a connection with these 378 extensions up to remote redirection attacks. 380 The TCP extensions described in this document contribute additional 381 state per connection. This makes hosts implementing them more 382 vulnerable to SYN flood attacks. Some of the implementation 383 techniques in Appendix B may be helpful in reducing the impact these 384 extensions cause. 386 8 References 388 [1] Postel, J., "Transmission Control Protocol", RFC 793, September 389 1981. 391 [2] Snoeren, A., Andersen, D. and H. Balakrishnan, "Fine-Grained 392 Failover Using Connection Migration", Proc. of the Third Annual 393 USENIX Symposium on Internet Technologies and Systems (USITS), 394 March 2001. 396 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 397 2002. 399 [4] Montenegro, G., "Reverse Tunneling for Mobile IP, Revised", RFC 400 3024, January 2001. 402 [5] Hain, T., "Architectural Implications of NAT", RFC 2993, 403 November 2000. 405 [6] American National Standards Institute, "Public Key Cryptography 406 for the Financial Security Industry", ANSI X9.62, January 1999. 408 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 409 March 1997. 411 [8] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 412 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 413 April 1997. 415 [9] Koh, S., Lee, M., Riegel, M., Ma, M. and M. Tuexen, "Dynamic 416 Host Configuration Protocol", draft-sjkok-sctp-mobility-03 417 (work in progress), February 2004. 419 [10] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to 420 Host Mobility", Proc. of the Sixth Annual ACM/IEEE 421 International Conference on Mobile Computing and Networking, 422 August 2000. 424 [11] Funato, D., Yasuda, K. and H. Tokuda, "TCP-R: TCP Mobility 425 Support for Continuous Operation", International Conference on 426 Network Protocols (ICNP), October 1997. 428 [12] Bernstein, D., "SYN cookies", September 1996. 430 [13] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 431 Control", RFC 2581, April 1999. 433 [14] Paxson, V. and M. Allman, "Computing TCP's Retransmission 434 Timer", RFC 2988, November 2000. 436 [15] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 437 RFC 3174, September 2001. 439 [16] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for 440 High Performance", RFC 1323, May 1992. 442 [17] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 443 Selective Acknowledgement Options", RFC 2018, October 1996. 445 Author's Address 447 Wesley M. Eddy 448 NASA GRC/Verizon FNS 450 EMail: weddy@grc.nasa.gov 452 Appendix A. Differences From the Migrate-Permitted Option 454 While based on Snoeren et al's Migrate work [10], the exchange of key 455 data described in this document has two main differences, (1) we 456 leave some space open in the SYN and SYN-ACK's TCP headers for 457 additional options, and (2) we do not overload the meaning of data in 458 the time-stamp and time-stamp echo fields on those packets. 460 The maximum number of bytes that can be used for TCP options is 40. 461 This limitation comes from the 4-bit length of the Data Offset field 462 of the TCP header [1]. The maximum value this field can encode is 463 15, which represents the number of 4-byte quantities in the TCP 464 header. Thus, the maximum TCP header is 60 bytes. Since the fixed 465 length fields take up 20 bytes, this leaves 40 bytes for options. 467 In addition to the Conn-Key option, there are several other TCP 468 options which must be present in the initial SYN and SYN-ACK segments 469 in order for their features to be used on a connection. At this 470 time, the defined TCP options sharing this property are MSS [1], 471 window scale [16], timestamp [16], and selective acknowledgements 472 permitted [17]. Based on the lengths of these previously defined 473 options alone (MSS = 4 bytes, window scale = 3 bytes, timestamp = 10 474 bytes, and selective acknowledgements permitted = 2 bytes, total = 19 475 bytes), there are only 21 bytes available for other options that must 476 go into the SYN packets. The originally-proposed Migrate-Permitted 477 Option [10] used 20 of these, leaving only a single byte free, which 478 is not enough for even a single other option, given the minium option 479 length of two bytes (one for kind and one for length). 481 There is a resulting inability (or at least extreme difficulty) 482 involved in defining future TCP options compatible with the 483 simultaneous use of the Migrate-Permitted Option and previous 484 options. To mitigate this, we have spread the key data originally 485 exchanged via this option out over two segments with the Conn-Key and 486 Conn-Key-Cont options. A downside to this is that an extra RTT is 487 imposed upon the exchange of key data, meaning a mobile host cannot 488 change addresses for two full RTTs after it initiates a connection by 489 sending a SYN, and one RTT after receiving a SYN and sending a 490 SYN-ACK. This does not seem like an unreasonable restriction. The 491 benefit obtained by this key data encoding is that it leaves some 492 room for new TCP options that may require negotiation at connection 493 startup. 495 The original Migrate-Permitted Option also required the presence of 496 the timestamp option and used 8 of the timestamp option's bytes to 497 encode key data. This was a reasonable approach since the timestamp 498 data in the SYN and SYN-ACK segments was not to be used (at least for 499 RTTM and PAWS) anyways [16]. However, this approach does not leave 500 open the possibility that later TCP extensions may have better use 501 for these fields, perhaps even a use more closely aligned with their 502 purpose as timestamps than as key data. By removing the 8 bytes of 503 key data encoded as timestamps by the Migrate-Permitted option and 504 moving them into the Conn-Key option, we impose the transmission of 505 an additional 8 bytes per direction upon startup of a TCP connection. 506 This should have little noticable effect on TCP performance. 508 Appendix B. Overhead Reduction 510 The overhead of running cryptographic routines is typically much 511 greater than normal for common TCP implementations. We describe some 512 possible approaches to minimizing this overhead. 514 An easy means of preventing the overhead of these options from being 515 an issues is to only enable the mobility options by an applications 516 request. In this way, typically short-lived applications like 517 name-lookup and remote procedure calls may elect not to have the 518 mobility options enabled. Such short-lived connections are the ones 519 where the additional cryptographic routine latency would be most 520 problematic and that would benefit from mobility the least, as the 521 potential for movement across networks will be small over the short 522 lifetimes of connections. Typically more long-lived applications 523 like file transfer or remote shells would, in contrast, be less 524 adversely affected by a small additional amount of startup delay and 525 would be more prone to mobility-induced disconnection during the 526 connections lifetime, and so such flows could select to enable the 527 options described in this document. 529 The security of the ECDH key exchange depends on selection of a good 530 random number X. Presently, generation of good random numbers is a 531 particularly time-consuming operation. To lessen the latency that 532 on-demand generation of X values would impose, it should be 533 sufficient to pre-generate a list of X values to be used for 534 connections in the near future. A single value of X might also be 535 shared by a small number of connections, although this approach 536 should only be taken if absolutely required, as it provides more 537 information about X to eavesdropping hosts. 539 The validation tokens used to identify that a SYN carrying a location 540 update refers to a particular connection SHOULD be precomputed and 541 are stable over the lifetime of a connection. An efficient data 542 structure for looking these up MAY be implemented. 544 Intellectual Property Statement 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the IETF's procedures with respect to rights in IETF Documents can 553 be found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Disclaimer of Validity 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Copyright Statement 580 Copyright (C) The Internet Society (2004). This document is subject 581 to the rights, licenses and restrictions contained in BCP 78, and 582 except as set forth therein, the authors retain all their rights. 584 Acknowledgment 586 Funding for the RFC Editor function is currently provided by the 587 Internet Society.