MIP6 Working Group F. Zhao Internet-Draft S F. Wu Expires: August 18, 2005 UC Davis S. Jung Soongsil University February 14, 2005 Extensions to Return Routability Test in MIP6 draft-zhao-mip6-rr-ext-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 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 August 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft proposes some extensions to Return Routability Test in MIP6 to address the privacy issues and enable CN as well as MN to detect the attack that could compromise the security of MIP6 RO mechanism. Zhao, et al. Expires August 18, 2005 [Page 1] Internet-Draft MIP6 RR Extensions February 2005 Table of Contents 1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 No infrastructure support . . . . . . . . . . . . . . . . 6 3.2 Pre-existing SA between MN and HA . . . . . . . . . . . . 6 3.3 No pre-existing SA between MN and CN or between HA and CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Ingress filtering . . . . . . . . . . . . . . . . . . . . 6 3.5 HA does not have any malicious intention to CN and MN . . 6 3.6 The assumptions of the power of the attacker . . . . . . . 6 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 The basic RR procedure . . . . . . . . . . . . . . . . . . 8 4.3 Protection of the HoA privacy in the BU message . . . . . 11 4.4 Extending the RR test with a detection mechanism . . . . . 12 4.5 Non-repudiation . . . . . . . . . . . . . . . . . . . . . 14 5. Security consideration . . . . . . . . . . . . . . . . . . . . 15 5.1 The privacy of HoA is protected as much as possible . . . 15 5.2 The disclosure of HoA is postponed as late as possible . . 15 5.3 Supports the fast Binding Updates procedure . . . . . . . 15 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Zhao, et al. Expires August 18, 2005 [Page 2] Internet-Draft MIP6 RR Extensions February 2005 1. Motivations 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 [1]. MIP6 adopts Return Routability Test as a lightweight and infrastructure-less authentication mechanism to achieve a reasonable level of authentication between MN and CN even without pre-existing security association. Our motivations to propose some extensions on the original MIP6 RR test are as follows: 1) Location privacy (We will only focus on the location privacy in the IP layer in this draft.) attaches more and more attentions recently; Moreover, RR test could be also used to achieve the security of NEMO Route Optimization protocol (Although NEMO RO solution is still under discussion, a potential approach is to enable MR to register its MNP(s) with CN/CR to achieve the optimal route just like the procedure of Binding Updates to correspondent nodes in MIP6.) where the privacy issue, such as MNP (Mobile Network Prefix) information, becomes even more serious. In this draft, we postpone the disclosure of HoA as late as possible and use the encryption to make HoA invisible to the eavesdropper. In MIP6 RR procedure, HoA is in the cleartext in the HoTi and HoT messages, thus an eavesdropper can learn that MN is away from the home network. In every message of the extended RR test, the privacy of HoA is protected. However, the location privacy of other messages, such as home BU messages, prefix discovery message and data message, is out of scope of this draft. 2) In MIP6, an attacker that is able to only eavesdrop the traffic in the normal IPv6 network can effectively intercept the traffic between MN and CN, which makes the MIP6 network a little bit less secure than the normal IPv6 network. For example, an attacker adjacent to a router on the path between HA and CN can only eavesdrop the traffic but not intercept the traffic passing by, however by eavesdropping and launching the RR test, the attacker can successfully intercept thus take the complete control over the communication between MN and CN. In this draft we propose a detection mechanism for both CN and MN to detect any attack that could break the security of MIP6 RO mechanism. 3) In MIP6, in order to mitigate the attack on the RR test, a timeout value is maintained. Currently, this value is a few minutes, which causes a lot of overheads. Also it is unnecessary to keep repeating the RR test even though there is no attacker around. Thus how to reduce the signaling overhead is also our concern. The detection Zhao, et al. Expires August 18, 2005 [Page 3] Internet-Draft MIP6 RR Extensions February 2005 mechanism enables CN and MN to detect such kind of ôpowerfulö attacker, thus take the correct responses based on the policy with requiring the long frequent timeout. 4) It is also our motivation to propose a RR test mechanism that could be easily extended to RR-test Mobile Network Prefix in NEMO once NEMO working group is re-chartered to work on the RO problem. This draft is organized as follows: in Section 2 we briefly review the related works and then describe the details of our proposal in Section 3. In Section 4 we present the security analysis. Zhao, et al. Expires August 18, 2005 [Page 4] Internet-Draft MIP6 RR Extensions February 2005 2. Related Works MIP6 protocol [2] adopts RR procudure to enable CN to authenticate the binding between CoA and HoA of MN in a reasonable level when there is no pre-exisitng security association between CN and MN. The rationale and background of this design are documented in [5]. Later on, a lot of enhancements of MIP6 RO and improvement of the original RR procedure are proposed [6][7]. Those proposals are based on MIP6 RO; however, NEMO RO has its own security requirements. [8] proposed the idea of using NPT message to verify the correctness of MNP; however, it not only generates the amplication effect but also leaves a hole for an attacker to successfully steal the traffic, which is found by E. Nordmark firstly to our best knowledgement. Zhao, et al. Expires August 18, 2005 [Page 5] Internet-Draft MIP6 RR Extensions February 2005 3. Assumptions 3.1 No infrastructure support The extended RR test does not require PKI or AAA infrastructure to assist the authentication procedure and thus avoids the expensive public key calculation and signaling overhead due to extra message exchanges. 3.2 Pre-existing SA between MN and HA We assume that there exists a security association between MN and HA and integrity and confidentiality of the messages between MN and HA are protected by this SA. 3.3 No pre-existing SA between MN and CN or between HA and CN We assume that there is no pre-existing SA between MN and CN or between HA and CN. 3.4 Ingress filtering Our proposal does not reply on the ingress filtering, thus we assume that there is no ingress filtering enforced. 3.5 HA does not have any malicious intention to CN and MN If HA is malicious, the security of RR procedure in MIP6 is comprised. For example, a malicious HA can redirect the HoT message to an attacker so that the attacker can successfully finish the RR procedure with CN and intercept the traffic to other MN; a malicious HA can also drop the HoTi or HoT message from or to any MN. In [8], the same assumption is also implicitly held because otherwise a malicious HA can forward the NPT messages to the attacker or respond on behalf of the attacker. Please note that a malicious HA can break the communication in MIP6 and NEMO when not performing the RO mechanisms. And this case falls into the category that the attacker has full control (interception) over the path between CN and HA. Thus we believe this is a valid assumption. 3.6 The assumptions of the power of the attacker MIP6 RR procedure limits the attack to be successful only when the attacker is in some certain locations. In other words, the security of RR procedure is comprised when the attacker has the following powers: The attacker is able to access (intercept or eavesdrop) the message exchanges on the MN-CN path and HA-CN path. To do so, the attacker could move from one path to the other; or it could have a Zhao, et al. Expires August 18, 2005 [Page 6] Internet-Draft MIP6 RR Extensions February 2005 conspirator on the other path; or these two paths are kind of overlapping with each other and the attacker is attached to the common part of these two paths. We assume that the attacker has no ability to access the message on both paths in a certain time period and when it attaches itself to either path, the attacker has at most the partial control over the path to eavesdrop the traffic passing by. Zhao, et al. Expires August 18, 2005 [Page 7] Internet-Draft MIP6 RR Extensions February 2005 4. Proposal Our discussions are based on the following simplified MIP6 scenario: CN is a fixed node in the Internet. It is possible to use the reverse tunneling when CN is also a mobile node just like in [5], but we will address this case in details in the later version of this draft due to the constrained time frame. 4.1 Notations Besides those used in [2], we also defines the following notations: RN: a random number generated and managed by MN with the fixed length. In other words, the length of RN is pre-configured and well known by MN, HA, CN and/or any other node. HV: the output of a secure hash function, such as SHA1. 4.2 The basic RR procedure When MN moves to a new location other than its home network, MN may decide to launch the RR procedure with remote node, CN, based on its policy that is not within the scope of this draft. HoTi: Source IP address: HoA Destination IP address: CN {home_init_cookie | RN} MN generates the HoTi message and forwards it into the reverse MN-HA tunnel, thus the confidentiality and secrecy of HoTi are protected by SA between MN and HA. After HA receives the HoTi message, HA can verify that HoA belongs to this home network. When the verification is successful, HA will generate the following HoTi_HA message and forward it to CN. Note that HoTi_HA message can use the same MH type value for HoTi message because all these messages are transparent to CN. We give the different names to these two messages in order to highlight their differences. HoTi_HA: Source IP address: HA Zhao, et al. Expires August 18, 2005 [Page 8] Internet-Draft MIP6 RR Extensions February 2005 Destination IP address: CN {home_init_ha_cookie | HV} where HV = SHA1 (HoA | RN) Please note that HA replaces the source IP address, HoA, with its own IP address, HA and replaces home_init_cookie with home_init_ha_cookie. home_init_ha_cookie can be generated by AES(Kha, HoA | home_init_cookie) or at random and HA establishes a table storing home_init_ha_cookie, HoA and home_init_cookie in one entry where home_init_ha_cookie is a primary key. Please note that HA generates home_init_ha_cookie by encrypting the concatenation of HoA and home_init_cookie after it verifies the received packet, it does not risk the Denial-of-Service attack at this stage and saves the memory cost. However, it may become a serious threat when HA later decrypts the message to restore HoA and home_init_cookie even though HA may verify the home_init_ha_cookie firstly, so HA can avoid the DoS attack at the cost of memory. After CN receives HoTi_HA message, CN generates the HoT message. Note that the formula to generate home_token takes HV as input as well. HoT: Source IP address: CN Destination IP address: HA {home_init_ha_cookie | home_token | home_nonce_index} home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0))) After HA receives HoT message, HA looks up the table with home_init_ha_cookie as the primary key or decrypts the home_init_ha_cookie. After successfully achieving HoA and home_init_cookie, HA generates the following HoT_HA message and forwards it to MN. HoT_HA: Source IP address: CN Destination IP address: HoA {home_init_cookie | home_token | home_nonce_index} home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0))) Zhao, et al. Expires August 18, 2005 [Page 9] Internet-Draft MIP6 RR Extensions February 2005 Please note that HoT_HA message can use the same MH type value for HoT message because all these messages are transparent to MN. We give the different names to these two messages in order to highlight their differences. MN generates the CoTi message and sends it directly to CN. Note that CoTi carries HV instead of HoA in the cleartext. CoTi: Source IP address: CoA Destination IP address: CN {careof_init_cookie | HV} HV = SHA1 (HoA | RN) where RN is the same random number used in the HoTi. After CN receives CoTi message, CN generates the CoT message. Note that the formula to generate careof_token takes HV as input as well. CoT: Source IP address: CN Destination IP address: CoA {careof_init_cookie | careof_token | careof_nonce_index} careof_token = First (128, HMAC_SHA1(Kcn, (CoA | HV | careof_nonce | 1))) The binding management key, Kbm, is generated by taking the concatenation of home_token and careof_token as input of SHA1. Kbm = SHA1(home_token | careof_token) MN generates the BU message as follows and sends it to CN. BU: Source IP address: CoA Destination IP address: CN Zhao, et al. Expires August 18, 2005 [Page 10] Internet-Draft MIP6 RR Extensions February 2005 {HoA | Seq | home_nonce_index | careof_nonce_index | RN | HC | MAC} MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) When CN receives the BU message, CN firstly calculates HV based on HoA and RN, then generates Kbm and verifies the MAC, finally verifies the element in the hash chain. If MN requests the Binding Acknowledgement, CN generates the BA message based on the verification result. BA: Source IP address: CN Destination IP address: CoA {Seq | HV | MAC} MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) 4.3 Protection of the HoA privacy in the BU message Kbm = SHA1(home_token | careof_token | 0) Ken = SHA1(home_token | careof_token | 1) BU: Source IP address: CoA Destination IP address: CN {Seq | home_nonce_index | careof_nonce_index | HV | ENC | MAC} ENC = AES (Ken, HoA | RN) MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) BA: Source IP address: CN Destination IP address: CoA {Seq | HV | MAC} Zhao, et al. Expires August 18, 2005 [Page 11] Internet-Draft MIP6 RR Extensions February 2005 MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) Please note that the decryption operation is after the verification succeeds, which is necessary to reduce the risk of Denial-of-Service attack. However, an attacker on the HA-CN path can still pass the MAC verification and make CN spend resources on the decryption operation. However, this attack cannot be stopped. So if this is really a concern for CN, the encryption is better not available. 4.4 Extending the RR test with a detection mechanism The original MIP6 RR procedure allows an attacker to intercept the traffic even though this attacker is only able to eavesdrop the traffic, which makes MIP6 slightly less secure than the normal IPv4 Internet today. In order to address this vulnerability together with other benefits we describe before, we propose a simple but effective detection mechanism to enable CN to detect and then take the correct action when the power of attacker can succeed in the original RR procedure. The core idea is that either an attacker or a valid MN must provide the cryptographically sound proof of the previous successful Binding Update at CN if any before a new Binding Update being accepted by CN. If the correctness of this proof cannot be verified by CN, CN will disable the relevant Binding Update Cache entry and switch from MIP6 RO mode to MIP6 Basic mode. We adopt the concept of one-way hash chain to achieve this. Although there are a lot of different kinds of one-way hash chain, we use the following one: MN wants to a chain of length l. Firstly, it generates a random number h_l and then repeatedly applies the one-way hash function, F. For example, h_l-1=F(h_l), h_l-2=F(h_l-1), à, h_0=F(h_1). This one-way hash chain has the following properties: 1) MN reveals the elements of the chain in the order of h_0, h_1, à, h_l to CN. Even though the attacker acquires h_i in this chain correctly, it is still cryptographically impossible for him to derive h_j from h_i where j>i. On the contrary, any one can easily confirm that h_j is part of the chain if h_i=F(h_j)^(j-i) where j>i. 2) MN can create the chain all at once and store each element of the chain, or just store h_l together with the sequence number of the next element in the chain and generate the element on demand. In practice, other approach can help to reduce storage cost with a small recomputation penalty. (It is possible to use log(l) storage and log(l) computation to access an element). Also we expect that the development of technology will meet the increasing requirement of battery and memory for MN to maintain such kind of one-way hash chain. HC denotes the current element in the one-way hash chain and Seq Zhao, et al. Expires August 18, 2005 [Page 12] Internet-Draft MIP6 RR Extensions February 2005 denotes the sequence number of this element in the one-way hash chain. MN generates the BU message as follows and sends it to CN. BU: Source IP address: CoA Destination IP address: CN {HoA | Seq | home_nonce_index | careof_nonce_index | RN | HC | MAC} MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU))) When CN receives the BU message, CN firstly calculates HV based on HoA and RN, then generates Kbm and finally verifies the MAC. If the verification is successful, CN performs the following procedure: Search the Binding Update Cache by using MNÆs HoA as the primary key. If it does exist, CN verifies the HC in the BU message with the old element stored in the Binding Updates Cache. If it succeeds, CN believes this BU message is correct and then sends the Binding Acknowledgement message if requested. If it fails, CN realizes that there is an attacker that can successfully finish the extended RR test; however, CN is not sure whether this BU message is from the attacker or a valid MN based on its current knowledge. Thus CN disables this entry until it times out, indicates the reason in the BA message and forwards the data packets destined to this HoA based on MIP6 Basic mode rather than MIP6 RO mode. If it does not exist, CN accepts the BU message and creates a new Binding Update Cache Entry and forwards the data packets destined to this HoA based on MIP6 RO protocol. CN also has to take into consideration the case that MN fails or reboots and all the information related to HC is lost. In this case, CN has to wait until the related BCE expires before accepting the new BU message. If MN requests the Binding Acknowledgement, CN generates the BA message based on the verification result. Zhao, et al. Expires August 18, 2005 [Page 13] Internet-Draft MIP6 RR Extensions February 2005 BA: Source IP address: CN Destination IP address: CoA {Seq | HV | MAC} MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA))) 4.5 Non-repudiation In this session, we discuss about the non-repudiation issue. It seems that the only way to achieve the non-repudiation of HA or CN is to use the public key. Our extended RR test can be extended to achieve the repudiation when the public keys of HA or CN are available. The details of this extension are skipped because it is equivalent to say that there exists the trust relationship between HA and CN. However, by using hash chain rather than public key, it does reduce the computation cost. Zhao, et al. Expires August 18, 2005 [Page 14] Internet-Draft MIP6 RR Extensions February 2005 5. Security consideration We take the following special considerations when extending the RR test: 5.1 The privacy of HoA is protected as much as possible All other messages use the hash value of HoA instead of HoA in the cleartext, which not only makes the attacker learn the HoA information cryptographically impossible, but also help shorten the length of message, simplify the task to design and parse message format as the length of a hash function output is fixed. Moreover, we append a random number to HoA before performing the hash function in order to make it more difficulty for the attacker to derive the HoA information. Please note that the privacy issue is secondary compared with the authentication because if an attacker can break the authentication of the RR test, the privacy of HoA cannot be kept. (If the process of encryption/decryption is much more expensive, the attacker can launch the Denial-of-Service attack to CN.) 5.2 The disclosure of HoA is postponed as late as possible Even though the BU message leaks the HoA information, the attacker on the MN-CN path together with its conspirator on the HA-CN path cannot launch the redirection attack to intercept the traffic that is intended to a specific MN if the attackers are assumed to be able to eavesdrop the traffic only and the detection mechanism is in use. 5.3 Supports the fast Binding Updates procedure The extended RR test supports the fast Binding Updates procedure in CN, which is especially useful when MN moves from one location to another frequently. When MN moves to a new location, MN can reuse the home_token received at the previous location as long as home_token is still valid, thus MN saves the home test procedure that is usually longer than the careof test since HoTi and HoT messages go through HA firstly. Please note that the attacks described in [7] do not succeed in our RR test. For the session hijacking attacks in section 3.1, although the attacker can learn the home_token, however, it does not know the HoA information, so the attacker cannot generate the correct BU message. If the attacker has its conspirator on the MN-CN path, since its conspirator cannot intercept the message, it cannot stop MN from finishing the Binding Updates procedure at CN. Together with the detection mechanism, the traffic cannot be hijacked. For the Zhao, et al. Expires August 18, 2005 [Page 15] Internet-Draft MIP6 RR Extensions February 2005 Movement Halting attacks in section 3.2, when the attacker is able to know home_token and careof_token in the different sessions but from one single MN, the attacker must have to learn the HoA from the BU message. If the BU message is encrypted, the attack fails if the attacker cannot monitor both paths simultaneously. If the BU message is not encrypted, the attack still fails when the detection mechanism is used. For the traffic permutation attacks in section 3.3, the attacker is able to know multiple home_tokens and multiple careof_tokens in the different sessions from multiple different MNs. However, since both home_token and careof_token are generated from the hash output of the HoA information, CN can detect the forged BU message using mixed home_token and careof_token. Again the detection mechanism can detect this attack as well. Our RR test only prevents the attack target at a specific MN and the attacker has no knowledge of the HoA information associated with this MN. But the attacker on the HA-CN path is free to launch the RR procedure for any HoA it chooses. Again, this attack can be mitigated by the detection mechanism. Zhao, et al. Expires August 18, 2005 [Page 16] Internet-Draft MIP6 RR Extensions February 2005 6. Conclusions In this draft, we propose several extensions to the MIP6 RR test. Our proposal protects the privacy of HoA and provides a prompt method for CN to detect the attack accurately when the attacker could succeed in the original MIP6 RR procedure. 7. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [5] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-02 (work in progress), October 2004. [6] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", draft-arkko-mip6-ro-enhancements-00 (work in progress), October 2004. [7] Bao, F., Deng, R. and J. Zhou, "Improvement of Return Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work in progress), August 2004. [8] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), October 2004. Zhao, et al. Expires August 18, 2005 [Page 17] Internet-Draft MIP6 RR Extensions February 2005 Authors' Addresses Fan Zhao University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 752 3128 Email: fanzhao@ucdavis.edu S. Felix Wu University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 754 7070 Email: sfwu@ucdavis.edu Souhwan Jung Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82 2 820 0714 Email: souhwanj@ssu.ac.kr Zhao, et al. Expires August 18, 2005 [Page 18] Internet-Draft MIP6 RR Extensions February 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. Zhao, et al. Expires August 18, 2005 [Page 19]