[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            W. Eddy
Internet-Draft                                      NASA GRC/Verizon FNS
Expires: October 6, 2004                                   April 7, 2004


                        Mobility Support For TCP
                       draft-eddy-tcp-mobility-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 6, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   Once a TCP connection is established, there are no mechanisms for
   dynamically rebinding the connection to new IP addresses or port
   numbers.  During the lifetime of a TCP connection, a mobile host's
   transition between networks (and the corresponding change in its IP
   address) will break any established TCP connections.  As a remedy,
   this document presents an extension of TCP with support for dynamic
   bindings of IP addresses and port numbers.  Compatibility with
   existing TCP implementations is maintained, and reasonable steps are
   taken to prevent remote-redirction attacks.





Eddy                    Expires October 6, 2004                 [Page 1]

Internet-Draft                TCP Mobility                    April 2004


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.














































Eddy                    Expires October 6, 2004                 [Page 2]

Internet-Draft                TCP Mobility                    April 2004


2.  Introduction

   A TCP connection is an association between two pairs of IP address
   and TCP port number identifiers [1].  None of these four values may
   change at any point over the lifetime of a TCP connection.  Host
   mobility across networks is a problem that motivates a change to this
   policy, so that a connection end may be rebound to a new IP addresses
   and TCP port number without requiring re-establishment.  While this
   feature might also be useful in load balancing scenarios, enabling a
   busy host to shed some of its connections to another host [2], only
   the mobility problem is specifically dealt with here.

   This document describes a set of TCP options for dynamic rebinding of
   TCP connection ends.  This is accomplished without breaking
   compatibility with TCP implementations that do not implement these
   options, and in a manner robust against connection hijacking or
   remote-redirection attacks, in which some malicious host attempts to
   change the address bindings of a connection belonging to another
   host.

   For mobility in today's Internet, simply using Mobile IP [3]
   underneath TCP is not an adequate solution.  The Home and Foreign
   Agents (HAs and FAs) that constitute the Mobile IP infrastructure are
   not ubiquitously deployed, leaving helpless mobile hosts that either
   originate in networks lacking an HA or move into networks lacking an
   FA.  Although the need for an FA is mitigated by using colocated
   care-of addresses in Mobile IP. this document presents a solution
   that removes the need for both HAs and FAs.  Furthermore, the current
   Mobile IP standard has no provisions for route-optimization, which
   would remove the less-efficient side of the triangle routes
   constructed by Mobile IP.  Current Internet security practices at
   many locations actually require the use of Mobile IP's
   topologically-correct tunnel extension [4], which uses the less
   efficient indirect route through the HA in both directions.  This
   document describes a solution of which route optimization is an
   inherrent property.  Stateful firewalls and Network Address
   translators (NATs) [5] also do not pose problems to the mobility
   mechanism presented here.

   The Mobility Support options for TCP described here allow a host
   whose IP address has changed to identify itself with a cryptographic
   cookie and have its TCP connections redirected to the new address.
   The use of Elliptic Curve Diffie Hellman key exchange [6] to create
   the cookie secures this technique against remote-redirection attacks.







Eddy                    Expires October 6, 2004                 [Page 3]

Internet-Draft                TCP Mobility                    April 2004


3.  Transport Layer Mobility Architecture

   The term "transport layer mobility" is used to describe an
   architecture for mobility where there is no need for additional
   network infrastructure beyond traditional IP routers, an automated
   method of acquiring IP addresses such as the Dynamic Host
   Configuration Protocol (DHCP) [7]  (which is widely deployed), and a
   means for maintaining host reachability across address changes such
   as dynamic DNS [8].

   A host employing tranport layer mobility may have either a single
   network interface or multiple interfaces.  The host must have some
   means of knowing when it has moved onto a new IP network. This might
   be accomplished by receiving a router advertisement from the new
   network.  The mobile host may then use a means such as DHCP to obtain
   an IP address on the new network.  At some point when either the
   signal strength on the new network is stronger than that on the old
   network, or a router advertisement on the new network is received,
   while communications with the old network's router time out, the host
   should initiate the proceedures this document describes to transition
   its existing connections to its IP address on the new network, update
   its reachability bindings via a system such as dynamic DNS, and
   release its old IP address.

   Since there is never any indirection, as through a Mobile IP HA,
   route optimization is implicit.  There are also no concerns about
   outgoing packets being filtered due to seemingly-spoofed source
   addresses as in Mobile IP. as only topologically correct addresses
   are used with transport layer mobility.

   In flight packets sent to the mobile host before its address binding
   update was received and after it has released its old IP address may
   be lost and require retransmission.  The problem of packets being
   lost during the handoff between networks exists in Mobile IP as well.
   We present a way to mitigate the problems this phenomenon causes for
   transport layer mobility.

   While existing connections are maintained, the host's reachability
   for new connections must be provided by a service like dynamic DNS,
   as in contrast to Mobile IP, a redirection agent like the HA is not
   part of the transport layer mobility architecture.  Slow convergence
   of DNS records to new values might pose temporary reachability
   problems for new connections attempting to reach the mobile host.

   The TCP-based transport layer mobility solution described here only
   allows one of the hosts in a TCP connection to move at a time, and
   the moving host must either be in the ESTABLISHED or FIN-WAIT states
   to do so.



Eddy                    Expires October 6, 2004                 [Page 4]

Internet-Draft                TCP Mobility                    April 2004


   A major advantage of using Mobile IP for mobility is that all
   transport layer protocols using IP will transparently inherit
   mobility support without modifications.  The mobility method
   presented in this document applies only to TCP, applications using
   other transport protocols will not benefit from it. Proposals like
   Mobile SCTP [9] are needed to give mobility support to other
   transports.  This is somewhat of a replication of effort that simply
   using Mobile IP avoids.  The transparency of Mobile IP handoffs and
   triangle routes however may cause problems for transport layer
   protocols that are not designed with the possibility of such
   occurances in mind.  The TCP extension presented here builds on
   similar works such as the Migrate Internet Mobility Project [10] and
   TCP-R [11].






































Eddy                    Expires October 6, 2004                 [Page 5]

Internet-Draft                TCP Mobility                    April 2004


4.  Mobility Negotiation

   During TCP connection initiation, hosts negotiate whether or not the
   mobility extension this document presents will be supported for use
   during the connection.  This is accomplished via exchange of the
   connection key (Conn-Key) option (Figure 1) in the initial SYN and
   SYN-ACK segments. The Conn-Key option is used to begin the exchange
   of a 200 bit cryptographic key using the Elliptic Curve
   Diffie-Hellman (ECDH) method [6].  The Conn-Key option carries the
   first 9 bytes of the public key data, while the Conn-Key-Cont option
   (Figure 2) on subsequent segments carries the remaining 16.  The
   public keys are split up over multiple segments in this way because
   of the tight space limitations on TCP options (see Appendix A).  ECDH
   is used because it generates relatively short and strong keys.

   The 200-bit public key is generated by selecting one of the
   standardized sets of elliptic curve domain parameters (containing a
   generating point P), and a secret random number X.  The key, k, is
   generated by scalar multiplication over the field specified by the
   domain parameters via: k = X * P.  The encoding of k should be
   left-padded with zeros to reach 200 bits.  The security of the key is
   baed on the randomness in X's selection.  The control block of the
   connection should store X for use throughout the connection.  Hosts
   that use the SYN cookie technique [12] may not be able to use the
   mobility methods presented here while they are under attack. Appendix
   B lists some ways of reducing the overhead of the cryptographic
   operations used by the mobility options presented in this document.

   If a SYN segment initiating a connection does not carry the Conn-Key
   option, then the SYN-ACK sent in response MUST NOT either, and the
   mobility extension described in this document MUST be disabled for
   the connection.  Likewise if a host sends a SYN with the Conn-Key
   option but receives a responding SYN-ACK without the Conn-Key option,
   the mobility extension MUST be disabled and the Conn-Key-Cont option
   MUST NOT be used to finish transmitting the key bits.
















Eddy                    Expires October 6, 2004                 [Page 6]

Internet-Draft                TCP Mobility                    April 2004


                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Kind: #    | Length = 12   |    Curve ID   |    Key Data   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Key Data (cont.)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Key Data (cont.)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TCP Connection Key (Conn-Key) Option

                                Figure 1

   The Conn-Key option shown in Figure 1 has a kind field indicating it
   is of type Conn-Key, a fixed length of 12 bytes, and a one-byte curve
   ID used to specify a set of elliptic curve domain parameters per ANSI
   X9.62 [6].  The first 9 bytes of key data are then included.  The
   remaining 16 bytes of the key data are transferred using
   Conn-Key-Cont options as shown in Figure 2.

                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Kind: #    |    Offset     |    Length     |  Key  Data    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Key Data (cont.)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  ...
                                  ...

   TCP Connection Key Continued (Conn-Key-Cont) Option

                                Figure 2

   The offset field in the Conn-Key-Cont option indicates the number of
   bytes from the beginning of the key data at which the portion of key
   data contained in this particular option begins.  Since 9 bytes of
   key data are always placed in the Conn-Key option, offset should
   always be greater than eight.  The Conn-Key-Cont options may be of
   variable length to accomodate room for other TCP options.  Ideally,
   the 19 bytes required to transfer the entire remaining portion of the
   key data would be available in the first segment after the one
   carrying the Conn-Key option.  In this case only a single
   Conn-Key-Cont option need be sent.  Otherwise, the remaining data can
   be broken up amongst multiple Conn-Key-Cont options.  If any segments
   carrying either Conn-Key or Conn-Key-Cont options are retransmitted,
   the retransmissions MUST include identical options to the original



Eddy                    Expires October 6, 2004                 [Page 7]

Internet-Draft                TCP Mobility                    April 2004


   transmissions.  If a host receives inconsistent overlapping key data,
   it MUST reset the connection.

   After 200 bits of key data, k, have been received, a host can
   generate the connection's shared secret key, K, via the scalar
   multiplication over the selected field: K = k * X.  When both sides
   have finished the exchange, a shared secret cryptographic key is then
   available for use in any number of TCP extensions.  For transport
   layer mobility, it is used to authenticate that a location update
   indeed comes from the host that originally made the connection and is
   not an attempted remote redirection attack.  Potentially, the
   exchanged key might be useful in other domains as well.







































Eddy                    Expires October 6, 2004                 [Page 8]

Internet-Draft                TCP Mobility                    April 2004


5.  Location Updates

   Once the full exchange of key data is successfully completed, either
   host may change IP addresses freely without breaking the connection,
   so long as they do not both do so simultaneously.

   To minimize any problems with segments and acknowledgements being
   sent by the remote host in time between when the old address is fully
   released and the new one aquired, a host MAY anticipatorily pause the
   transmission of any data segments its buffers hold and send an
   advertised receive window of zero to pause the other host.  This
   technique could significantly reduce the possibility of lost segments
   during the handover.

   After a host changes addresses, it resets its congestion control
   state to the intial slow-start conditions, [13], and resets its
   estimates of RTT, RTTVAR, and RTO [14].  The mobile host then sends a
   TCP segment with the SYN bit set and the Location Update (Loc-Update)
   option. The SYN bit is set in order to allow the segment to pass
   through NATs and stateful firewalls that will see the segment as
   invalid because they haven't seen a SYN seeming to initiate the
   connection yet.  The sequence number of the segment should be that of
   the last acknowledgement received.  Any data transmitted above the
   last acknowledgement before the address change will require
   retransmission if not covered by SACK blocks.  The acknowledgement
   field in the SYN should indicate the last byte of data received.  The
   format of the Loc-Update option is shown in Figure 3.

                        1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |///////////////|    Kind: #    |  Length = 19  |     ReqNo     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Token                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Token (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Request                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request (cont.)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TCP Location Update (Loc-Update) Option

                                Figure 3

   Loc-Update options are fixed at 19 bytes.  They contain a request
   number (ReqNo), a token used to lookup the connection to be updated,



Eddy                    Expires October 6, 2004                 [Page 9]

Internet-Draft                TCP Mobility                    April 2004


   and a request that authenticates it.  The token (T) consists of the
   upper 64 bits of the SHA-1 hash [15] over the initial sequence number
   of the original SYN segment that begun the connection (N_i), the
   sequence number in the corresponding SYN-ACK (N_a), and the shared
   secret key (K).  It can be computed via: T = upper64(SHA-1(N_i, N_a,
   K)), where upper64() selects the 64 most significant bits in the
   160-bit value computed by the hash function SHA-1().  If observed by
   a malicious host, this value is replayable, although since we do not
   use it for authentication, but only for identification of a candidate
   mobile connection, this is not a problem.  The request (R) is
   computed in a similar manner, except with the hash also covering the
   sequence number of the SYN (S), and the request number, such that: R
   = upper64(SHA-1(N_i, N_a, K, S, ReqNo)).  The initial request number
   may be chosen by the host sending the option in any manner desired,
   so long as it is incremented by one every time that a location update
   is sent.  The request number rolls back to zero after reaching its
   maximum value.

   Upon receiving a SYN carrying a location update, a host first
   attempts to look up the token it contains.  If the token does not
   belong to any known connections, the segment is immediately rejected
   and no response is sent.  If the token does match a known connection,
   then the request can be validated by computing the hash and comparing
   it to the received value.  If the values match, then the host resets
   its state in the same manner specified for the sender of the
   Loc-Update option, and the remote host's address and port number are
   updated in the control block.  The SYN should be acknowledged with a
   SYN-ACK carrying the sequence number of the acknowledgment field in
   the SYN segment.  Data above this point will require retransmission
   if not covered by a SACK block.  Updating the remote port number
   normally shouldn't be necessary, however it might be required in case
   the new IP address is behind a NAT, and it doesn't cause any
   additional difficult, so we do it by default.

   On receiving the SYN-ACK, the host that sent the location update
   resumes normal operation.  Either side may change addresses again at
   this point.














Eddy                    Expires October 6, 2004                [Page 10]

Internet-Draft                TCP Mobility                    April 2004


6.  State Machine Changes

   There is a possibility of connections from being accidentally closed
   by stray segments sent during a mobile host's handover between
   networks.  To prevent this, when the mobility options are used on a
   connection, then a transition is added between the ESTABLISHED state
   and TIME-WAIT on the reception of a RST. and the TIME-WAIT state is
   slightly modified to contain a transition back to ESTABLISHED if a
   valid request in a Loc-Update option is received before the timeout,
   These transitions need not be added for connections that do not use
   the mobility options defined in this document.  To motivate these
   changes, we provide an example.

   Consider the scenario where a mobile host, MH, is temporarily bound
   to address A and has an active connection with a corresponding host
   CH.  MH moves off of the network A belongs to, and before it is able
   to get a new address, A is reaped and reassigned to another host.
   Since CH hasn't seen a location update from MH, it still sends
   segments addressed to A.  The new host now bound to A has no
   knowledge of the connection and replies with a RST.  This would
   normally cause CH to immediately close the connection.  CH should,
   however, instead take the RST as meaning that the MH has possibly
   moved and go into the TIME-WAIT state.  The transition to the
   modified TIME-WAIT state SHOULD occur if the mobility extensions
   described in this document are enabled.


























Eddy                    Expires October 6, 2004                [Page 11]

Internet-Draft                TCP Mobility                    April 2004


7.  Security Considerations

   The authentication mechanism used for location updates is based on
   the initial ECDH key exchange and a SHA-1 hash.  Any presently
   unknown vulnerabilities in ECDH or SHA-1 may make the source of
   location updates less certain and open a connection with these
   extensions up to remote redirection attacks.

   The TCP extensions described in this document contribute additional
   state per connection.  This makes hosts implementing them more
   vulnerable to SYN flood attacks.  Some of the implementation
   techniques in Appendix B may be helpful in reducing the impact these
   extensions cause.

8  References

   [1]   Postel, J., "Transmission Control Protocol", RFC 793, September
         1981.

   [2]   Snoeren, A., Andersen, D. and H. Balakrishnan, "Fine-Grained
         Failover Using Connection Migration", Proc. of the Third Annual
         USENIX Symposium on Internet Technologies and Systems (USITS),
         March 2001.

   [3]   Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January
         2002.

   [4]   Montenegro, G., "Reverse Tunneling for Mobile IP, Revised", RFC
         3024, January 2001.

   [5]   Hain, T., "Architectural Implications of NAT", RFC 2993,
         November 2000.

   [6]   American National Standards Institute, "Public Key Cryptography
         for the Financial Security Industry", ANSI X9.62, January 1999.

   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [8]   Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [9]   Koh, S., Lee, M., Riegel, M., Ma, M. and M. Tuexen, "Dynamic
         Host Configuration Protocol", draft-sjkok-sctp-mobility-03
         (work in progress), February 2004.

   [10]  Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to



Eddy                    Expires October 6, 2004                [Page 12]

Internet-Draft                TCP Mobility                    April 2004


         Host Mobility", Proc. of the Sixth Annual ACM/IEEE
         International Conference on Mobile Computing and Networking,
         August 2000.

   [11]  Funato, D., Yasuda, K. and H. Tokuda, "TCP-R: TCP Mobility
         Support for Continuous Operation", International Conference on
         Network Protocols (ICNP), October 1997.

   [12]  Bernstein, D., "SYN cookies", September 1996.

   [13]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
         Control", RFC 2581, April 1999.

   [14]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
         Timer", RFC 2988, November 2000.

   [15]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
         RFC 3174, September 2001.

   [16]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
         High Performance", RFC 1323, May 1992.

   [17]  Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
         Selective Acknowledgement Options", RFC 2018, October 1996.


Author's Address

   Wesley M. Eddy
   NASA GRC/Verizon FNS

   EMail: weddy@grc.nasa.gov



















Eddy                    Expires October 6, 2004                [Page 13]

Internet-Draft                TCP Mobility                    April 2004


Appendix A.  Differences From the Migrate-Permitted Option

   While based on Snoeren et al's Migrate work [10], the exchange of key
   data described in this document has two main differences, (1) we
   leave some space open in the SYN and SYN-ACK's TCP headers for
   additional options, and (2) we do not overload the meaning of data in
   the time-stamp and time-stamp echo fields on those packets.

   The maximum number of bytes that can be used for TCP options is 40.
   This limitation comes from the 4-bit length of the Data Offset field
   of the TCP header [1].  The maximum value this field can encode is
   15, which represents the number of 4-byte quantities in the TCP
   header.  Thus, the maximum TCP header is 60 bytes.  Since the fixed
   length fields take up 20 bytes, this leaves 40 bytes for options.

   In addition to the Conn-Key option, there are several other TCP
   options which must be present in the initial SYN and SYN-ACK segments
   in order for their features to be used on a connection.  At this
   time, the defined TCP options sharing this property are MSS [1],
   window scale [16], timestamp [16], and selective acknowledgements
   permitted [17].  Based on the lengths of these previously defined
   options alone (MSS = 4 bytes, window scale = 3 bytes, timestamp = 10
   bytes, and selective acknowledgements permitted = 2 bytes, total = 19
   bytes), there are only 21 bytes available for other options that must
   go into the SYN packets.  The originally-proposed Migrate-Permitted
   Option [10] used 20 of these, leaving only a single byte free, which
   is not enough for even a single other option, given the minium option
   length of two bytes (one for kind and one for length).

   There is a resulting inability (or at least extreme difficulty)
   involved in defining future TCP options compatible with the
   simultaneous use of the Migrate-Permitted Option and previous
   options.  To mitigate this, we have spread the key data originally
   exchanged via this option out over two segments with the Conn-Key and
   Conn-Key-Cont options.  A downside to this is that an extra RTT is
   imposed upon the exchange of key data, meaning a mobile host cannot
   change addresses for two full RTTs after it initiates a connection by
   sending a SYN, and one RTT after receiving a SYN and sending a
   SYN-ACK.  This does not seem like an unreasonable restriction.  The
   benefit obtained by this key data encoding is that it leaves some
   room for new TCP options that may require negotiation at connection
   startup.

   The original Migrate-Permitted Option also required the presence of
   the timestamp option and used 8 of the timestamp option's bytes to
   encode key data. This was a reasonable approach since the timestamp
   data in the SYN and SYN-ACK segments was not to be used (at least for
   RTTM and PAWS) anyways [16].  However, this approach does not leave



Eddy                    Expires October 6, 2004                [Page 14]

Internet-Draft                TCP Mobility                    April 2004


   open the possibility that later TCP extensions may have better use
   for these fields, perhaps even a use more closely aligned with their
   purpose as timestamps than as key data.  By removing the 8 bytes of
   key data encoded as timestamps by the Migrate-Permitted option and
   moving them into the Conn-Key option, we impose the transmission of
   an additional 8 bytes per direction upon startup of a TCP connection.
   This should have little noticable effect on TCP performance.












































Eddy                    Expires October 6, 2004                [Page 15]

Internet-Draft                TCP Mobility                    April 2004


Appendix B.  Overhead Reduction

   The overhead of running cryptographic routines is typically much
   greater than normal for common TCP implementations.  We describe some
   possible approaches to minimizing this overhead.

   An easy means of preventing the overhead of these options from being
   an issues is to only enable the mobility options by an applications
   request.  In this way, typically short-lived applications like
   name-lookup and remote procedure calls may elect not to have the
   mobility options enabled.  Such short-lived connections are the ones
   where the additional cryptographic routine latency would be most
   problematic and that would benefit from mobility the least, as the
   potential for movement across networks will be small over the short
   lifetimes of connections.  Typically more long-lived applications
   like file transfer or remote shells would, in contrast, be less
   adversely affected by a small additional amount of startup delay and
   would be more prone to mobility-induced disconnection during the
   connections lifetime, and so such flows could select to enable the
   options described in this document.

   The security of the ECDH key exchange depends on selection of a good
   random number X.  Presently, generation of good random numbers is a
   particularly time-consuming operation.  To lessen the latency that
   on-demand generation of X values would impose, it should be
   sufficient to pre-generate a list of X values to be used for
   connections in the near future.  A single value of X might also be
   shared by a small number of connections, although this approach
   should only be taken if absolutely required, as it provides more
   information about X to eavesdropping hosts.

   The validation tokens used to identify that a SYN carrying a location
   update refers to a particular connection SHOULD be precomputed and
   are stable over the lifetime of a connection.  An efficient data
   structure for looking these up MAY be implemented.
















Eddy                    Expires October 6, 2004                [Page 16]

Internet-Draft                TCP Mobility                    April 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Eddy                    Expires October 6, 2004                [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/