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]