Request for Comments: 4004 P. Calhoun
Category: Standards Track Cisco Systems, Inc.
T. Johansson
Bytemobile Inc
C. Perkins
Nokia Research Center
T. Hiller, Ed.
P. McCann
Lucent Technologies
August 2005
Diameter Mobile IPv4 Application
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies a Diameter application that allows a Diameter
server to authenticate, authorize and collect accounting information
for Mobile IPv4 services rendered to a mobile node. Combined with
the Inter-Realm capability of the base protocol, this application
allows mobile nodes to receive service from foreign service
providers. Diameter Accounting messages will be used by the foreign
and home agents to transfer usage information to the Diameter
servers.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
1. Introduction
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point
of attachment to the Internet while maintaining its fixed home
address. Packets directed to the home address are intercepted by a
Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at
its current point of attachment. Optionally, a Foreign Agent (FA)
may be deployed at this point of attachment, which can serve as the
tunnel endpoint and may also provide access control for the visited
network link. In this role, the FA has to authenticate each MN that
may attach to it, whether the MN is from the same or a different
administrative domain. The FA has to verify that the MN is
authorized to attach and use resources in the foreign domain. Also,
the FA must provide information to the home administrative domain
about the resources used by the MN while it is attached in the
foreign domain.
The Authentication, Authorization, and Accounting (AAA) requirements
for Mobile IPv4 are described in detail in other documents [MIPREQ,
CDMA2000]. This document specifies a Diameter application to meet
these requirements. This application is not applicable to the Mobile
IPv6 protocol.
Message formats (e.g., as in section 5.1) are specified as lists of
Attribute-Value Pairs (AVPs) using the syntax as described in RFC
2234 [ABNF]. This includes the use of the "*" symbol to denote zero
or more occurrences of an AVP.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
1.1. Entities and Relationships
The Diameter Mobile IPv4 Application supports the HA and FA in
providing Mobile IPv4 service to MNs. Both the HA and FA act as
Diameter clients. The MNs interact with the HA and FA by using only
Mobile IPv4 and therefore do not implement Diameter.
The FA, when present, is always assumed to exist in the visited
administrative domain. The HA may be statically or dynamically
allocated to the MN in the home administrative domain or may be
dynamically allocated to the MN in a visited administrative domain.
The home domain contains a home AAA server (AAAH), and the visited
domain contains a foreign AAA server (AAAF). When the MN is "at
home" (present on its home network), the AAAH and AAAF may be the
same.
1.2. Mobility Security Associations
The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a
Mobility Security Association (MSA) between the MN and HA (MN-HA
MSA). The MN-HA MSA is used to authenticate, by using a keyed hash-
style algorithm, the Mobile IP Registration Request that is sent from
the MN to the HA. It is important to authenticate Registration
Requests, as they inform the HA about the MN’s current Care-of-
Address, which is the destination for tunneled packets from the home
network. Without authentication, malicious attackers would be able
to redirect packets to anywhere on the Internet. The MSA comprises
an agreement on a Security Parameters Index (SPI, a 32-bit number)
that will be used to refer to the MSA, an algorithm that will be used
to compute keyed hashes over messages, and a shared secret key. To
enable authentication of a message, the sender appends a Mobile IP
Authentication Extension that contains the SPI and the result of
running the keyed hash over the entire previous contents of the
message. The recipient checks the Authentication Extension by
looking up the MSA based on the SPI, re-computing the keyed hash, and
verifying that the result is equal to the contents of the received
Authentication Extension.
The base Mobile IPv4 protocol also supports an optional MSA between
the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by
the FA to authenticate each Registration Request passing through it
on the way to the HA. Although not critical to the operation of the
base protocol, the MN-FA MSA is useful when the FA has to know the
authenticity of a Registration Request; e.g., when it will be
generating accounting records for a session. The MN-FA MSA may also
be useful in future work related to handoff optimization.
Similarly, Mobile IPv4 supports an optional MSA between the FA and HA
(FA-HA MSA). The FA-HA MSA is useful for authenticating messages
between the FA and HA, such as when the HA seeks to inform the FA
that it has revoked a Mobile IP registration.
Note that configuration of MSAs that involve FAs is substantially
more difficult than configuring the one between the MN and HA,
because the MN and HA are often in the same administrative domain and
the MN will retain the same HA for long periods of time. In
contrast, the MN is likely to encounter many FAs over time and may
often find itself in foreign administrative domains.
The base Mobile IPv4 protocol assumes that MNs are identified by
their static home IP addresses and that all MSAs are statically
preconfigured. The Diameter Mobile IPv4 application, together with
extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4
protocol, allows an MN to be dynamically assigned a home address
and/or home agent when it attaches to the Internet. This set of
specifications also supports the dynamic configuration of the MN-HA,
MN-FA, and FA-HA MSAs. The dynamic configuration of these
relationships is important to support deployments in which the MN can
attach to a visited network without having a pre-established
relationship with it.
Initially, the MN is assumed to have a long-term AAA security
association only with the AAAH. This security association is indexed
by the MN’s NAI, and, like the MSAs, comprises an agreement on a SPI,
an algorithm, and a shared secret key. The MN enters a visited
network and requests service from some FA by sending a Mobile IPv4
Registration Request. The FA contacts an AAAF in its own
administrative domain to authenticate and authorize the request for
service. The AAAF and AAAH may establish a Diameter session directly
with each other, such as via a Diameter Redirect, or may pass
messages via a network of Diameter proxies. Where the AAAF and AAAH
route messages to each other through proxies, rather than a direct
connection, transitive trust is assumed. MNs can include their
Network Access Identifier (NAI) in a Mobile IPv4 Registration Request
[MIPNAI], which serves in place of the home address to identify the
MN. The NAI is used to route Diameter messages toward the correct
AAAH. This use of the NAI is consistent with the roaming model
defined by the ROAMOPS Working Group [EVALROAM, RFC2607].
The AAAH can authenticate the Registration Request with the use of
the MN-AAA security association [MIPCHAL]. If authentication is
successful, the AAAH then generates and distributes MSAs to the MN,
HA, and FA. For each of the MSA pairs that involve the MN (i.e.,
MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce
and then hashes it together with the MN-AAA shared key to derive the
session key for the MSA pair. The nonces are sent to the HA that
includes them in the Registration Reply, which enables the MN to
derive the same keys [MIPKEYS]. At the same time, the AAAH must
distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA
and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to
the FA. These are sent in Diameter AVPs and must be independently
secured by using IPSec or TLS between the AAAH and the FA and between
the AAAH and the HA. See section 8 for more information on key
derivation and distribution.
Note that MSAs in Mobile IP are unidirectional in that, for example,
the MN-HA MSA (used to protect traffic from the MN to the HA) and the
HA-MN MSA (used to protect traffic from the HA to the MN) can use
different SPIs, algorithms, and shared secrets. This is true of the
base Mobile IP protocol despite common existing practice during
manual configuration of MSAs in which all parameters are set to the
same value in both directions. This document supports the use of
different SPIs in each direction; however, it only supports the
distribution of a single session key for each pair of MSAs between
two nodes. The security implications of this are discussed in
section 13. This document sometimes names only one of the two
unidirectional MSAs when referring to the distribution of the single
shared secret and the pair of SPIs for the pair of MSAs between two
entities.
1.3. Handoff
In addition to supporting the derivation and transport of the MN-HA,
MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff.
When an MN moves from one point of attachment to another, the MN can
continue the same Mobile IPv4 session by using its existing HA and
home address.
The MN accomplishes this by sending a Mobile IPv4 Registration
Request from its new point of attachment. To enable a single set of
accounting records to be maintained for the entire session, including
handoffs, it is necessary to allow the AAAH to bind the new
registration to the pre-existing session. To enable the Mobile IPv4
Registration Request to be routed to the same AAAH, the MN SHOULD
include the AAAH NAI [AAANAI] in such re-registrations. Also, to
assist the AAAH in routing the messages to the MN’s existing HA the
mobile node SHOULD include the HA NAI [AAANAI] in such re-
registrations. If the mobile node does not support the Mobile IPv4
AAA NAI extension [AAANAI], this functionality is not available.
1.4. Structure of the Document
The remainder of this document is structured as follows. Section 2
provides acronym definitions. Section 3 provides some examples and
message flows illustrating both the Mobile IPv4 and Diameter messages
that occur when a mobile node attaches to the Internet. Section 4
defines the relationship of this application to the Diameter Base
Protocol. Section 5 defines the new command codes. Section 6
defines the new result codes used by this application. Section 7
defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8
gives an overview of the key distribution capability, and Section 9
defines the key distribution AVPs. Section 10 defines the accounting
AVPs, and section 11 contains a listing of all AVPs and their
occurrence in Diameter commands. Finally, sections 12 and 13 give
IANA and security considerations, respectively.
2. Acronyms
AAAH Authentication, Authorization, and Accounting Home
AAAF Authentication, Authorization, and Accounting Foreign
AMA AA-Mobile-Node-Answer
AMR AA-Mobile-Node-Request
ASR Abort-Session-Request
AVP Attribute Value Pair
CoA Care-of-Address
FA Foreign Agent
FQDN Fully Qualified Domain Name
HA Home Agent
HAA Home-Agent-MIP-Answer
HAR Home-Agent-MIP-Request
MN Mobile Node
MSA Mobility Security Association
NAI Network Access Identifier
RRQ Registration Request
SPI Security Parameters Index
STR Session-Termination-Request
3. Scenarios and Message Flows
This section presents four scenarios illustrating Diameter Mobile
IPv4 application and describes the operation of key distribution.
In this document, the role of the "attendant" [MIPREQ] is performed
by either the FA (when it is present in a visited network) or the HA
(for co-located mobile nodes not registering via an FA), and these
terms will be used interchangeably in the following scenarios.
3.1. Inter-Realm Mobile IPv4
When a mobile node requests service by issuing a Registration Request
to the foreign agent, the foreign agent creates the AA-Mobile-Node-
Request (AMR) message, which includes the AVPs defined in section 7.
The Home Address, Home Agent, Mobile Node NAI, and other important
fields are extracted from the registration messages for possible
inclusion as Diameter AVPs. The AMR message is then forwarded to the
local Diameter server, known as the AAA-Foreign, or AAAF.
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |