Network Working Group M. Nakhjiri, Ed.
Request for Comments: 5030 Motorola
Category: Informational K. Chowdhury
Starent Networks
A. Lior
Bridgewater Systems
K. Leung
Cisco Systems
October 2007
Mobile IPv4 RADIUS Requirements
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document provides an applicability statement as well as a scope
definition for specifying Remote Authentication Dial-In User Service
(RADIUS) extensions to support Mobile IPv4. The goal is to allow
specification of RADIUS attributes to assist the Mobile IPv4
signaling procedures.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Nakhjiri, et al. Informational [Page 1]
RFC 5030 Mobile IPv4 RADIUS Requirements October 2007
1. Introduction
To kick start the Mobile IPv4 [RFC3344] processing of its packets by
Mobile IP agents, a mobile node (MN) needs to be able to acquire a
pair of home and care of addresses (HoA and CoA, respectively), find
a willing agent to act as a Home Agent (HA) for the MN and perform a
registration process with the HA. The registration process consists
of an exchange of a registration request and a registration reply
message between the MN and the HA. The specification in [RFC3344]
allows an MN to start the registration process prior to having
acquired its home address or the address of its HA. Acquiring those
parameters by the MN is typically part of a process referred to as
bootstrapping.
Successful processing of registration request and reply messages,
among other things, depends on successful creation and verification
of a number of authentication extensions developed specifically to
protect the integrity and security of these messages and the entities
processing them, i.e., MN, HA and some times, Foreign Agents (FAs)
[RFC3344]. Creation as well as verification of these extensions
requires existence of trust relationships and shared keys between MN
and each of the mobility agents. However, creation of these trust
relationships, typically referred to as mobility security
associations (MSAs), is considered outside the scope of the base
Mobile IPv4 specification defined in [RFC3344]. Avoiding the
scalability issues arising from creating static security associations
between an MN and all possible mobility agents is desired. Thus,
establishing the associations dynamically, using the pre-existing
relationship between the MN and the AAA server, is preferred.
To allow for utilization of an existing AAA infrastructure in the
bootstrapping of the Mobile IPv4 parameters and security
relationships, the Mobile IPv4 working group has developed Mobile
IPv4 extensions to allow the MN to authenticate to the home AAA
server [RFC4721]. The extensions also allow the MN to request
assistance from the AAA server in creation of mobility security
associations [RFC3957] with the mobility agents, using the pre-
established trust relationship between the MN and its home AAA
server.
While Mobile IPv4 extensions are necessary for implementing a
utilization of the AAA infrastructure for Mobile IPv4 purposes, they
are not sufficient. The interaction between the MN and the mobility
agents (HA and FA) is based on Mobile IP signaling. However, the