NETLMM Working Group Vamsi Krishna.G, Internet Draft Nazim Agoulmine, Expires: August 2008 LRSM, UEVE, Toan T, Ecole Politechnique, France February 15, 2008 Mobility Management using AAA mobility extensions and Proxy Mobile IPv4 draft-gondi-netlmm-pmip-aaam-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 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). This version of this MIB module is part of RFC 4748; see the RFC itself for full legal notices. Copyright (C) The IETF Trust (2008). The initial version of this MIB module was published in RFC 4748; for full legal notices see the Vamsi & Nazim Expires february 15, 2008 [Page 1] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html. Abstract Mobility access through IPv4 and IPv6 provides seamless services for the user terminals across different access networks. To provide seamless continuity while the mobile is moving from one access networks to another is provided by different mechanisms, on the whole the proposed mechanisms provides mobility with special requirements access mechanism. The foremost popular of the mobility mechanisms is provided by Charles Perkins in mobile IPv4 IETF RFC 2002. There are some of the issues that MIP doesn't provide as a total mobility solution. The Proxy MIP is a mobility mechanism to ensure mobility management of the user terminal in different access networks. This method provides the network based mobility management without any client interactions. By this method the signaling overhead and the latency during the handover and roaming is reduced. In this proposed mechanism the mobile node doesn't need to have support for the mobility instead the access network provide the mobility for the user terminal. Even though the proxy mobile IPv4 provides the mobility management there are some of the issues that have to be solved for the network controlled mobility management. In this proposed draft we proposed new mechanism using proxy mobile IP with the mobility extensions provided by the AAA server at the time of authentication and authorizing a user terminal. Later in the draft we discuss the novel architecture and packet format for PMIP interactions with AAA of the access networks. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................6 3. Proposed nouvelle solution for PMIP with integrated AAA architecture of the 3GPP and Wireless networks....................8 4. AAA mobility extensions for PMIP integrated architecture......10 5. Overview of PMIP operation with new mobility extensions with MPA and HA...........................................................11 6. Packet format for AAA mobility extensions, MPA and HA.........12 7. Sequence diagram of data and control information during the mobile terminal roaming in access networks.......................23 8. Being at home network.........................................23 9. Security Considerations.......................................24 10. IANA Considerations..........................................24 Vamsi & Nazim Expires August 15, 2008 [Page 2] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 11. Conclusions..................................................25 12. References...................................................25 Full Copyright Statement.........................................27 Intellectual Property............................................27 1. Introduction IP version 4 assumes that a node's IP address uniquely identifies the node's point of attachment to the Internet. Therefore, a node must be located on the network indicated by its IP address in order to receive datagram's destined to it, otherwise datagram's destined to the node would be undeliverable. For a node to change its point of attachment without losing its ability to communicate, currently one of the two following mechanisms must typically be employed: a) The node must change its IP address whenever it changes its point of attachment, or b) Host-specific routes must be propagated throughout much of the Internet routing fabric. Both of these alternatives are often unacceptable. The first makes it impossible for a node to maintain transport and higher-layer connections when the node changes location. The second has obvious and severe scaling problems, especially relevant considering the explosive growth in of portable devices connected to internet. The mobility management in the access networks is provided by the mobile IP for the seamless continuity of the services during handover and roaming. The traditionally user terminal does require a mobile node enabled with a client mobile IP, in some cases the devices can't be enabled with mobile IP, in this case the mobility must be provided without changing the software configuration of the devices and provide mobility from the access network side. By this method the controlling of the mobility of the mobile terminal can be more efficient. The Proxy Mobile IP [2] solution based on Mobile IP approach, handle the mobility management inside the network. Therefore network entities will require more capability than in the standard Mobile IP. The Foreign Agent is no longer capable to handle the mobility management in this new scenario, so we need to enhance its capabilities with the Mobility Proxing mechanism. This new entity called Proxy Mobile Agent replaces the Foreign Agent in the visiting network. It also handles the mobility registration with the Home Vamsi & Nazim Expires August 15, 2008 [Page 3] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Agent. This change is the most significant since the Mobile Node now lies outside the mobility registration procedure. In fact, the Mobile Node is not aware of its movement, the access networks deceives the host to believe that it is stationary in its Home Network. Since the Mobile Node does not need either movement detection or agent registration, the advertisements are no longer necessary. There are some of the requirements and features to be satisfied for the PMIP for mobility management: . Support Unmodified Hosts: As noted above, the protocol supports mobility to the nodes that doesn't have capability of mobility. . Airlink consumption: Mobility-related signaling over the air- link is eliminated. Considering that Network Address Translation (NAT) is ubiquitous in IPv4 networks, a mobile node needs to send keep alive at short intervals to properly maintain the NAT states. This can be performed by the MPA in the network which does not consume any air-link bandwidth. The Agent Advertisement is also eliminated in the protocol. . Support the Heterogeneous Wireless Link Network: One aspect is how to adopt the scheme to an access technology. Since Proxy Mobile IPv4 is based on a heterogeneous mobility protocol, it can be used for any type of access network. . The other aspect is how to support mobility across different access technologies. As long as the MPA can use the same NAI to identify the MN for various access networks, roaming between them is possible. . Support the IPv4 and IPv6: As IPv6 increases in popularity, the host will likely be dual stack. Draft-leung-mip4-proxy-mode-03.txt proposes a proxy mobile IP mechanism as shown in figure 1. +----+ +-------+ +-------+ +-----+ | | | | | | | | | MN | | MPA | | AAA | | HA | | | | | | | | | +----+ +-------+ +-------+ +-----+ Vamsi & Nazim Expires August 15, 2008 [Page 4] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 | | | | | 1a | 1b | | |<------------->|<----------->| | | | | | | 2 | | | |-------------->| | | | | 3 | | | |----------------------->| | | | | | | 4 | | | |<-----------------------| | 5 | | | |<--------------| | | | | | | | 6 | | | |<------------->|<===========>|<========>| | | | | Figure 1. PMIP mechanism Steps 1a and 1b involves layer 2 establishment with base station or with an access point and performs authentication and authorization. After successful authentication, MN does the DHCP request for the authentication during step 2 As mentioned in the draft information of the mobile node and its home agent information is passed to the MPA, in the step 3 with the available information of the MN, MPA does sends the registration request to the HA of the home network. Step 4 does involves the HA authenticating the mobility registration request from the MPA, sends the registration reply to MPA. After receiving the registration reply MPA sends the home address to the DHCP server. The DHCP server sends the DHCP reply to the MN. During step 6 IPCP/NCP procedures get completed and the MN's IP stack is ready to receive or send IP packets in case of 3GPP network. In case of wireless network DHCP is used, the regular DHCPREQUEST and DHCPACK messages are exchanged and the MN's IP stack is configured with the assigned IPv4 address. Even though the PMIP does provide the mobility solutions there are issues of user identity, mobility context of the user from the home network to the visiting network, assigning the home address to the user from the visiting network. In this draft we propose a new mechanism with the proxy mobile IPv4 as a mobility solution in Vamsi & Nazim Expires August 15, 2008 [Page 5] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 networks. In this mechanism during mobile node access authentication, MPA exchanges registration messages with HA to set up a proper routing and tunnelling the packets from/to MN. In this method during the authentication request of the mobile node is passed through the NAS or AP of the visiting network, this is passed to AAA server, authentication server checks the realm and does start the authentication procedure at the time of initialling the authorizing module of the mobile terminal it also initiates mobility extension module where AAA server initiates MPA of the access network and also informs the AAA server of the home network with the mobility extensions for the request of the mobility parameters of the user. The home AAA server interacts with the HA and collects the details of mobile node parameters and sends back the details as a reply for the request to the visiting AAA server. After the mobility context transfer the MPA does mobility registration to the HA for that mobile node. Later in this draft we provide more details of the interactions between different components of the architecture, packet formats and sequence of message exchanges during a mobility session of a user mobile node during a handover. 2. Conventions used in this document The keywords "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 [1]. Mobile Node (MN): Any IPv4 node that has the ability to physically access or roam across different networks. In Proxy Mobile IP, the Mobile Node does not need the Mobile IPv4 protocol stack. MN is provided with a long-term IP address on its Home Network - the Home Address. Corresponding Node (CN): The peer node that sends/receives packets to/from MN. Home Network: Network that MN is registered which provides its Home Address (long-term IP address that is issued to the Mobile Node). Visited Network: Current network where MN situates. Old Visited Network: The last network other than Home Network that the MN has left for the current location (Visited Network). Vamsi & Nazim Expires August 15, 2008 [Page 6] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Home Agent (HA): Data/routing anchor that maintains the location of the Mobile Node and tunnels the datagrams from/to the Mobile Node while it is away from home. HA takes part in the Mobility Registration. Foreign Agent (FA): A router in the Visited Network that handles the registration of the Mobile Node in the Visited Network, may offer the Foreign Agent Care-of Address to tunnel the packet to the Mobile Node. The Foreign Agent may serve as the default router for the Mobile Node. Mobility Proxy Agent (MPA): Mobile IPv4 entity that offers proxy mobility service for a Mobile Node by performing the registration function on the host's behalf. It helps tunneling data. Agent Advertisement: An advertisement message constructed with the special extension to declare the service offered by an agent (Home Agent or Foreign Agent). Access Point (AP): Point of attachment that connects the MN to network. Home AAA Server (AAAH) and Foreign AAA Server (AAAF): AAA server in the MN's Home Network and the AAA server in the local network (Visited Network), respectively. The address of the HA and MPA can be downloaded from the AAA Server (AAAH and/or AAAF). Care-of Address (CoA): The termination point of a tunnel toward a Mobile Node, playing role of intermediate destination for datagrams forwarded to the Mobile Node while it is away from home. In the Mobile IP, there are 2 types of care-of address: "Foreign Agent Care-of Address" (address of the Foreign Agent that registers the MN) and "Co-located Care-of Address" (address that the Visited Network issues to the Mobile Node, considered as a network interface of the Mobile Node in the local network). In the Proxy Mobile IP, the Care-of Address is the MPA's IP address. Vamsi & Nazim Expires August 15, 2008 [Page 7] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 3. Proposed nouvelle solution for PMIP with integrated AAA architecture of the 3GPP and Wireless networks In this new mechanism, mobility registration of the user terminal is performed by visiting access network and home access network. The user terminal does general authentication mechanism with the visiting access network with the help of EAP mechanism. The visiting access network does receive the authentication request from the user terminal from the NAS of the network. AAA of the visiting network and home networks are modified so that they can communicate with the HA and MPA of their respective networks. The visiting network initiates the authentication and mobility extension method whenever it receives the request from the NAS or AP of the access network. During initiation of mobility extensions AAA mobility extension process collects the data from the NAS request from the AAA server. If ever the authentication initiation is done the mobility extension does initiates the procedure for proxy mobile IP. AAA mobility process sends a mobility extension request to the home network of the terminal with the special attributes of the proxy mobile IP. The Home AAA server does receive the request for the mobility extension as well as the authentication. Home AAA server distinguishes the proxy mobile IP packet with the code and the attributes of the received packet. If ever the packet has to be proxy from a intermediate AAA server, that server adds the proxy attribute to the received packet and sends to the destination AAA server. After receiving the mobility extension packet from the visiting AAA server the home AAA server investigates the information available in the packet. After processing the request the mobility extension method prepares a request packet to the HA of the access network. This packet contains details of user id and its parameters. The HA server receives the request and with the user ID of the request it extract the information of SID, keys, home address and home agent address from the database. HA sends back the reply to the AAA of the home networks with the above mentioned data. AAA server receives the reply and process the information and sends back the reply message to the visiting AAA server. Visiting AAA server receives the reply from home server and process the reply and stores the data of the user in a temporary database. After processing the reply message, AAA server sends the MPA with a request for the mobility. This request contains details of user ID, SPI, keys, home address and home agent address. MPA receives the packet starts the mobility registration of the user with details from the AAA server. Vamsi & Nazim Expires August 15, 2008 [Page 8] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 MPA server initiates the registration request of the user with the home agent with the details provided by the AAA server. Registration involves the user SPI and the shared key mechanisms with the key available from the AAA server to the MPI. After successful registration of the user with the HA, MPI modify the DHCP server configuration with the user terminal details. These modifications contain the details of MAC address and the home address of the user in the DHCP server. After successful authentication of the user the user terminal starts the DHCP request. The AP or the NAS of the visiting network forward the request to the DHCP server. With the MAC address of the user terminal the modified DHCP server sends the reply to the user terminal with its home address. User terminal receives the reply and configure the IP address to the home address. Necessary modification has to be done on the visiting network to accommodate the terminal with the ARP, etc. +--------------+ |NAs sending | |request for | |authentication| +--------------+ | | +---|-------------------------------------+ +-----------+ | | Visiting | | home | | | AAA | | AAA | | | +--------+ | | +-------+ | | | |Authen | | | |Authent| | | | /|tication|<--A-->| |ication| | |+-------+ +--------+ / +--------+ | | +-------+ | ||check |----->|MN of |/ | | | | ||realm | |visiting|\ | | | | |+-------+ +--------+ \ +----------+ | | +-------+ | | | \| PMIP |<--B-->| PMIP | | | | | Managemen| | | |Manage | | |+--------+ +----------+ | | +-------+ | ||MN of | | | | | | ||Local | | | +--|--------+ ||network | | | | |+--------+ | | | | | | | | |+---------------+ | | | || Local | C | D Vamsi & Nazim Expires August 15, 2008 [Page 9] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 ||Authentication |--------+ | | | |+---------------+ | | | | | | | | | | | | | | +-------------------------|-------|-------+ | | | | +------+ +--------+ +-------+ +-----+ | User | | HA / | | | | User| | DB |<->| MPA |<---E---->| HA |<->| DB | +------+ +--------+ +-------+ +-----+ A - Mobile Node Authentication request and reply B - AAA mobility Context management C - AAA to MPA context transfer D - AAA to HA context transfer E - Mobile node registration request and reply 4. AAA mobility extensions for PMIP integrated architecture In this section we describe the detailed architecture of AAA for mobility extensions to provide mobility management during the roaming of a user in different access networks. In this process existing AAA architecture is modified to accommodate proxy mobile IP. In general the authentication information of the users are passed through the authenticator, this information is passed through NAS or AP of the access networks. AAA server authenticates the access networks AP or NAS initially and then process the user authentication request depending on the realm of the user. In this new method the mobility management of the user can be initiated during the authentication process. In this process, due to parallel operation of authentication and mobility management the overall latency of the user during handover and initial access can be reduced. When the authentication module is initiated in the AAA server at the request for authentication by the NAS or AP of the network, mobility management process does initiates. The details of NAS or AP, user details are processed and sent to the PMIP modules of AAA. AAA is modified and new attributes and codes are added for supporting the PMIP modules. As mentioned previously in the proposed solution section with new extensions, AAA of the home network can communicate with the visiting network can provide the mobility context management. With these mobility extensions AAA server can communicate with the MPA and HA of the access network. Vamsi & Nazim Expires August 15, 2008 [Page 10] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 On first hand the visiting AAA server communicates with the home network AAA server after receiving the authentication request using the mobility extensions with the user information available from the authentication request from the client using AAA mobile extension as a request. When the home network receives the request packet the AAA server process the information of the user. It sends a request to HA with the new mobility extension requesting the details of the user. HA after receiving the packet process the user details from its internal database and sends back the reply packet with home address and home agent address to the AAA home. Home AAA server sends back the reply to the visiting AAA server with the user details as a reply. After receiving the reply from the home AAA server the visiting AAA process the information of the user and sends a request for the mobility context with the new attribute request to the MPA. The MPA receive the user data sent by the visiting AAA server and temporarily stores in a local database. MPA with the available user information starts authenticating with the HA. According to the response the MPA sends the reply to AAA as a success or the failure of the mobility registration of the user to visiting AAA server. To clarification sake we kept all the attributes, data and code type details to one section 6 of this document. 5. Overview of PMIP operation with new mobility extensions with MPA and HA MPA exchanges registration messages with HA to set up a proper routing and tunneling the packets from/to MN. The MN broadcasts messages containing MN's Network Access Identifier (NAI) to request authentication/authorization. The AP transfers the request to the local AAA server (AAAF). If the MN is away from home, it is clear that the MN is out of the local authentication database; however, the local AAA server can use the NAI to identify the MN's Home Network. The authentication/authorization registration message then will be transferred to the AAA Server (AAAH) in the Home Network. Alongside with the authenticating validation, the AAAH searches for the information of the MN stored in the HA, containing MN's HA, NAI, and SPI. If the MN is back to its Home Network: the local AAA server sends a message to HA to deregister the MN instead of searching for the data. The MN's information will be transferred to the AAAF, which will deliver it to the MPA with the AP's MAC address included. Triggered by the AAA server, the MPA exchanges messages with the HA to demand for the Mobility Registration and Tunneling. The formats of the Mobile IPv4 Registration Request (MIPv4 RRQ - sent by the MPA) and Vamsi & Nazim Expires August 15, 2008 [Page 11] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 the Mobile IPv4 Registration Reply (MIPv4 RRP - sent back by the HA) are specified as in the section. After registration successful, MPA sends a message to inform DHCP about the MN's arrival. It forces the DHCP server to update the configuration file with the Mobile Node information. Finally, the MPA informs the AAAF about the registration successful. The Authentication Accept message is sent to the NAS granting network access to the MN. After the authentication success, the MN sends a Binding DHCPDISCOVER to request for the IP address. This message is formatted as described by the DHCP protocol (the CIADDR field is filled with the MN's IP). By searching the information of the Mobile Node in the configuration, the DHCP server replies with a DHCPOFFER message in which the YIADDR field is filled with the MN's Home Address and the default gateway address is MPA's. Next, the MN and DHCP server exchange the DHCPREQUEST and DHCPREPLY to complete this procedure. The MN is then ready to connect to the network with its Home Address. 6. Packet format for AAA mobility extensions, MPA and HA The AAA server builds Mobility Request message from the Access Request or EAP Request from the NAS. Remark that the intermediate AAA servers just pass through this step, adding Proxy Attribute and forwarding the Request. Mobility Request format: 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 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Vamsi & Nazim Expires August 15, 2008 [Page 12] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Note: the codes and the attributes in this document are taken as reference these can be changed according to the IANA consideration, in this case we used available values for developing the prototype, if there are any issues regarding these values we can change them in the next version. Code = (1 byte) Mobility_Request = 60. Identifier: (1 byte) number to match the Request/Reply. Length: (2 bytes) length of the message, including Code, Identifier, Length, Authenticator, Attributes. In the case that there is only mobility attribute, length = 350 Authenticator: The Authenticator field is 16 bytes. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Attributes: Mobility Attribute: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Length (2 bytes) | User's ID (1B)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (1byte) | Key (64 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = (1 byte) Mobility_Request_Attribute = 193. Length (2 bytes) = Length of the message = 332. User's ID: (256 bytes) extracted from the name of the user (ex: userID@realm). HA address: (4 bytes) Home Agent's IP address, filled with Zeros. Vamsi & Nazim Expires August 15, 2008 [Page 13] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Home Address: (4 bytes) Mobile Node's Home Address, filled with Zeros. SPI: 1 byte, filled with Zeros. Key: (64 bytes) public key of the HA, filled with Zeros. The AAAH will reply with a Mobility Response. HA/MPA consultation If AAA home server receives Mobility Request from a visiting server, the AAAH sends message to HA to fill the information required in the Mobility Request Attribute (fields that are filled with Zeros). Remark that the AAAH sends the HA Consultation message only by being triggered by the Mobility Request; the Access Request forces the AAAH to deregister the MN (See Section 10). - H1: Create a message from AAAH to the HA demanding for the necessary information: 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 (1byte) |Identifier (1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Point's MAC address (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP's MAC address (cont) | MN's MAC address (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's MAC address (continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (1 byte) | Key (64 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (continue) | | | Vamsi & Nazim Expires August 15, 2008 [Page 14] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code (1 byte) = HA_Consultation_Request = 63. Identifier: (1 byte) number to match Request/Response. Length (2 bytes) = total length of the message = 343 AP and MN's MAC address: These fields are practically used in the message from AAA to MPA. In the message from AAA to HA, these fields are filled with Zeros, and the HA just ignores it. But these fields SHOULD appear in the HA Consultation Message to identify the format of messages AAA-HA and AAA-MPA. It is very useful since the HA and MPA in the same network are usually installed in the same server. This identification simplifies the treatment of message in the HA/MPA server. Other fields are copied from the Mobility Attribute of the authentication request. - H2: HA looks for the required information in its database, save the AP and MAC address fields. If the information can't be found (this may be due to the modification of the administrator), HA will pass this phase, so that the message will be left Zeros. That allows the AAAH to detect the failure. - H3: HA sends back the reply to the AAA after filling the request's required fields and setting Code = HA_Consultation_Response = 64. - H4: The AAAH replies the AAAF with a Mobility Authentication Response, which is either an Accept or Reject message. The format of these messages is as same as the request, with different code and attributes: If the message from HA is not filled with Zeros (successful verification), the AAAH reply to the AAAF with Mobility Accept message which is copied from the Mobility Request whose the Attributes filled by the data gotten from HA. The Code field for this message is: Code = Mobility_Accept = 61. If the data from HA is filled with Zeros, the AAAH MUST reply the AAAF with a Mobility Authentication Reject message, with Code = Mobility Reject = 62. The Mobility Reject message doesn't contain the Mobility_Attribute, and may include Reply-Massage Attribute which contains the error message shown to the user [10]: Vamsi & Nazim Expires August 15, 2008 [Page 15] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type = 18 | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 18 for Reply-Message. Length: length of the attribute, including Type and Length field. Text: The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. If the registration failed, this field is filled with the message extracted from the MPA Mobility Registration Reply. Mobility Registration After receiving the Mobility Accept message, the AAAF makes MPA handle the Mobility Registration procedure. The MPA exchanges messages with the HA and DHCP server, then informs the AAAF about the result (success or not). The Mobility Authentication Reject causes the AAAF to send the Reject message to the NAS and terminate the whole procedure. - MR1: AAAF sends a MPA Mobility Registration Request message to MPA: the format is as same as HA Consultation message: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte)| Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User's ID (256 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Point's MAC address (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP's MAC address (cont) | MN's MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN's MAC address (continue) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address (4 bytes) | Vamsi & Nazim Expires August 15, 2008 [Page 16] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (1 byte) | Key (64 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (continue) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (1 byte) = MPA_Mobility_Registration_Request = 65. Identifier: (1 byte) number to match Request/Response. Length (2 bytes) = total length of the message = 343. Other fields save AP and MN's MAC address are copied from the Mobility Attributes of the Authentication Response. - MR6: MPA Mobility Registration Reply to AAAF: The MPA sends back the reply to the AAA after successful communication with the DHCP server, or if it detects any error (registration unsuccessful, DHCP server refusal to register the Mobile Node, or requests cannot reach the destination). In this latter the MPA sends a reject message to the AAA server (reply with response = 1 or 2). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response (1B) | Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = MPA_Mobility_Registration_Reply = 66 Response = 0 if successful, = 1 if unsuccessful with message, = 2 if unsuccessful without message. In the unsuccessful case (Response != 0), AAA will sends an Access_Reject message to the NAS. Otherwise, if the Response Code = Vamsi & Nazim Expires August 15, 2008 [Page 17] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 1, the text in the Message field can be used in the Reply-Message Attribute in the Mobility Authentication Reject message [8]. - MR2: Registration For the convenience of use of Client Mobile (Mobile IPv4) and Proxy Mobile, the MPA and HA should use the Mobility Registration Request as specified as in RFC3344 (this simplicity allows the MPA to handle the Mobile IP protocol): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 1 (Registration Request) S Simultaneous bindings. If the 'S' bit is set, Home Agent retains the Mobile Node's prior mobility bindings. B Broadcast datagrams. If the 'B' bit is set, HA tunnel to MN any broadcast datagrams that it receives on the home network. D Decapsulation by mobile node. If the 'D' bit is set, the Mobile Node will decapsulate datagrams which are sent to the care-of address. That is, the mobile node is using a co-located care-of address. This bit is only for the Mobile Node that support mobility: D=0 for Proxy Mobile IP. Vamsi & Nazim Expires August 15, 2008 [Page 18] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 M Minimal encapsulation. If the 'M' bit is set, the mobile node requests that its home agent use minimal encapsulation for datagrams tunnelled to the mobile node. G GRE encapsulation. If the 'G' bit is set, HA is required to use GRE encapsulation for datagrams tunnelled to the mobile node. r Sent as zero; ignored on reception. SHOULD NOT be allocated for any other uses. T Reverse Tunnelling requested. T = 1 with Proxy Mobile IP. x Set as zero; ignored on reception. Lifetime The number of seconds remaining before the registrations considered expired. A value of zero indicates a request for deregistration. A value of 0xffff indicates infinity. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Care-of Address The IP address for the end of the tunnel. Here is the MPA's. Identification A 64-bit number, used for matching Registration Requests with Registration Replies, and for protecting against replay attacks of registration messages. Extensions The fixed portion of the Registration Request is followed by some extension. In this document we don't discuss about the mobility registration extension. Vamsi & Nazim Expires August 15, 2008 [Page 19] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 HA reply with Mobility Registration Reply, formatted as specified in RFC3344: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code (1 byte)| Lifetime (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification (8 bytes) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 3 (Registration Reply) Code A value indicating the result of the Registration Request. (List of currently defined Code values [3]). Registration successful: 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported Registration failed: Code > 1 Lifetime 2 bytes. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Vamsi & Nazim Expires August 15, 2008 [Page 20] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Identification Match the request/Reply (8 bytes) Extensions: In this document we don't discuss about the mobility registration extension. MR4: MPA sends DHCP Mobility Registration Request to DHCP server: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Identifier (1 byte) | Length (1B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address (continue) | Home Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address (continue) | Action (1B) | MPA's MAC add | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA's MAC address (continue) (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA's MAC add | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = DHCP_Mobility_Registration = 67 Identifier: match Request/Response Length = 21: length of the message, including the Type and Identifier fields MAC address: MN's MAC address Home Address = MN's Home Address. Action: (1 byte) = 0 - binding update: the DHCP server updates its configuration file with the MN's new entry: Vamsi & Nazim Expires August 15, 2008 [Page 21] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 MN's MAC address --- MN's IP address --- Default Gateway = MPA's MAC address If Action = 1 - remove entry: cause the DHCP server to remove the MN's entry in its configuration file. This action is used in the Registration Revocation Procedure. As receiving the message from the MPA, the DHCP server updates its configuration with the information supplied by the MPA. Since then, as soon as the DHCP server receives the (Binding) DHCPDSICOVER message from the MN, it will exchange the messages with the MN granting the MN keep its Home Address; also indicates the MPA as MN's default gateway. MR5: DHCP Mobility Registration Reply to MPA The message is formatted as same as the reply from MPA to AAA 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1 byte) | Identifier(1B)| Length (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response (1B) | Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = DHCP_Mobility_Registration_Reply = 68 Length = length of the message including the Type and Identifier fields Response Code = 0: accept, = 1 reject with message, = 2 reject without message. If the response Code is other than 0, the MPA MUST response with the AAA with MPA Mobility Registration Reply whose Response and Message fields copied from DHCP Mobility Registration Reply message. Message: this message will be used in the response from MPA to AAA. Vamsi & Nazim Expires August 15, 2008 [Page 22] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 7. Sequence diagram of data and control information during the mobile terminal roaming in access networks +----+ +-------+ +-------+ +-------+ +-----+ | | | | | | | | | | | MN | | AAA V | | MPA | | AAA H | | HA | | | | | | DHCP | | | | | +----+ +-------+ +-------+ +-------+ +-----+ | | | | | | 1 | | | | |<------------->| | | | | | 2 | | | | |<-----------------------| | | | | | 3 | | | | |<----------| | | | | | | | 4| | | | |<-----------------------| | | | | | | | | 5 | | | | |<------------| | | | | | | | | | | |6 | | | |<---------------------| | | | | | | | | | | In the step 1 the mobile node send the authentication request to the NAS or the AP of the visiting network. The NAS forwards the request to the AAAF server. The AAAF server identifies the request and prepares the mobility and authentication mechanisms. In step 2 the AAAF sends a request to the AAAH for the for the mobility request for the user with the ID from the authentication request from the NAS. After receiving the request from the AAAF the AAAH sends the HA for the user consultation request and HA responds with the details as a response. The AAAH sends back the response to AAAF in step 4 as a response with the user details, home address, home agent details and the user temporary key to the AAAF. In step 5 the AAAF sends the user details to the MPA. In step 6 MPA and HA does the registration for the mobile node and provides the tunnel for mobility management. 8. Being at home network As the MN returns its Home Network, this fact is revealed to the AAA server (AAAH) by receiving a Access_Request from a NAS which it finds an entry matching the Access_Request, the AAA server will sends a HA Registration Revocation Request to HA which erases the MN Vamsi & Nazim Expires August 15, 2008 [Page 23] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 entry in its Mobility Registration Database and sends an MIPv4_Regstration_Revocation to the MPA on the last network that MN has visited. Recall that the Mobility Request message makes the AAAH send a HA Conslultation message in order to get information of the MN, while the Access_Request makes the AAAH send a HA Registration Revocation to erase the MN's mobility registration entry. The message format is as same as the MIPv4 Registration Revocation Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1B) | Identifier (1B) | Length (1B) | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = HA_Registration_Revocation_Request = 4 Identifier: 1 byte Length = 7 Home Address = MN's Home Address The HA replies with an ACK. 9. Security Considerations The HA and the MPA to the RADIUS server transactions must be adequately secured. Otherwise there is a possibility that fraudulent values are received from a rogue RADIUS server. The new attributes defined in this document do not introduce additional security considerations. 10. IANA Considerations The type of attribute PMIP MPA/HA with AAA, AAA new attributes and codes configuration mode MUST be assigned by IANA. The value of the attribute Framed-Protocol MUST also be assigned by IANA. In this draft for demonstrating the prototype we have used available IANA values assigned to the AAA. Vamsi & Nazim Expires August 15, 2008 [Page 24] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 11. Conclusions The Proxy Mobile IP is a development of the Mobile IP in which the registration is done by the network entity. Hence, the Mobile Node does not require the Mobile IP stack to roam over the network without losing the IP address, so can be applied to the unchanged devices. Using this proposed mechanism the authentication and the mobility management of the user during the access is performed in parallel, in this way the latency during the authentication and re- authentication is reduced. In this mechanism using the context management the control of user can be maintained according to the access networks. We already demonstrated the capabilities the propose solution using a testbed. We developed the attributes and modules proposed in this architecture and implemented over a live testbed. In the future we want to enhance proposed architecture to address the issues which may have to be addressed for certain functionalities proposed by the working group. 12. References 12.1. Normative References [1] Perkins C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] Leung K., Dommety G., Yegani P, Chowdhury K., "Mobility Management using Proxy Mobile IPv4", Internet-Draft, January 2007. [3] C. Rigney et al "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997 [5] Perkins C., Calhoun P., "AAA Registration for Mobile IPv4", Internet-Draft, June 2004 [6] Plummer D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982 Vamsi & Nazim Expires August 15, 2008 [Page 25] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 [7] Rigney C., Willens S., Rubens A., Simpson W., "Remote Authentication Dial in User Service (RADIUS)" - RFC2865, June 2000 [8] Kulkarni M., Patel A., Leung K., "Mobile IPv4 Dynamic Home Agent (HA) Assignment" - RFC4433, March 2006 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [9] Postel J., "Multi-LAN Address Resolution", RFC 925, October 1984 [10] Carl-Mitchell S., Quarterman J., "Using ARP to Implement Transparent Subnet Gateways", RFC 1027, October 1987 [11] Aboba B., "IANA Considerations for RADIUS" - RFC2869, July 2003 Author's Addresses Vamsi Krishna Gondi, LRSM research lab, University of Evry, Evry, France. Email: gondi@ensiie.fr Nazim Agoulmine, LRSM research lab, University of Evry, Evry, France. Email: nazim.agoulmine@iup.univ-evry.fr Toan TRAN, Ecole Politechnique, France Email: khanh.tran@polytechnique.edu Vamsi & Nazim Expires August 15, 2008 [Page 26] Internet-Draft AAA and Proxy Mobile IPv4 February 2008 Full 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. 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. Intellectual Property 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. Vamsi & Nazim Expires August 15, 2008 [Page 27]