Network Working Group Vamsi K Gondi, Internet Draft Nazim Agoulmine, Expires: August 2008 LRSM, UEVE, France February 18, 2008 Handover method using EAP draft-gondi-hokey-neweap-handover-method-00.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. 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, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The increase in the use of different access networks which involves different mechanisms for authentication and access authorizations, demands the new mechanisms to roam at any time anywhere with low latency. To overcome this process we need new mechanisms where a user terminal roams in different access networks with low latency and Vamsi & Nazim Expires August 18, 2008 [Page 1] Internet-Draft Handover method using EAP February 2008 efficiently. There is a need for unified signaling mechanisms for choosing and accessing networks. In this draft we have discussed some of the processes involved in network selection, mobility management, security management in detailed to perform handover. The Handover information is passed to home server using the new handover method using EAP proposed vice versa in this draft. Even though there are different mechanisms provide this support such as IAPP context transfer mechanisms for seamless mobility some of the instances like supporting different access networks, roaming in access networks etc is not considered. The proposed mechanism is interoperable with the existing procedures involving security authentication and mobility during roaming. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. Overview of EAP HO and Handover mechanism......................5 3.1. Authentication and Re-authentication......................6 3.2. Handover Library Model....................................7 3.2.1. Network Selection (NS)...............................7 3.2.2. Handover (HO)........................................8 3.2.3. Security Context Transfer Mechanisms (SC)............9 3.2.4. Mobility Management (MM)............................10 3.3. EAP HO conversation......................................10 3.4. Radius server considerations.............................12 4. EAP HO packet format..........................................12 4.1. Packet Format............................................13 5. Security Considerations.......................................15 6. IANA Considerations...........................................15 7. Conclusions...................................................15 8. References....................................................16 8.1. Normative References.....................................16 8.2. Informative References...................................16 Author's Addresses...............................................16 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................17 1. Introduction The open issues which remain are about what are the signaling protocols that should be used for exchanging the information between the existing network entities to perform seamless handover. It will be a big advantage if information about presence (PR), network selection (NS), security context management (SC) and mobility (MM) Vamsi & Nazim Expires August 18, 2008 [Page 2] Internet-Draft Handover method using EAP February 2008 signaling can be transported from the home access network to the mobile terminal (MT) and vice versa to perform the handover. Ideally this process can be performed before handover trigger with new access network to reduce the latency and ensure seamless roaming in any access networks. The main aim is to design a mechanism which is interoperable with the existing architectures and mechanisms involved in different access networks. In this process we have identified a mechanism where a terminal can gather information from different entities performing different functionalities, and send this information to the access network. On the access networks side, the server collects the details for that terminal investigates the request and performs relevant operations to send back the reply to terminal. Terminal collects these data and distributes to different entities and performs the handover in a seamless manner (in this case the terminal does the pre authentication with the network entities of network selection, handover decision, security context management, mobility management and session management). In the present architectures of WLAN and WIMAX the information for authentication is transported using EAP [1]. EAP typically runs directly over data link layers such as IEEE 802 and PPP without requiring IP address. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. The basic authentication and authorization access mechanisms involve AAA in the networks at present, based on this we have designed this architecture to extend its functionalities for handover and roaming support. By introducing new handover method in EAP (EAP HO), at the time of re-authentication different procedures can be performed and the necessary information for the handover can be transferred from the client and home access network. In this process the information for network selection, handover management, security and mobility context management is send to the access network using EAP. In this new EAP HO method there are different sub types which can handle the different processes. An API is proposed and the functionalities of this are to communicate with the different entities of the mobile terminal and performs different processes. This API can initiate EAP and the new method and through the subtype option in the proposed method it sends the data to the access network. This API can also handle different mechanisms like the authentication, mobility management of the mobile terminal. Through this API the peer authentication model can be triggered according to the user settings initially and with the security context transfer from the access network the API can Vamsi & Nazim Expires August 18, 2008 [Page 3] Internet-Draft Handover method using EAP February 2008 reconfigure the authentication mechanisms and authenticates to the visiting network. The details of the API are explained in detail of section 3 with the process handlers and EAP HO trigger mechanisms. In section 4 gives details of EAP HO message sequences with the access networks (home and visiting networks). Section 5 provides information of the packet format of the EAP HO. 2. Conventions used in this document 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. Mobile Terminal (MT): The user terminal which has the capability of mobility traditionally a mobile phone or a laptop. Network Selection (NS): The process of identifying the best available network for accessing a network. Handover (HO): Mechanism involving the authentication and access control of the MT moving from one access network to another access network or technology. Security Configuration (SC): Authentication and re-authentication management of the mobile terminal in any access networks, in this draft context management is proposed where the security credentials can be transported to other mechanisms. Mobility Management (MM) In this mechanisms the mobility and session context management can be achieved. Extensible Authentication Protocol (EAP): Extensible Authentication Protocol is a universal authentication framework frequently used in wireless networks and Point-to-Point connections defined by RFC 3748. Radius server: Vamsi & Nazim Expires August 18, 2008 [Page 4] Internet-Draft Handover method using EAP February 2008 Remote Authentication Dial In User Service (RADIUS) is an AAA (authentication, authorization, and accounting) protocol for controlling access to network resources. 3. Overview of EAP HO and Handover mechanism Handover API (Library) proposed in this architecture as mentioned earlier provides roaming and handover support for a mobile terminal when it is roaming in access networks. Traditionally the mobile terminal does not provide any pre authentication support with the existing architecture. As mentioned earlier the information regarding handover can be preemptively processed before mobile terminal moving to another access networks. The proposed Handover API can perform this process and using EAP HO it sends the details of the handover to the home network while it connected to any network. On the other side the radius server receives this information and process this information with the access networks entities and also with the visiting network. The Radius protocol and process mechanism is out of this draft context, we are proposing another draft where the Radius server functionalities are extended for roaming and handover support compatible with the proposed EAP HO method. Initially when the mobile terminal starts the Handover library starts and collects the information of the available networks from the different interfaces on the mobile terminal. This information is basically the available SSIDs, SNR etc..., after looking details of the user policy the HO Library select the best available network, and does initiate the interface and try to authenticate using any EAP method to that network. After successful authentication it does the mobility part using Mobile IP and register to the HA and starts the user session. Whenever the SNR of the present network does goes below the level of the required value, it scans for the other available networks to connect. After gathering the information it triggers EAP HO on the peer and sends the details to the authenticator in a normal EAP process with the user identity initially. The packets are routed according to the NAI of the peer. With the EAP HO sub type of NS the mobile terminal starts a request to the Radius server. Radius server on the other hand listens to the details and responds with the best accessible network as a response for the request of the mobile terminal. After receiving the details of NS the handover library process the information and triggers EAP HO with the subtype of HO the best suited network as a request to the access network. The radius server responds with the HO confirmation requesting the mobile terminal to Vamsi & Nazim Expires August 18, 2008 [Page 5] Internet-Draft Handover method using EAP February 2008 access that network. On the background the radius server interrogates the availability of resources, SLA with the other access network to provide services to the mobile terminal. After receiving the confirmation for handover as a response the mobile terminal handover library trigger for SC and MM methods for deriving the security keys with the home server and create a session using the MM before the terminal initiates the re authentication to the visiting network. In this process the HO Library sends a request to home server for the SC management, the server responds with the details of the duplicate keys derived on the server for the next session and sends as a response to the peer. Through EAP HO SC response, HO library collects the details and prepare for handover with that interface with keys from the server. On the access server side, it derives the temporary keys and forwards to the visiting network so that the authentication can be performed locally in that network to reduce the latency during the re authentication. Again after successful SC management the HO library triggers EAP HO with MM as subtype for MM, in this case we used PMIP for mobility management, the MM is performed on the access network side. The following section provides details and procedures involved during pre authentication. The following procedure provides best QoS guarantee, control of access and low latency. The following section provides details of client processing involves details of network selection, mobility, handover management and security context management. 3.1. Authentication and Re-authentication In general the authentication is performed during the initial access to the network. In this process the handover library does trigger authentication, using general EAP methods it does the authentication to the access network and establishes the session. Normally the re- authentication does disconnect to the present network and initiating the EAP method again with NAI. If ever the access network which is connecting belongs or a part of the SLA with the home network of the operator the authentication takes time, during this process different applications and services can have lot of delay and packet loss. In the process proposed in this draft, the mobile terminal and the access networks pre authenticate the details using EAP HO method proposed in this draft before it disconnects to the present network and tries to establish a connection with the other network. With the context management of the SC and MM the re-authentication to the visiting network the delay and the latency reduces drastically. Vamsi & Nazim Expires August 18, 2008 [Page 6] Internet-Draft Handover method using EAP February 2008 3.2. Handover Library Model As mentioned earlier the handover library does manage the authentication and re authentication of the mobile terminal during handover and roaming in the access networks. In the following section we provide in depth details of different process involved in the EAP HO method with the Handover Library during authentication and re-authentications. 3.2.1. Network Selection (NS) Network selection can be initiated at the terminal level or at the network level. In this process a manual triggering or automatic can be done at the terminal level. When the mobile terminal is switched on the terminal must initiate the network interfaces available on the terminal and scanning for any available networks for connecting. The mobile terminal checks for networks which are hard coded on the terminal as the first preference, if ever the home networks are not available at that instance the mobile terminal peer must try to select one of the networks available and use SLA for getting connected to that access network. In case if the mobile terminal is already connected to any access network, using EAP HO home network can provide at any given instance of available networks and black listed networks to connect to mobile terminal. Once this list is available on the mobile terminal it can do the network selection according to the QoS, preferences, policies, and priority. In roaming case, the mobile will select the networks that have SLA agreement with the home network. If there's not preferred network, the mobile will select a suitable roaming intermediary to help the roaming procedure. In this mechanism we process different information available on the mobile terminal. The mobile terminal does two types of information processing one during initial authentication and other involves during the re authentication. In the re-authentication process the client contacts the home server and process the information available from the home server as well to do the network selection. During initial authentication: In this process the client initiates the network selection procedure, after initiation the client terminal starts the network scan. During the network scan the device probes the different devices available and scans the available networks. The client terminal process the information from devices and process the SSID of the networks. And the terminal initiates the location based process such as GPS, and available home network from the local Vamsi & Nazim Expires August 18, 2008 [Page 7] Internet-Draft Handover method using EAP February 2008 database. With all the networks gathering from different processes, policy of the user, the client selects best suitable network. The client can initiates the NAI of the home network to connect to that visiting network. During Re-Authentication in visiting network: The client does the same procedure as mentioned above and sends the selected networks to the home networks, the home networks chooses the best networks in the preference order to the client. In the home network it processes the details which involve the policies and other procedures to select the network. After receiving the NS list from home network the client NS chooses the best access network and initiates the handover mechanisms with selected network as input. 3.2.2. Handover (HO) Handover management in this architecture, initiate network selection, does required measurements on the network interfaces for network selection. HO on the mobile terminal does measurements and initiates the network selection and informs the access network about the selected target network from the NS process for possible handover or roaming. On the other hand HO on the access network does prepare the network for handovers and communicate with other networks. After identifying the selected target network from the home network, home network sends the handover initiation to the HO of the mobile terminal for initiating the handover to the target network. After handover initiation messages from the home network, HO on mobile terminal initiates the security (SC) management on the mobile terminal for authentication and re-authentication on the target network. This procedure involves the decision after gathering information from all the other procedures of security and mobility. As mentioned earlier the mobile terminal performs two methods one at initial authentication and the other during the re-authentication. During initial authentication: After receiving the selected network from NS the handover initiation function initiate the SC and MM and wait until all the other procedure are completed and then does the handover trigger and does the initial connection on the selected interface with the selected network. During Re-Authentication in visiting network: Vamsi & Nazim Expires August 18, 2008 [Page 8] Internet-Draft Handover method using EAP February 2008 With the selected network the client terminal does start the handover mechanism, the handover function calls home network for confirming the selected network to handover. After receiving the reply from the server the decision is made and triggers the handover procedure with SC and MM. 3.2.3. Security Context Transfer Mechanisms (SC) The role of SC in mobile terminal is to identify the network and get authenticated or re-authenticated to the different access networks. Security mechanism can be obtained by EAP and implementing EAP methods of EAP-SIM/AKA and EAP-TLS on wireless networks. On the other hand access network have a capability to authenticate the user's uses this mechanisms. Whenever there is a request for authentication from the user Radius server of the access networks uses specific EAP methods and creates the security credentials and authenticate the users. On the other hand to make more secured in the architecture we implemented mutual authentications where a MT and access networks authenticate each other. Whenever MT tries to roam to different access networks, the home network does create the re-authentication credentials like Re-id, duplicate certificates and keys and they are send to the MT and to the target access network using security context transfer. We used security context transfer to reduce latency delay during re-authentications by using context transfer of security to target network, while the MT tries to authenticate at the target network without reaching to the home network for re-authentications, by this way latency can be reduced. In this section we deal with authentication and re-authentication of the client terminal with the help of security context management. During initial authentication: With the access network ID and with the specific NAI the user id is strapped. The network interface is initiated and the security mechanism on that interface is started, the client uses the strapped user ID with NAI to access with the access network security mechanisms in this case we used EAP with TLS or SIM for the authentication. After successful authentication mobility management is processed. If ever the authentication is failed the network selection is processed again. During Re-Authentication in visiting network: After the security context management is started the client terminal contacts the home network server. Home radius server provides the re-authentication ID and duplicates keys to the client. After the Vamsi & Nazim Expires August 18, 2008 [Page 9] Internet-Draft Handover method using EAP February 2008 client receiving the security IDs and keys it informs interface security management. After handover decision the interface initiates the security authentication with the provided keys, if the re-authentication is successful it initiates the mobility management if ever the authentication fails it initiates the network selection again. 3.2.4. Mobility Management (MM) This section deals with the mobility management during authentication and re-authentication. During initial authentication: In this process mobility management is started when the security and handover. After receiving this information the IP from DHCP and mobile IP functions. During Re-Authentication in visiting network: Mobility management sends the home network which type of mobility mechanisms to be implemented, the home network assists according to the visiting network information and reply to the client to use Proxy MIP or Client MIP. Other information such as keys etc.. are transferred to the client. 3.3. EAP HO conversation In this section we will provide the details of EAP HO conversations with the authenticator and the radius server during the pre authentication information model using EAP HO method. As mentioned earlier the EAP HO initiates when the HO library of the mobile terminal identify the best suited network, before it is disconnecting to the present network it performs the EAP HO and gets the details of NS, HO, SC, MM from the radius server and prepares the terminal for direct authentication. As shown in figure 1 the information exchange during EAP HO method, in this process the EAP HO can be triggered by the Peer or by an authenticator when there is a request identity, HO library sends the reply and a hint of HO method, then the HO starts the EAP HO method with the subtype NS request, it follows until MM and after successful MM the server sends the success for the EAP HO. In figure 2, gives details of direct authentication to the visiting network using the HO information after the EAP HO method, the home server forwards the re-authentication id and keys to the visiting server. Vamsi & Nazim Expires August 18, 2008 [Page 10] Internet-Draft Handover method using EAP February 2008 Peer Authenticator Home Server ==== ============= =========== EAP request Identity <--------------------- EAP response Identity ---------------------> -----------------------> EAP HO method indication EAP HO start subtype NS request ---------------------------------------------> EAP HO subtype NS reply <--------------------------------------------- EAP HO subtype HO request ---------------------------------------------> EAP HO subtype HO reply <--------------------------------------------- EAP HO subtype SC request ---------------------------------------------> EAP HO subtype SC reply <--------------------------------------------- EAP HO subtype MM request ---------------------------------------------> EAP HO Success <--------------------------------------------- Figure 1: EAP HO method with different subtype message exchange Peer Authenticator visiting Server ==== ============= =========== Vamsi & Nazim Expires August 18, 2008 [Page 11] Internet-Draft Handover method using EAP February 2008 EAP request Identity <--------------------- EAP response Identity (re-authentication ID) ---------------------> -----------------------> EAP request re-authentication <--------------------------------------------- EAP response re-authentication ---------------------------------------------> EAP Success <--------------------------------------------- Figure 2: EAP Re-authentication after EAP HO method 3.4. Radius server considerations Not only the client side the access networks are also has to be modified to accommodate the solution proposed in this architecture. The Radius server has been modified with new modules supporting NS, SC, HO and MM. Different codes and attributes are been added to the existing architecture of Radius to support these mechanisms proposed in this architecture. The Radius server is also modified so it can contact the different network entities like the APs, NAS, HA, FA and MPA etc. And also we are adding new functionalities where the context transfer can be performed from the home radius server to the visiting radius servers. The re authentication model in the visiting networks has to be modified so that the mobile terminal can directly authenticates with that access network. We are in process of proposing a draft for the roaming and mobility support for the Radius server. 4. EAP HO packet format The proposed protocol is to transport information for handover and roaming support for a client in different access network to its home network dedicated server. In this process the NAS and the radius server of the visiting network routes the packets from the client to the home radius server. The client and radius server equipped to access and process the information between them through an API and EAP HO. The proposed EAP handover method support different Vamsi & Nazim Expires August 18, 2008 [Page 12] Internet-Draft Handover method using EAP February 2008 functionalities of Network selection, Handover Management, security context management, mobility management and presence management. 4.1. Packet Format The proposed mechanism the EAP HO packet format is shown below. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code (1 B) |identifier(1 B)| length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type (1 B) | flags (1 B) | message length (4 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length(contd ...) | sub type (1B) |subtype data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subtype data............... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As mentioned in the above packet format, the packet contains fields of code, identifier, length of the packet, its type, flags for controlling, message length if in the case the packet is supporting the fragmentation, and the main important is the subtype method which is the mechanisms involved like the NS or SC etc.., and the subtype main data. Code: The Code field is one octet and identifies the Type of EAP packet. EAP HO Codes are assigned as follows: 1 Request 2 Response 3 Success 4 Failure Since EAP only defines Codes 1-4, EAP packets with other codes MUST be silently discarded by both authenticators and peers. Identifier: The Identifier field is one octet and aids in matching Responses with Requests. Length: The Length field is two octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should Vamsi & Nazim Expires August 18, 2008 [Page 13] Internet-Draft Handover method using EAP February 2008 be treated as Data Link Layer padding and MUST be ignore upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Type: the type of EAP HO is not yet identified by the IETF for the experimental purposes we are using 255 as our data field. Can be re assigned according to the IANA consideration. Flags: the flags for the packet in the proposed mechanisms are shown below. 0 1 2 3 4 5 6 7 8 L M S R R R R R R L is for length inclusion M is for More Fragments, this is included on all the packet but it is excluded in the last packet. S is for EAP HO Start R is for Reserved for future inclusions Message Length: the message length field is of size 4 octets contains the information of the total length of the message in the packet. Subtype: subtype field of 1 octet, it contains details of which type of sub information the packet is carrying. This is specified by an API from libraries to the EAP engine. 0 1 2 3 4 5 6 7 8 NS HO SC PM CM PR R R R NS field is used in case the packet is carrying the NS information from the client and server. HO field is for Handover Management SC is for security context management PM is proxy mobile IP management CM is Client mobile IP management PR is for presence management for the routing and session management R is reserved Vamsi & Nazim Expires August 18, 2008 [Page 14] Internet-Draft Handover method using EAP February 2008 Subtype Data: this data is the information which the packet is transporting from the client and server and vice versa. 5. Security Considerations The proposed mechanisms has been addressing some of the security vulnerabilities, but there are still open issues of the privacy of the users and access networks which is an open issue which has to be addressed properly. Later version of the draft we want to provide more information of the security threats and main issues of man in the middle attacks. 6. IANA Considerations The type value of the new EAP HO method has to be assigned by the IANA. For the experimental purposes we have been using the some available EAP types. 7. Conclusions The mechanisms proposed in this draft can provide seamless mobility solution in access networks during roaming and handover. Using this method the context transfer can be achieved to the client and the visiting network. The control of handover and roaming can be achieved in the access networks using this mechanism. Even though the proposed solution is nomadic there are issues that are to be solved to make this proposed solution robust and easily adaptable to every access networks. Vamsi & Nazim Expires August 18, 2008 [Page 15] Internet-Draft Handover method using EAP February 2008 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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [3] Blunk, L., "Extensible Authentication Protocol (EAP)", RFC 3748 (work in progress), June 2004. 8.2. Informative References [4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [7] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. Author's Addresses Vamsi Krishna Gondi, LRSM Research Lab, University of Evry Evry, France 91000 Email: vamsi.gondi@gmail.com Nazim Agoulmine, LRSM Research Lab, University of Evry Evry, France 91000 Email: nazim.agoulmine@iup.univ-evry.fr Vamsi & Nazim Expires August 18, 2008 [Page 16] Internet-Draft Handover method using EAP February 2008 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, 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. Vamsi & Nazim Expires August 18, 2008 [Page 17]