Network Working Group Sheng Jiang Internet Draft Sam(Zhongqi) Xia Expires: January 2009 Huawei Technologies Co., Ltd Alberto Garcia-Martinez UC3M July 11th, 2008 Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches draft-jiang-sendcgaext-cga-config-02.txt 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. This document may only be posted in an Internet-Draft. 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 10, 2009. Abstract This document analyzes the requirements for the configuration Cryptographically Generated Addresses and Multi-key CGAs. The applicability of Router Advertisement and DHCPv6 for this configuration is also discussed. Jiang, et al. Expires January 10, 2009 [Page 1] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Requirements................................................3 3.1. Configuration of the parameters required for the generation of CGA......................................................3 3.1.1. Offloading the large computational burden...........4 3.1.2. Certificate information dissemination..............5 3.2. CGA granting and registration...........................5 3.3. Configuration the parameters in order to enable the CGA proxy ............................................................5 4. Approaches overview.........................................6 4.1. Node requests CGA-related configuration parameters to the DHCPv6 server...............................................7 4.2. Node requests to the DHCPv6 server the computation of the Modifier....................................................7 4.3. Node requests DHCPv6 server to grant the CGA............8 4.4. Node sends MCGA-specific information to the DHCPv6 server8 5. Security Considerations......................................8 5.1. Threat Analysis of the Configuration Requirements........8 5.1.1. Threats faced by the end hosts.....................8 5.1.2. Threats faced by the configuration servers and proxies10 5.2. Threat Analysis of the Approaches Proposed.............10 5.2.1. Router Advertisement with SEND support............11 5.2.2. Router Advertisement without SEND support..........11 5.2.3. DHCPv6...........................................11 6. IANA Considerations........................................12 7. Conclusions................................................12 8. Acknowledgments............................................12 9. References.................................................12 9.1. Normative References...................................12 9.2. Informative References.................................13 Author's Addresses............................................14 Intellectual Property Statement................................14 Disclaimer of Validity........................................15 Copyright Statement...........................................15 1. Introduction Cryptographically Generated Addresses (CGA, [RFC3972]) provide means to verify the ownership of IPv6 addresses without requiring any security infrastructure such as a certification authority. As an extension to enable SEure Neighbor Discovery (SEND, [RFC3971]) proxy Jiang, et al. Expires January 10, 2009 [Page 2] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 support, multi-key CGAs [MCGA] have been introduced. The use of both types of addresses has been proposed for allowing identity verification in different protocols, such as SEND, Enhanced Route Optimization for MIPv6 [RFC4866] or SHIM6 [SHIM6-proto]. In the current specifications, there is a lack of procedures to enable proper management of CGA generation, in particular, in the configuration of the parameters that define the security properties of the addresses. Additionally, there is a lack of tools for informing the hosts about the availability of SEND proxies, and exchanging the required information with the proxies. Finally, there are no means to delegate the computation of the Modifier, a CPU intensive operation, to faster or non battery-dependant resources. This draft analyses the configuration requirements raised by CGA and MCGA generation. Additionally, the applicability of Router Advertisement and Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315]) for performing this configuration is discussed. 2. Terminology 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 RFC2119 [RFC2119]. 3. Requirements The CGA specifications [RFC3972, MCGA] define the procedure to generate a CGA. However, these procedures do not allow the enforcement of a given configuration to a group of hosts, nor address the interactions between end hosts and proxies required for proxy configuration. It does also not consider the delegation of CPU- intensive operations to other nodes. In this section, we analyze the scenarios in which these operations are required. 3.1. Configuration of the parameters required for the generation of CGA The CGA associated Parameters used to generate a CGA includes several parameters [RFC 3972]: - a Public Key, - a Subnet Prefix, - a 3-bit security parameter Sec, Jiang, et al. Expires January 10, 2009 [Page 3] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 - a Modifier that is selected so that the result of a hash to comply with the requirements introduced by the value of a security parameter Sec in order to provide protection against brute-force attacks, - a Collision Count value, increased each time the address generated results in a collision in the subnet considered, - any Extension Fields that could be used. Additionally, it should be noted that the hash algorithm to be used in the generation of the CGA is also defined by the Sec value [RFC4982]. Currently, there are convenient mechanisms for allowing an administrator to configure the subnet prefix for a host. Other parameters used for generating the CGA could also benefit from the possibility of being configured by the administrator. For instance, the administrator can determine, according to the type of infrastructure and the security needs, the Sec value that should be used by the hosts to generate the CGA. When appropriate, the Extension Fields could also be mandated by the administrator. Upon reception of this information, the end hosts SHOULD generate addresses compliant with the received parameters. If the parameters change, the end hosts SHOULD generate new addresses compliant with the parameters propagated. 3.1.1. Offloading the large computational burden An important case to consider is the large computational consumption of the generation of the Modifier field. The Modifier is a 128 unsigned integer that is selected so that the Hash2 operation defined in RFC 3972 results in the required number of leftmost 0 bits. The higher the number of bits required being 0, the more secure a CGA is against brute-force attacks. However, high number of bits also results in additional computational cost for the generation process, cost that could be deemed excessive in certain environments, such as mobile terminals with low computing power. As an example, consider a Sec value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 to be zero. For assuring this, a system has to generate in mean 2^32 different modifiers, and perform the Hash2 operation to check the bits required to be 0. An estimation of the CPU power required to do this can be obtained as following: openSSL can perform in an Intel Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- Jiang, et al. Expires January 10, 2009 [Page 4] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 1 operations on 16 byte blocks per second. Since the input data of Hash2 operation is larger than 16 bytes, this value is an upper bound for the number of hash operations that can be performed for generating the modifier. Checking 2^32 different modifiers requires around 5000 seconds. The high number of required operations can represent a problem for end hosts (i.e. mobile devices) with much lower computing power than considered in the example, and/or with restrictions in battery resources. For these cases, a mechanism for delegating the computation of the modifier should be provided. 3.1.2. Certificate information dissemination CGAs enable the verification of the relationship between a public/private key pair (certificate) and an address. However, it does not verify the identity of a sender. In most of scenarios, it is necessary to know which certificates or certificate chains are trustworthy. Mechanisms are required to disseminate such information to CGA receivers. 3.2. CGA granting and registration The usage of self-generated CGAs may need to be granted by the networking management plate. Only granted CGAs are allowed to be used to access the network. It is also validated whether the CGAs do not use the reserved range of interface identifier [RIID]. As described in RFC 3972, the modifier can be reused when the prefix of the CGA changes and this is the only change. However, when a mobile node moves from a network to another, not only the prefix changes, but also other CGA relevant parameters may change. Therefore, any CGAs generated by the node itself should also be granted by the networking management plate. A node that has generated a CGA could register the resulting address so that a central administration could manage this information. The node could be requested to perform this registration. 3.3. Configuration the parameters in order to enable the CGA proxy In order to preserve location privacy of CGAs, the CGA proxy solutions, such as Multi-Key Cryptographically Generated Addresses (MCGAs), are introduced. These CGA proxy solutions require that certain information/parameters of proxy are configured. First of all, end hosts should be notified that their SEND validation could be proxied, and therefore that they should generate MCGA addresses. In order to generate the MCGA, and in addition to the Sec Jiang, et al. Expires January 10, 2009 [Page 5] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 parameter and Extension Fields required for CGA bootstrapping, the node must know the node's own public key and the public key(s) from its proxy(s), which are certified router public keys. RFC 3971 describe a mechanism that allows the node to obtain the public keys of the router(s), although other protocols could be used for this purpose. Upon reception of this information, the end hosts SHOULD generate MCGAs compliant with the received parameters. If the parameters change, the end hosts SHOULD generate new MCGAs compliant with the parameters propagated. Additionally, the proxy(s) should be notified the new MCGA and its associated CGA Parameters Data Structure, so that the proxy could securely proxy the MCGA by signing the message with its own private key. Consequently, a mechanism for making proxy(s) aware of the keys used by each end host should be provided. 4. Approaches overview Among the mechanisms in which configuration parameters could be pushed to the end hosts and/or CGA related information sent back to a central administration, we discuss two mechanisms: the stateless address configuration mechanism based in Router Advertisement, and the stateful configuration mechanism based in DCHPv6. On one hand, Router Advertisement could be extended with an option that could convey parameters related with CGA configuration, such as the value of the Sec or the values of future Extension Fields, etc. In this way, a router could distribute these parameters to all the hosts of the subnet through Router Advertisement, in the same message in which prefix information is conveyed. On the other hand, DHCPv6 can be extended to: - propagate to the end hosts the values of the basic parameters required to configure CGAs, - request the node to propagate to the server the resulting CGA address, - grant the node to use its self-generated CGA address, - obtain from the end host CGA information to update any database with the addresses being used, - inform the end hosts about the convenience for generating MCGA, Jiang, et al. Expires January 10, 2009 [Page 6] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 - obtain from the end hosts the MCGA information required to configure the proxy(s), - receive requests for generating a Modifier according to a given security configuration, and returning the result to the end host. Finally, both Router Advertisement and DCHPv6 could be combined in the following cases: - when the node is requested by Router Advertisement to register the resulting CGA, DHCPv6 could be used to inform the DHCPv6 server about the resulting address, - when MCGA address are generated, Router Advertisement could be used to propagate the basic CGA parameters, and a notification that the end host should generate MCGA, and use DHCPv6 to inform the DHCPv6 server about the public key material used for MCGA generation, - when the node solicits the computation of the Modifier, after receiving a Router Advertisement with the Sec parameters and Extension Fields, it can issue the request through a DHCPv6 exchange. We next describe in more detail the interactions foresee for DHCPv6. 4.1. Node requests CGA-related configuration parameters to the DHCPv6 server A node may initiate a request for the relevant CGA configuration information needed to the DHCPv6 server. The server responds with the configuration information for the node. The server also sends its known certification information for the node. If registration of the resulting address is required, the server can include such requirement in the message sent. If SEND proxies are available, the server informs the node that an MCGA should be generated. The public keys for the routers, along with their certificates, could be included in the response. After receiving the configuration information, the node generates a CGA (or a MCGA) based on its public key and the configuration information. 4.2. Node requests to the DHCPv6 server the computation of the Modifier A node may initiate a request for the computation of the Modifier for a certain security configuration to the DHCPv6 server. The node Jiang, et al. Expires January 10, 2009 [Page 7] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 includes the values selected for the CGA associated parameters, such as its public key, the value of the Sec parameter, etc. The server either computes the Modifier value, or redirects the computation to other node using a mechanism that is out of the scope of this draft. Once the server obtains the modifier, it computes the CGA or MCGA according to the process described in RFC 3972, and it responds to the node with the resulting address and the CGA Parameters Data Structure. 4.3. Node requests DHCPv6 server to grant the CGA A node requests DHCPv6 server to grant a CGA generated by the node itself, listing the CGA addresses in IA options [RFC3315]. According to whether the CGA matches the CGA-related configuration parameters of the network, the DHCPv6 server sends an acknowledgement to the node, grant the usage of the CGA or indicate the node that it must generate a new CGA with the CGA-related configuration parameters of the network. In the meantime, the DHCPv6 server has had the opportunity to log the address/host combination. 4.4. Node sends MCGA-specific information to the DHCPv6 server A node that has generated its MCGA informs the DHCPv6 server about the MCGA and its associated CGA Parameters Data Structure. The DHCPv6 server sends an acknowledgement to the node. The server or the node also needs to notify this information to the routers acting as SEND proxies, in a way that is out of the scope of this document. 5. Security Considerations 5.1. Threat Analysis of the Configuration Requirements 5.1.1. Threats faced by the end hosts We first discuss the threats that the clients may face as a result of the operations described in this document. Regarding to the configuration of the Sec parameter, one risk is that a malicious node could propagate a Sec value providing less protection than intended by the network administrator, facilitating a brute force attack against the hash, or the selection of the weakest hash algorithm available for CGA definition. Even in the worst case, if the hash algorithm cannot be inverted, the expected number of iterations required for a brute force attack is O(2^59) in order to find a CGA Parameters Data Structure that matches with a given node. Jiang, et al. Expires January 10, 2009 [Page 8] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 Another risk is the use of a Sec, higher than intended by the administrator, which would require a large number of resources of the client to compute the modifier, requiring a long time until the device can communicate. This can be considered a kind of DOS attack. A variation of this attack is the propagation of different Sec values could force the nodes to generate different addresses, requiring the generation of a new modifier, etc. The end host SHOULD store the addresses that were generated in the past according to different Sec values. The disclosure of the Sec value to any party does not represent any threat. The analysis of the threats for the configuration of CGA Extension Fields should be performed in a case-by-case basis. Regarding to the propagation of MCGA-related information, an attacker could generate a key pair, and propagate the public key to the end host, so the MCGA generated were associated with the public key of the attacker, In this way, the attacker would be able to impersonate the end host for all the protocols for which MCGA were used, such as SEND. Note that the privacy features included in the MCGA design prevents correspondent nodes from realizing that the end host identity has been stolen. In addition, an attacker could propagate different public keys at a high frequency, forcing the end host to generate new MCGAs, resulting if repeated in a DOS attack. The disclosure of the public keys of the proxy(s) or end host(s) used to build the MCGA does not represent any threat. Finally, we consider the delegation of the Modifier computation. The configuration at a given end host of a Modifier not compliant with the Sec requirement could break any identity validation performed at other hosts, and consequently, could prevent any communication. However, this event can be easily detected at the end host by a performing the Hash2 computation and certifying that results in the required number of 0 bits. If it were impossible to obtain a valid Modifier, the end host would be forced to compute by itself the modifier, falling back to the current standard procedure. It is worth to note that the proposed operations do not exchange private keys. An operation requiring such exchange would be the generation of a CGA/MCGA in a different location than the final end host to which it is assigned. The benefits do not outweigh the risks. On one hand, the gain would be small, since a CGA-enabled host is Jiang, et al. Expires January 10, 2009 [Page 9] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 expected to dynamically sign and validate signatures, and the cost of generating a key pair is not much higher. On the other hand, there are significant risks, associated to the fact that the compromise of the node generating the keys results in the compromise of the identities of many other systems, and the need for assuring private communications among the parties involved (possibly requiring cryptographic tools, key distribution, etc.) 5.1.2. Threats faced by the configuration servers and proxies In general, the threats that the configuration servers may face are related with DOS. An attacker could generate CGA registration requests in order to exhaust the server resources (or to impact on any other operation that depend on the registration of the CGAs). The considerations for MCGAs are similar, although in this case the impact is extended to proxies. However, the most dangerous attack is bound to malicious requests to compute the Modifier, since the CPU cost for the server can be high, especially considering that the attacker could select a Sec value requiring the highest number of computations for the server. We also consider the threats involved in the delivery of the information used to build a MCGA to a SEND proxy. In this case, an attacker could generate fake information in order to exhaust the resources at the proxy. While computing resources are not compromised, since the only check required at the proxy is that its own certified key is included, the state associated to the proxy operation could be exhausted, or proxy operation slowed down. 5.2. Threat Analysis of the Approaches Proposed Now we discuss the security implications of the use of Router Advertisement and DHCPv6 for performing the proposed operations. To analyze the different scenarios regarding to security in which they can be applied, it is worth to note that the use of CGAs and MCGAs is not bound to SEND enabled networks, since they could be used for identity protection in other protocols such as MIPv6 or SHIM6. Therefore, we can consider different scenarios regarding to security: Router Advertisement with SEND support, Router Advertisement without SEND support, and DHCPv6. For Router Advertisement approaches, only parameter propagation and SEND proxy public key distribution are to be considered. Jiang, et al. Expires January 10, 2009 [Page 10] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 5.2.1. Router Advertisement with SEND support Since the integrity of the RA messages and the identity of their sender are protected by the SEND protocol, protection against malicious nodes generating inappropriate values for the Sec parameter or the Extension Fields is provided. The same protection is provided for the distribution of the public keys of the proxies required for MCGA generation. In this case, a trust anchor must have been configured in the client previously to the reception of the RA messages. 5.2.2. Router Advertisement without SEND support In this case there is no protection against the generation of different Sec values, so an attacker could force the generation of CGA with the lowest protection allowed by the standard. It could also force the generation of up to 8 CGA addresses in the end host, wasting resources from the end host. Another attack is related with the association of the public key of an attacker to the MCGA of the end host. DOS attacks based on the request of multiple MCGAs could be issued, although in this case a rate limit set in the client could mitigate the impact. However, it should be noted that an attacker being able to generate Router Advertisements could also perform Man-In-The-Middle or DOS attacks, by registering itself as a default router for the subnet. 5.2.3. DHCPv6 All the configuration operations proposed in this document are initiated by the end host. From the point of view of the end host, the difficulty of generating fake responses that were accepted by the end host with the same transaction-id at the precise time is outstanding. However, attacks can be generated by nodes placed in path between the requesting end host and the DHCPv6 server. In particular, non-SEND enabled subnets are more prone to this type of attacks, although SEND does not provide full protection against MITM attacks. In this case, the Sec parameter could be forced to be the lowest, the node could be forced to compute up to 8 CGA addresses, or to compute MCGAs associated with the attacker. The mechanism based on DHCPv6 is also vulnerable to DOS attacks to the server, such as registration of large number of CGA, or request for Modifier computation. Jiang, et al. Expires January 10, 2009 [Page 11] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as AUTH option, can prevent these threats, provided that a configuration token is known to both the client and the server. Note that, as expected, it is not possible to provide secure configuration of CGA or MCGA without a previous configuration of security information at the client (either a trust anchor, a DHCPv6 configuration token...). However, considering that the values of these elements could be shared by the nodes in the network segment, these security elements can be configured more easily in the end nodes than its addresses. 6. IANA Considerations This document defines only the interaction models that involve the Router Advertisement and the DHCPv6 protocol in the CGA generation procedure. The actual DHCPv6 and Router Advertisement extensions are defined in other documents. 7. Conclusions This document analyses the requirements for the configuration Cryptographically Generated Addresses (CGA) and Multi-key CGAs. A central administration could configure some parameters such as Sec or Extension Fields to be used by the end hosts in CGA generation. The central administration could notify the availability of CGA proxies, requesting the generation of MCGAs, and propagating the keying material required for MCGAs, and obtaining the end host specific material resulting from this address generation. The computation of the Modifier could also be delegated by an end host to a more appropriate system. The tools discussed for this performing these interactions are Router Advertisement and the DHCPv6 protocol. 8. Acknowledgments The authors would like to thank Marcelo Bagnulo Braun for been involved in the early requirement identification. 9. References 9.1. Normative References [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. Jiang, et al. Expires January 10, 2009 [Page 12] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor Discovery (SEND) ", RFC 3971, March 2005. [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, March 2005. [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) ", RFC4982, July 2007. [MCGA] J. Kempf, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Address", draft-kempf-cgaext- ringsig-ndproxy-02 (work in progress), August 2007. [RIID] S. Krishnan, "Reserved IPv6 Interface Identifiers", draft- ietf-6man-reserved-iids-00.txt (work in progress), February 2008. 9.2. Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. [RFC4866] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC4866, May 2007. [SHIM6-proto] E. Nordmark, M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10.txt (work in progress), February 2008. Jiang, et al. Expires January 10, 2009 [Page 13] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd QuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China 100085 Phone: 86-10-82836774 Email: shengjiang@huawei.com Sam (Zhongqi) Xia Huawei Technologies Co., Ltd QuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China 100085 Phone: 86-10-82836864 Email: xiazhongqi@huawei.com Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34-91-6249500 Email: alberto@it.uc3m.es 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. Jiang, et al. Expires January 10, 2009 [Page 14] Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt July 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. Jiang, et al. Expires January 10, 2009 [Page 15]