Network Working Group Vamsi Krishna.G, Internet Draft Nazim Agoulmine, Expires: August 2008 LRSM, UEVE, France February 15, 2008 Radius Mobility Extensions draft-gondi-radext-radius-mobility-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 RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html. Vamsi, Nazim Expires August 15, 2008 [Page 1] Internet-Draft Radius Mobility Extensions February 2008 Abstract Increase in the usage of different access networks, the role of Radius server is increased to provide access across different access networks and access technologies. AAA server provides access to user terminals in different security mechanisms in access networks. Due to the robust architecture of radius server, the functionalities of server can be extended to provide different services other than the authentication and access to the user terminal. In this draft we are proposing to extend the functionalities of the radius server for the mobility management of the user in the access networks. In this process the Radius server performs the mobility context management of the user when its roaming or during handover from the visiting network and the home network. In this draft we are proposing to accommodate Proxy Mobile IP (PMIP) using these extensions. In this proposed architecture we have defined new attributes and packet format when a Radius server communicates with the MPA/HA of the PMIP architecture as well as with another Radius server for context management. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Radius mobility extension mechanism............................5 3.1. Process mechanisms for Mobility Extensions for Radius.....6 3.1.1. Radius mobility extensions for PMIP process mechanism7 4. Working methodology of PMIP with the new mobility extensions inside Radius server..............................................8 5. New mobility extensions message exchange.......................9 6. Packet format for AAA for new mobility extensions.............10 7. Security Considerations.......................................15 8. IANA Considerations...........................................16 9. Conclusions...................................................16 10. Acknowledgments..............................................16 11. References...................................................17 11.1. Normative References....................................17 11.2. Informative References..................................17 Author's Addresses...............................................17 Full Copyright Statement.........................................18 Intellectual Property............................................18 Vamsi & Nazim Expires August 15, 2008 [Page 2] Internet-Draft Radius Mobility Extensions February 2008 1. Introduction The functionalities of Radius server can be extended with the existing mechanisms to provide extra services in the mobile and wireless networks. There exists different mechanisms where the functionalities of the Radius server are extended to provide services for the user. Traditionally in wireless and cellular networks the Radius server provides authentication, access and accounting of the users when they are accessing the service provider network. In the context of this draft we are introducing new mechanism to extend the Radius functionalities for the mobility management and mobility context transfer in different access networks. The main aim of this mechanism is to provide seamless access to users when they are roaming or handover from one access network to another and also eventually from one technology to another technology (Heterogeneous Networks). In this draft we have provided detailed mechanism on how the mobility context transfer is provided with the new mobility attributes inclusion in the existing Radius server. In the mobility management context we interrogated two mechanisms one is Client Mobile IP and the second one is Proxy Mobile IP to use the mechanisms proposed in this draft. In this draft we provide details for the Proxy Mobile IP management. But with the minor modifications the proposed mechanism can be adapted to the Client Mobile IP. In this draft we proposed Radius extensions for Proxy Mobile IP(PMIP) as well as Client mobile IP. The detailed analysis of Radius extensions for PMIP is also presented in this draft. Later we proposed the mobility attributes for the AAA extensions, detailed architecture and protocol formats. The exchanged messages between the components of the architecture are discussed. Software architecture of the modified AAA server is also described in this draft. 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 Vamsi & Nazim Expires August 15, 2008 [Page 3] Internet-Draft Radius Mobility Extensions February 2008 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). 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 Vamsi & Nazim Expires August 15, 2008 [Page 4] Internet-Draft Radius Mobility Extensions February 2008 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. Client Mobile IP (CMIP) Client Mobile IPv4 enables user devices to roam over different networks based on data/routing anchor such as Home Agent and Foreign Agent. While away from home, a user device (Mobile Node) is attached with a care-of address that locates the current position of the device. The method to deliver packets to the Mobile Node is to tunnel the packets from the Home Agent to the Mobile Node through the care-of address Proxy Mobile IP (PMIP) The Proxy Mobile IP solution is based on the approach of the Mobile IP. To handle the mobility management, the network entities need more capability than in the standard Mobile IP (aka Client Mobile IP) solution. The Foreign Agent is no longer capable to handle the mobility management in this new scenario, so we need a more capable entity: the Mobility Proxy Agent. This agent replaces the role of the Foreign Agent in the network. It also handles the mobility registration with the Home Agent. This change is the most significant since the Mobile Node now lies outside the mobility registration procedure 3. Radius mobility extension mechanism 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 Vamsi & Nazim Expires August 15, 2008 [Page 5] Internet-Draft Radius Mobility Extensions February 2008 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 and can provide the mobility context management. With these mobility extensions AAA server can communicate with the MPA and HA of the access network. 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. After receiving the packet HA 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 receives 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 a failure of the mobility registration of the user to visiting AAA server. For the sake of clarification we kept all the attributes, data and code type details to one section 5 of this document. 3.1. Process mechanisms for Mobility Extensions for Radius In this section we provide details of the process mechanisms of the extended Radius server when a user roams into different access networks with different mobility solutions. In this section we Vamsi & Nazim Expires August 15, 2008 [Page 6] Internet-Draft Radius Mobility Extensions February 2008 explain details of our solution which is based on the PMIP but it can be extended further to accommodate mobility context for CMIP. 3.1.1. Radius mobility extensions for PMIP process mechanism Whenever there is a request for authentication received from the NAS, radius server does initially identify the MN belongs to the local network or the visiting network. The mobility context is initiated in parallel with the authentication modules in the radius server. After initiating the mobility module in the radius server, the server has to decide with whom to initiate a dialog according to the mobile node realm. If the MN belongs to local network the radius mobility module sends the registration with the user detailed collected from the NAS. With the available details the HA does the registration of the user. In the other case when mobile node belongs to the visiting network, radius server initiates the Mobility Management (MM) context. In this process the mobility module in the Radius server collects the details of the MN from the NAS request and sends that information to the home network depending on the network access identifier (NAI) of the MN. Upon receiving the request the Home Radius server collects the details of the MN from the HA of the access network. After collecting the details Home Radius server sends the response with the details of the MN to the visiting networks Radius server. The visiting Radius server upon receiving the response sends the details to their MPAs in the access networks. +--------------+ |NAS sending | |request for | |authentication| +--------------+ +------------------------|--------------------+ | +-----------+ AAA visiting | | |Identify MN| | | |belongs to | | | |local or | | | |visiting | | | +-----------+ | | | | | + | | +---------------------+ | Vamsi & Nazim Expires August 15, 2008 [Page 7] Internet-Draft Radius Mobility Extensions February 2008 | Home|network visiting|network | | +---------------+ +-------------+ | +--------+ | |HA registration| |MM context | | A |AAA Home| | |MN is in home | |transfer INIT| |<-->|Network | | +---------------+ +-------------+ | B +--------+ +---------------------------------------------+ A - MN details request B - MN details response with failure or success 4. Working methodology of PMIP with the new mobility extensions inside Radius server +--------------+ |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 ||Authentication |--------+ | | | |+---------------+ | | | | Vamsi & Nazim Expires August 15, 2008 [Page 8] Internet-Draft Radius Mobility Extensions February 2008 | | | | | | | | | | +-------------------------|-------|-------+ | | | | +------+ +--------+ +-------+ +-----+ | User | | HA / | | | | User| | DB |<->| MPA |<---E---->| HA |<->| DB | +------+ +--------+ +-------+ +-----+ A - Mobile Node Authentication request and reply B - AAA mobility Context management request and reply C - AAA to MPA context transfer D - AAA to HA context transfer E - Mobile node registration request and reply 5. New mobility extensions message exchange +----+ +-------+ +-------+ +-------+ +-----+ | | | | | | | | | | | MN | | AAAF | | MPA | | AAAH | | HA | | | | | | DHCP | | | | | +----+ +-------+ +-------+ +-------+ +-----+ | | | | | | 1 | | | | |<------------->| | | | | | 2 | | | | |<-----------------------| | | | | | 3 | | | | |<------------| | | | | | | | 4| | | | |<-----------------------| | | | | | | | | 5 | | | | |<------------| | | | | | | | | | | |6 | | | |<-----------------------| | | | | | | | | | | Vamsi & Nazim Expires August 15, 2008 [Page 9] Internet-Draft Radius Mobility Extensions February 2008 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 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. 6. Packet format for AAA for new mobility extensions 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- 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. Vamsi & Nazim Expires August 15, 2008 [Page 10] Internet-Draft Radius Mobility Extensions February 2008 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. 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. Vamsi & Nazim Expires August 15, 2008 [Page 11] Internet-Draft Radius Mobility Extensions February 2008 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code (1 byte) = HA_Consultation_Request = 63. Identifier: (1 byte) number to match Request/Response. Vamsi & Nazim Expires August 15, 2008 [Page 12] Internet-Draft Radius Mobility Extensions February 2008 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]: 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Vamsi & Nazim Expires August 15, 2008 [Page 13] Internet-Draft Radius Mobility Extensions February 2008 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 effect 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (1 byte) | Key (64 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (continue) | | | Vamsi & Nazim Expires August 15, 2008 [Page 14] Internet-Draft Radius Mobility Extensions February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 = 1, the text in the Message field can be used in the Reply-Message Attribute in the Mobility Authentication Reject message [8]. 7. 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 Vamsi & Nazim Expires August 15, 2008 [Page 15] Internet-Draft Radius Mobility Extensions February 2008 defined in this document do not introduce additional security considerations. 8. 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. 9. Conclusions Using this proposed mechanism the authentication and the mobility management of the user during an 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. Using this mechanism the attributes proposed in the architecture can be implemented in efficient manner, during designing this solution we have taken careful consideration of compatibility with the existing solutions so the up gradation to this proposed solution in future can be ease. 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. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Vamsi & Nazim Expires August 15, 2008 [Page 16] Internet-Draft Radius Mobility Extensions February 2008 11. References 11.1. Normative References [1] C. Rigney et al "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000 [2] Perkins C., Calhoun P., "AAA Registration for Mobile IPv4", Internet-Draft, June 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 11.2. Informative References [3] Perkins C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Leung K., Dommety G., Yegani P, Chowdhury K., "Mobility Management using Proxy Mobile IPv4", Internet-Draft, January 2007. [5] Aboba B., "IANA Considerations for RADIUS" - RFC2869, July 2003 Author's Addresses Vamsi Krishna Gondi, LRSM Research Lab, University of Evry, Evry, France, 91000 Email: gondi@ensiie.fr Nazim Agoulmine, LRSM Research Lab, University of Evry, Evry, France, 91000 Email: nazim.agoulmine@iup.univ-evry.fr Vamsi & Nazim Expires August 15, 2008 [Page 17] Internet-Draft Radius Mobility Extensions 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 18]