MIP4 Working Group V. Devarapalli Internet-Draft P. Eronen Expires: January 11, 2006 Nokia July 10, 2005 Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE draft-devarapalli-mip4-mobike-connectivity-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. Devarapalli & Eronen Expires January 11, 2006 [Page 1] Internet-Draft MIPv4 and MOBIKE interworking July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Access modes . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6 3.1.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . 6 3.1.3 Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 3.2 Mobility within the enterprise . . . . . . . . . . . . . . 7 3.3 Mobility when outside the enterprise . . . . . . . . . . . 7 3.4 Crossing Security Boundaries . . . . . . . . . . . . . . . 8 3.4.1 Operation when moving from an untrusted network . . . 8 3.4.2 Operation when moving from a trusted network . . . . . 9 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 A. Mobility Extensions for IKEv1 . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 14 Devarapalli & Eronen Expires January 11, 2006 [Page 2] Internet-Draft MIPv4 and MOBIKE interworking July 2005 1. Introduction A typical enterprise network consists of users connecting to the services from a trusted network (intranet), and from an untrusted network (Internet). The trusted and untrusted networks are, typically, separated by a DMZ. Access to the intranet is controlled by a firewall and a VPN gateway in the DMZ. Enterprise users, when roaming on untrusted networks, most often have to authenticate themselves to the VPN gateway and setup a secure tunnel in order to access the intranet. The use of IPsec VPNs is very common to enable such secure connectivity to the intranet. When the user is on the trusted network, VPNs are not used. However, the users benefit tremendously when session mobility between subnets, through the use of Mobile IPv4, is available. There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [10]. The solution described in [10] was designed with certain restrictions, including requiring no modifications to the VPN gateways and involves the use of two layers of MIPv4, with one Home Agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node. This document describes an alternate solution that does not require two layers of MIPv4. The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE capable IPsec VPNs when mobile node is on the untrusted network. The mobile node uses the tunnel inner address (TIA) given out by the IPsec VPN gateway as the co-located CoA for MIP registration. This eliminates the need for using an external mobile IP Home Agent and the need for encapsulating the VPN tunnel inside a MIP tunnel. The following assumptions are made for the solution described in this document. o IKEv2 [4] and IPsec [5] are used to setup the VPN tunnels between the mobile node and the VPN gateway. o The VPN gateway and the mobile node support MOBIKE extensions as defined in [3]. o When the mobile node is on the trusted network, traffic should not go through the DMZ. Current deployments of firewalls and DMZs consider the scenario where only a small amount of the total enterprise traffic goes through the DMZ. Routing through the DMZ, typically, involves stateful inspection of each packet by the firewalls in the DMZ. Devarapalli & Eronen Expires January 11, 2006 [Page 3] Internet-Draft MIPv4 and MOBIKE interworking July 2005 o When the mobile node is on the trusted network and uses a wireless access technology, confidentiality protection of the data traffic is provided by the particular access technology. In some networks, confidentiality protection MAY be available between the mobile node and the first hop access router, in which case, it is not required at layer 2. Mobility extensions are IKEv2 are being standardized. There is no similar effort for IKEv1 [6]. This document also presents a solution for the mobile node to detect when it is on a trusted network, so that the IPsec tunnel can be dropped and the mobile node can use Mobile IP in the intranet. 2. Terminology Many of the following terms are defined in [10], but are repeated here to make this document self-contained. FA: Mobile IPv4 foreign agent co-CoA: co-located Care-of address FA-CoA: Foreign Agent Care-of address FW: Firewall i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) network i-HA: Mobile IPv4 home agent residing in the trusted (intranet) network i-MIP: The mobile node uses the home agent in the internal network VPN-TIA: VPN tunnel inner address. This address is given out by the VPN gateway during IKE negotiation and is routable in the trusted network mVPN: VPN with MOBIKE functionality The following access modes are used in explaining the protocol. The access modes are explained in more detail in [10]. f: i-MIP with FA-CoA c: i-MIP with co-CoA mc: mobile enhanced VPN, i-MIP with VPN_TIA has co-CoA Devarapalli & Eronen Expires January 11, 2006 [Page 4] Internet-Draft MIPv4 and MOBIKE interworking July 2005 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 [1]. 3. Solution Overview The mobile node is configured with a home address that remains the same irrespective of whether the mobile node is outside or inside the enterprise network. The mobile node is also reachable at the same home address irrespective of its current point of attachment. When the mobile node is connected to the intranet directly, it uses Mobile IP for internal mobility. When it roams and connects to an untrusted network outside the enterprise, it sets up a VPN tunnel to the VPN gateway. However, it still maintains a valid binding cache entry at the i-HA. It uses the VPN TIA, allocated by the VPN gateway, as the co-located CoA for registration with the i-HA. If the VPN TIA changes or if the mobile node moves and connects to another VPN gateway, then it sends a Registration Request to the i-HA using the new co-located CoA. If the mobile node moves while outside the enterprise and its access network changes, it uses the MOBIKE protocol to update the VPN gateway of its current address. The internal home agent is not aware of the mobile node's movement as long as the mobile node is attached to the same VPN gateway and the TIA remains the same. The following figure depicts the network topology assumed for the solution. It also shows the possible MN locations and access modes. Devarapalli & Eronen Expires January 11, 2006 [Page 5] Internet-Draft MIPv4 and MOBIKE interworking July 2005 (MN) {mc} {home} (MN) [i-HA] ! \ / .--+---. .-+---+-. ( ) ( ) `--+---' [MVPN] `--+----' \ ! ! [R/FA] .--+--. [R] \ ( DMZ ) ! .-+-------+--. `--+--' .-----+------. ( ) ! ( ) ( external net +---[R]----[FW]----[R]--+ internal net ) ( ) ( ) `--+---------' `---+---+----' / / \ [DHCP] [R] [DHCP] [R] [R] [i-FA] \ / \ / \ / .+--+---. .-+-+--. .--+--+-. ( ) ( ) ( ) `---+---' `--+---' `---+---' ! ! ! (MN) {mc} (MN) {c} (MN) {f} This results in a Mobile IP tunnel inside an IPsec tunnel. The Mobile IP tunnel is between the MN and the Home Agent and the IPsec tunnel is between the MN and the mVPN gateway. The Mobile IP tunnel uses reverse tunneling through the Home Agent [12]. 3.1 Access modes The following access modes are used in the solution described in this document. 3.1.1 Access mode: 'c' This access mode is standard Mobile IPv4 [2] with a co-located care-of address. The mobile node MUST be able to detect that it is connected to an internal trusted network before using this mode. The co-located care-of address is configured form the access network to which the mobile node is attached to. 3.1.2 Access mode: 'f' This access mode is standard Mobile IPv4 [2] with a FA-located care-of address. The mobile node can use this mode only when it is able to detect that it is connected to an internal trusted network and detects a foreign agent on the access network. Devarapalli & Eronen Expires January 11, 2006 [Page 6] Internet-Draft MIPv4 and MOBIKE interworking July 2005 3.1.3 Access mode: 'mc' This access mode involves using both Mobile IPv4 and MOBIKE enabled IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec tunnel. The mobile node uses the IPsec TIA as the co-located CoA for registering with the Home Agent. This mode is used only when the mobile node is attached to an untrusted network and is required to setup an IPsec tunnel with a VPN gateway to gain access to the trusted network. 3.2 Mobility within the enterprise When the mobile node is inside the enterprise network and attached to the intranet, it uses Mobile IPv4 [2] for subnet mobility. The mobile node uses Foreign Agent co-located care-of address, if a foreign agent is available. Otherwise it acquires an address through DHCP on the access link and uses it as the care-of address (CoA) for Mobile IP. The mobile node attempts Foreign Agent discovery and CoA address acquisition through DHCP simultaneously in order to avoid the delay in discovering a foreign agent when there is no foreign agent available. The mobile node at any time maintains a valid binding cache entry that maps the home address to the current CoA, at the Home Agent. Whenever the mobile node moves, it sends a Registration Request to update the binding cache entry. The Mobile IP signaling messages between the mobile node and the Home Agent are authenticated as described in [2]. When the mobile node moves outside the enterprise and attaches to an untrusted network, it sets up a VPN tunnel with the VPN gateway. It also maintains a valid binding cache entry at the Home Agent. The VPN TIA given out by the VPN gateway is used as care-of address for Mobile IP registration. If the mobile node attaches to another VPN gateway or it re-connects to the same VPN gateway after a while, it might get allocated a new TIA. In such a case, the mobile node sends a Registration Request to its Home Agent to update the binding cache with its current TIA. 3.3 Mobility when outside the enterprise When the mobile node is attached to an untrusted network, it sets up a VPN tunnel with the VPN gateway to gain access to the enterprise network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel. If the mobile node moves and its IP address changes, it initiates the MOBIKE protocol [3] to update the address on the VPN gateway. If the TIA changes or the mobile node attaches to another VPN gateway, while outside the enterprise, the mobile node should send a Registration Devarapalli & Eronen Expires January 11, 2006 [Page 7] Internet-Draft MIPv4 and MOBIKE interworking July 2005 Request to its Home Agent using the new TIA as the co-located care-of address. 3.4 Crossing Security Boundaries Security boundary detection is based on the reachability of the i-HA from the mobile node's current point of attachment. Whenever the mobile node detects that it has moved to a new IP subnet [13] and its IP address changes, it sends a registration request to the i-HA without any VPN encapsulation. If the mobile node receives a Registration Reply, then it is assumes that it is on a trusted network. This is based on the mechanism described in [10] to detect attachment to the internal trusted network. The mobile node should re-transmit the Registration Request, if it does not receive the Registration Reply within a timeout period. The number of times the mobile node should re-transmit the Registration Request and the timeout period for receiving the Registration Reply are configurable on the mobile node. If the mobile node has an existing VPN tunnel to its VPN gateway, it MUST send a IKE MOBIKE message at the same time as the registration request to the i-HA, whenever the IP address changes. If the mobile node receives a response from the VPN gateway, but not from the i-HA, it assumes it is outside the enterprise network. If it receives a response from the i-HA, then it assumes it is inside the enterprise network. There could also be some out-of-band mechanisms that involve configuring the wireless access points with some information which the mobile node can recognize as access points that belong to the trusted network in an enterprise network. Such mechanisms are beyond the scope of this document. 3.4.1 Operation when moving from an untrusted network When the mobile node is outside the enterprise network and attached to an untrusted network, it has an IPsec VPN tunnel with its mobility aware VPN gateway, and a valid registration with a Home Agent on the intranet with the VPN TIA as the care-of address. If the mobile nodes moves and its IP address changes, it performs the following steps: 1. Initiate IKE mobility exchange to update the current address with the VPN gateway. If the new network is also untrusted, this will be enough for setting up the connectivity. If the new network is trusted, and if the VPN gateway is reachable, this exchange will allow the mobile node to keep the VPN state alive while in the Devarapalli & Eronen Expires January 11, 2006 [Page 8] Internet-Draft MIPv4 and MOBIKE interworking July 2005 trusted side. If the VPN gateway is not reachable from inside, then this exchange will fail. 2. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal Home Agent without VPN encapsulation. 3. If the mobile node receives a Registration Response to the request sent in step 2, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling. The mobile node MAY tear down the VPN tunnel. 3.4.2 Operation when moving from a trusted network When the mobile node is inside the enterprise and attached to the intranet, it does not use a VPN tunnel for data traffic. It has a valid binding cache entry at its home agent. If the VPN gateway is reachable from the trusted network, the mobile node MAY have valid IKEv2 security associations with its VPN gateway. The IPsec security associations can be created when required. The mobile node may have to re-negotiate the IKEv2 security associations to prevent them from expiring. If the mobile node moves and its IP address changes, it performs the following steps: 1. Initiate IKE mobility exchange to update the current address with the VPN gateway, or if there is no VPN connection, then establish a VPN tunnel with the gateway from the new local IP address. If the new network is trusted, and if the VPN gateway is reachable, this exchange will allow the mobile node to keep the VPN state alive, while in the trusted side. If the new network is trusted and if the VPN gateway is not reachable from inside, then this exchange will fail. 2. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal Home Agent without VPN encapsulation. 3. If the mobile node receives a Registration Response to the request sent in step 2, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling, using only Mobile IP with the new care-of address. 4. If the mobile node didn't receive the response in step 3, and if the VPN tunnel is successfully established and registered in step 1, then the mobile node sends a Registration Request over the VPN tunnel to the internal Home Agent. After receiving a Registration Response from the Home Agent, the mobile node can start communicating over the VPN tunnel with the Mobile IP home address. 4. NAT Traversal There could be a NAT device between the mobile node and the home Devarapalli & Eronen Expires January 11, 2006 [Page 9] Internet-Draft MIPv4 and MOBIKE interworking July 2005 agent in any of the access modes, 'c', 'f' and 'mc', and between the mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 NAT traversal, as described in [7] MUST be supported by the mobile node and the home agent when the mobile node is using access modes 'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8] [9] MUST be supported by the mobile node and the VPN gateway. Typically, the TIA would be a routable address inside the enterprise network. But in some cases, the TIA could be from a private address space associated with the VPN gateway. In such a case, Mobile IPv4 NAT traversal should be used in addition to IPsec NAT traversal in the 'mc' mode. 5. Security Considerations Enterprise connectivity, typically requires very strong security and the solution described in this document was designed keeping this in mind. Security concerns related to the mobile node detecting that is on a trusted network and thereafter dropping the VPN tunnel are described in [10]. Please see [3] for MOBIKE-related security considerations, and [7], [8] for security concerns related to the use of NAT traversal mechanisms for Mobile IPv4 and IPsec. 6. IANA Considerations This document requires no action from IANA. 7. Acknowledgments The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval Shah and John Cruz for their participation in developing this solution. 8. References 8.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-00 (work in progress), June 2005. Devarapalli & Eronen Expires January 11, 2006 [Page 10] Internet-Draft MIPv4 and MOBIKE interworking July 2005 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), April 2005. [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [7] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003. [8] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [9] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [10] Vaarala, S., "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", draft-ietf-mip4-vpn-problem-solution-01 (work in progress), January 2005. 8.2 Informative References [11] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of VPN Gateways", draft-ietf-mip4-vpn-problem-statement-03 (work in progress), October 2004. [12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [13] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005. Devarapalli & Eronen Expires January 11, 2006 [Page 11] Internet-Draft MIPv4 and MOBIKE interworking July 2005 Authors' Addresses Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Appendix A. Mobility Extensions for IKEv1 Note: It is not decided yet if we should have this section in this document. It might be removed or moved to a separate document. There is no standards effort currently to develop mobility extensions for IKEv1. The current IPsec VPN deployments predominantly use IKEv1. In this section, we describe mobility extensions for IKEv1. The mobile node must not use these extensions before it has confirmed that the VPN gateway supports this. The VPN gateway signals support by including a Vendor ID payload in the first phase 1 message it sends. The value for this payload is the following 15 bytes {0xB5, 0xC8, 0xDF, 0x2B, 0xD4, 0xC3, 0xC6, 0x89, 0x9F, 0xB8, 0x19, 0xA3, 0x4A, 0x81, 0x1F}, followed by one byte corresponding to the highest version of this extension supported (0x01 for this document). The messages used by this extension are shown below. Mobile node VPN gateway ----------- ----------- HDR*, HASH, N(ADDRESS-UPDATE-REQUEST), --> NAT-D, NAT-D <-- HDR*, HASH, NAT-D, NAT-D When the mobile node wishes to change its address, it constructs a message with the following contents: Devarapalli & Eronen Expires January 11, 2006 [Page 12] Internet-Draft MIPv4 and MOBIKE interworking July 2005 o The IP source address is the new address. o ISAKMP Exchange Type is Transaction Exchange (defined in draft-dukes-ike-mode-cfg-02). All payloads following the header are encrypted, so the Encryption bit is set to 1, and a new Message ID is selected. o The HASH payload authenticates the message, and is calculated as described in draft-dukes-ike-mode-cfg-02. o The ADDRESS-UPDATE-REQUEST Notify payload is constructed as follows: * Domain of Interpretation is set to 1 (IPSEC) and Protocol-Id is set to 1 (ISAKMP) * Notify Message Type is set to 35389 (randomly selected from the 32768-40959 range). * SPI Size is set to 16; the SPI is set to the ISAKMP cookies. * Notification Data contains a four-octet sequence number. This sequence number is initialized to 0 when the ISAKMP SA is set up, and incremented for each ADDRESS-UPDATE-REQUEST sent. o The NAT-D payloads as described in draft-ietf-ipsec-nat-t-ike-08. Note that more than two NAT-D payloads may be present in some circumstances. When the VPN gateway receives this message, it o Looks up the correct ISAKMP SA, decrypts the message, and verifies the HASH payload. o Compares the sequence number in the ADDRESS-UPDATE-REQUEST payload with its stored value, and rejects the message if the sequence number in the packet is smaller than the stored value. The stored value is updated after the message has been processed. o Determines which ESP SAs are associated with the mobile node (typically only a single ESP SA). o Calculates the expected value for the NAT-D payloads based on IP address and port number from the IP/UDP headers. o If the mobile node is behind a NAT (none of the mobile node's NAT-D payloads match the expected value), updates encapsulation mode of the ESP SAs to UDP-Encapsulated-Tunnel, and updates the IP address and port number based on the IP/UDP header. o If the mobile node is not behind a NAT, updates the encapsulation mode of the ESP SAs to Tunnel, and updates the IP address based on the IP header. o Constructs a reply containing a HASH and NAT-D payloads. When the mobile node receives the reply, it verifies the HASH payload, and changes encapsulation mode if it detects that it is behind a NAT. Devarapalli & Eronen Expires January 11, 2006 [Page 13] Internet-Draft MIPv4 and MOBIKE interworking July 2005 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 procedures with respect to rights in RFC 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 (2005). 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. Devarapalli & Eronen Expires January 11, 2006 [Page 14]