Internet DRAFT - draft-gondi-radext-radius-mobility
draft-gondi-radext-radius-mobility
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]
