[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 19 20 RFC 4004
AAA Working Group Pat R. Calhoun
Internet-Draft Black Storm Networks
Category: Standards Track Tony Johansson
<draft-ietf-aaa-diameter-mobileip-09.txt> Ericsson Inc
Charles E. Perkins
Nokia Research Center
March 2002
Diameter Mobile IPv4 Application
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2002. All Rights Reserved.
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.
et al. Calhoun expires September 2002 [Page 1]
Internet-Draft March 2002
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Inter-Realm Mobile IP
1.3 Support for Mobile IP Handoffs
1.4 Allocation of Home Agent in Foreign Network
1.5 Co-located Mobile Node
1.6 Diameter Session Termination
1.7 Advertising Application support
1.8 Fast Handoff support
2.0 Command-Code Values
2.1 AA-Mobile-Node-Request
2.2 AA-Mobile-Node-Answer
2.3 Home-Agent-MIP-Request
2.4 Home-Agent-MIP-Answer
3.0 Result-Code AVP Values
3.1 Transient Failures
3.2 Permanent Failures
4.0 Diameter AVPs
4.1 MIP-Reg-Request AVP
4.2 MIP-Reg-Reply AVP
4.3 MIP-Mobile-Node-Address AVP
4.4 MIP-Home-Agent-Address AVP
4.5 MIP-Feature-Vector AVP
4.6 MIP-MN-AAA-Auth AVP
4.6.1 MIP-MN-AAA-SPI AVP
4.6.2 MIP-Auth-Input-Data-Length AVP
4.6.3 MIP-Authenticator-Length AVP
4.6.4 MIP-Authenticator-Offset AVP
4.7 MIP-FA-Challenge AVP
4.8 MIP-Foreign-Agent-Host AVP
4.9 MIP-Filter-Rule AVP
4.10 MIP-Candidate-Home-Agent-Host
4.11 MIP-Originating-Foreign-AAA AVP
5.0 Key Distribution Center
5.1 Authorization Lifetime vs. MIP Key Lifetime
5.2 Key Material vs. Session Key
5.3 Distributing the Mobile-Home Session Key
5.4 Distributing the Mobile-Foreign Session Key
5.5 Distributing the Foreign-Home Session Key
5.6 Key Distribution Example
6.0 Key Distribution Center (KDC) AVPs
6.1 MIP-FA-to-MN-Key AVP
6.2 MIP-FA-to-HA-Key AVP
6.3 MIP-HA-to-FA-Key AVP
6.4 MIP-HA-to-MN-Key AVP
6.5 MIP-MN-to-FA-Key AVP
et al. Calhoun expires September 2002 [Page 2]
Internet-Draft March 2002
6.6 MIP-MN-to-HA-Key AVP
6.7 MIP-Session-Key AVP
6.8 MIP-Algorithm-Type AVP
6.9 MIP-Replay-Mode AVP
6.10 MIP-FA-to-MN-SPI
6.11 MIP-FA-to-HA-SPI
6.12 MIP-Key-Material AVP
6.13 MIP-Key-Lifetime AVP
7.0 Accounting AVPs
7.1 Accounting-Input-Octets AVP
7.2 Accounting-Output-Octets AVP
7.3 Acct-Session-Time AVP
7.4 Accounting-Input-Packets AVP
7.5 Accounting-Output-Packets AVP
8.0 AVP Table
8.1 Mobile IP Command AVP Table
8.2 Accounting AVP Table
9.0 IANA Considerations
9.1 Command Codes
9.2 AVP Codes
9.3 Result-Code AVP Values
9.4 MIP-Feature-Vector AVP Values
9.5 MIP-Algorithm-Type AVP Values
9.6 MIP-Replay-Mode AVP Values
9.7 Application Identifier
10.0 Security Considerations
11.0 References
11.1 Normative
11.2 Informative
12.0 Acknowledgements
13.0 Authors' Addresses
14.0 Full Copyright Statement
15.0 Expiration Date
et al. Calhoun expires September 2002 [Page 3]
Internet-Draft March 2002
1.0 Introduction
Mobile IP, as defined in [MOBILEIP], defines a method that allows a
Mobile Node to change its point of attachment to the Internet with
minimal service disruption. Mobile IP does not provide any specific
support for mobility across disparate administrative domains, and
therefore does not specify how usage can be accounted for, which has
limited the applicability of Mobile IP in a IPv4 commercial
deployment. The Mobile IP specification as defined in [MOBILEIP]
recommends mobile nodes to have a static home address and a home
agent. However this may not be always possible in certain deployment
scenarios. Recent developments in areas that impact IP mobility in
the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile
nodes do not have a static home agent and home address. Recent
specification [MIPNAI] allows a mobile node to use its NAI instead of
its home address, which better accommodates current administrative
practice.
This document specifies Application 4 to the Diameter base protocol
[DIAMBASE] that allows a Diameter server to authenticate, authorize
and collect accounting information for Mobile IPv4 services rendered
to a mobile node. This application MUST NOT be used in conjunction
with the Mobile IPv6 protocol.
Combined with the Inter-Realm capability of the base protocol, this
application allows mobile nodes to receive service from foreign
service providers. The Diameter Accounting messages will be used by
the Foreign and Home agents to transfer usage information to the
Diameter servers.
The Mobile IP protocol [MOBILEIP] specifies a security model that
requires that mobile nodes and home agents share a pre-existing
security association, which leads to scaling and configuration
issues. This specification defines Diameter functions that allow the
AAA server to act as a Key Distribution Center (KDC), whereby dynamic
session keys are created and distributed to the mobility entities for
the purposes of securing Mobile IP Registration messages.
As with the Diameter base protocol, AAA servers implementing the
Mobile IP application can process users' identities supplied in a
Network Access Identifier (NAI) format [NAI], which is used for
Diameter message routing purposes. Mobile nodes include their NAI in
Registration messages, as defined in [MIPNAI]. The use of the NAI is
consistent with the roaming model defined by the ROAMOPS Working
Group [EVALROAM].
et al. Calhoun expires September 2002 [Page 4]
Internet-Draft March 2002
An AAA Home server (AAAH) and AAA foreign server (AAAF) which
supports the Mobile-IP authentication application MAY maintain
session-state or MAY be session-stateless. AAA redirect agents and
AAA relay agents MUST not maintain session-state. The AAAH, AAAF,
proxies and relays agents MUST maintain transaction state.
Given the nature of Mobile IP, a re-authentication can only be
initiated by a mobile node, which does not participate in the
Diameter message exchanges. Therefore the Diameter base protocol's
server initiated re-auth does not apply to this application
The Diameter Mobile-IP Application meets the requirements specified
in [MIPREQ, CDMA2000]. Later subsections in this introductory section
provide some examples and message flows of the Mobile IP and Diameter
messages that occur when a Mobile Node requests service in a foreign
network. In this document, the role of the "attendant" [MIPREQ] is
performed by either the home agents (for co-located mobile nodes) or
foreign agents for the Mobile-IP Application, and these terms will be
used interchangeably.
1.1 Requirements language
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [KEYWORDS].
et al. Calhoun expires September 2002 [Page 5]
Internet-Draft March 2002
1.2 Inter-Realm Mobile IP
When a Mobile Node 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 2.1. 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
+--------+ +--------+
|abc.com | AMR/AMA |xyz.com |
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +--------+ communication +--------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@xyz.com
+--------+
Figure 1: Inter-Realm Mobility
Upon receiving the AMR, the AAAF follows the procedures outlined in
[DIAMBASE] to determine whether the AMR should be processed locally,
or if it should be forwarded to another Diameter Server, known as the
AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node
(mn@xyz.com) requests service from a foreign provider (abc.com). The
request received by the AAAF is forwarded to xyz.com's AAAH server.
et al. Calhoun expires September 2002 [Page 6]
Internet-Draft March 2002
Figure 2 shows the message flows involved when the foreign agent
invokes the AAA infrastructure to request that a mobile node be
authenticated and authorized. Note that it is not required that the
foreign agent invoke AAA services every time a Registration Request
is received from the mobile, but rather only when the prior
authorization from the AAAH expires. The expiration time of the
authorization is communicated through the Authorization-Lifetime AVP
in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH.
Mobile Node Foreign Agent AAAF AAAH Home Agent
----------- ------------- ------------ ---------- ----------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
<----------HAA
Session-Id = bar
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
Figure 2: Mobile IP/Diameter Message Exchange
The foreign agent (as shown in Figure 2) MAY provide a challenge,
which gives it direct control over the replay protection in the
Mobile IP registration process, as described in [MIPCHAL]. The
mobile node includes the Challenge and MN-AAA authentication
extension to enable authorization by AAAH. If the authentication
data supplied in the MN-AAA extension is invalid, AAAH returns the
response (AMA) with the Result-Code AVP set to
DIAMETER_AUTHENTICATION_REJECTED.
et al. Calhoun expires September 2002 [Page 7]
Internet-Draft March 2002
In the event that the AMR generated by the FA is for a session that
has was previously authorized by the AAAH, it MUST include the
Destination-Host AVP, with the identity of the AAAH. The AAAH's
identity can be retrieved from the Origin-Host AVP in the last AMA
received for the session.
If the Mobile Node was successfully authenticated, the AAAH checks if
the Home Agent was located in the foreign realm, by checking the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If
the flag is enabled, then the Home Agent is located in the foreign
realm then AAAH sends an HAR message to AAAF which contains a MIP-
Reg-Request AVP.
If the Home Agent was not located in the foreign realm, the AAAH
checks for the MIP-Home-Agent-Address AVP. If one was specified, the
AAAH checks that the address is that of a known Home Agent, and one
that the Mobile Node is allowed to request, and the Home Agent's
identity is included in the Destination-Host AVP. If no Home Agent
was specified, and if the MIP-Feature-Vector has the Home-Agent-
Requested flag set, and if allowed by policy in the home realm, the
AAAH SHOULD allocate a home agent on behalf of the Mobile Node. This
can be done in a variety of ways, including using a load balancing
algorithm in order to keep the load on all home agents equal. The
actual algorithm used and the method of discovering the home agents
is outside the scope of this specification.
The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains
the Mobile IP Registration Request message data encapsulated in the
MIP-Reg-Request AVP, to the assigned or requested Home Agent. The
AAAH MAY allocate a home address for the mobile node, while the Home
Agent MUST support home address allocation. In the event the AAAH
handles address allocation, it includes it in a MIP-Mobile-Node-
Address AVP within the HAR. The absence of this AVP informs the Home
Agent to perform the allocation.
During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA (see Figure 2). If the
AAAH is session-stateful, it should send the same session identifier
for all HARs initiated on behalf of a given mobile node's session.
Otherwise, if the AAAH is session-stateless, it will manufacture a
unique session-id for every HAR. (Note--This will not cause a
problem for the HA, who must be able to recognize a handoff even if
the AAAH thinks the session is new; an AAAH may incorrectly view a
session as new when the handoff AMR goes to a different AAAH than the
previous AMR).
et al. Calhoun expires September 2002 [Page 8]
Internet-Draft March 2002
A mobile node's session is identified via its identity in the User-
Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address
AVPs. This is necessary in order to allow the session state machine,
defined in the base protocol [DIAMBASE], to be used unmodified with
this application. Therefore, an STR from a foreign agent would free
the session from the foreign agent, but not the one towards the home
agent (see figure 3).
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 3: Session Termination and Session Identifiers
Upon receipt of the HAR, the Home Agent first processes the Diameter
message. The Home Agent processes the MIP-Reg-Request AVP and creates
the Registration Reply, encapsulating it within the MIP-Reg-Reply
AVP. If a home address is needed, the Home Agent MUST assign one and
include the address in both the Registration Reply and within the
MIP-Mobile-Node-Address AVP. The HA MUST include an Accounting-Multi-
Session-Id AVP in the HAA returned to the AAAH.
Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
(AMA) message, includes the Accounting-Multi-Session-Id that was
present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-
Address AVPs in the AMA message, enabling appropriate firewall
controls for the penetration of tunneled traffic between the Home
Agent and the Mobile Node.
The AAAF is responsible for ensuring that the AMA message is properly
forwarded to the correct foreign agent.
1.3 Support for Mobile IP Handoffs
Given the nature of Mobile IP, a mobile node MAY receive service from
many foreign agents during a period of time. However, the home realm
should not view these handoffs as different sessions, since this
could affect billing systems. Furthermore, many foreign agents do not
communicate, which makes it quite difficult for AAA information to be
exchanged between these entities. Therefore, it MUST be assumed that
a foreign agent is not aware that a registration request from a
mobile node has been previously authorized.
et al. Calhoun expires September 2002 [Page 9]
Internet-Draft March 2002
The first registration request from a mobile node will therefore
cause an AMR to be sent to its AAAF. The AMR will include a new
session identifier, and MAY even be sent to a different AAAF in the
visited network. It is also possible that the AMR will be received by
a different AAAH.
Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, or since the AAAH
may be session-stateless, it is necessary for the resulting HAR
received by the HA to be identified as a continuation of an existing
session. If the HA receives an HAR for a mobile node, with a new
session identifier, and the HA can guarantee that this request is to
extend service for an existing service, then the HA MUST be able to
modify its internal session state information to reflect the
(possibly) new AAAH and new session identifier.
If the AAAH is new, the HA MUST also issue an STR message with the
old session identifier to the AAAH it was communicating with when
using the old session identifier.
It is necessary for accounting records to have some commonality
across handoffs in order for correlation to occur. Therefore, the
home agent MUST send the same Accounting-Multi-Session-Id AVP value
in all HAAs for the mobile's session. That is, the HA generates a
unique Accounting-Multi-Session-Id when receiving an HAR for a new
session, and returns this same value in every HAA for the session.
This Accounting-Multi-Session-Id AVP will be returned to the foreign
agent by the AAAH in the AMA. Both the foreign and home agents MUST
include the Accounting-Multi-Session-Id in the accounting messages.
ACR, Session-Id = foo ACR, Session-Id = bar
Accounting-Multi-Session-Id = a Accounting-Multi-Session-Id = a
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
ACA, Session-Id = foo ACA, Session-Id = bar
Figure 4: Accounting messages w/ Mobile IP Application
et al. Calhoun expires September 2002 [Page 10]
Internet-Draft March 2002
1.4 Allocation of Home Agent in Foreign Network
The Diameter Mobile IP application allows a Home Agent to be
allocated in a foreign network, as required in [MIPREQ, CDMA2000].
When a Foreign Agent detects that the mobile node has a home agent
address equal to 0.0.0.0 or 255.255.255.255 in the Registration
Request message, it MUST add a MIP-Feature-Vector AVP with the Home-
Agent- Requested flag set to one. If the home agent address is equal
to 255.255.255.255, then the foreign agent also MUST set the Home-
Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home
agent address is set to 0.0.0.0, the foreign agent MUST set the Home-
Address-Allocatable-Only-in-Home-Realm flag equal to zero.
When the AAAF receives an AMR message with the Home-Agent-Requested
flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm
flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available
flag in the MIP-Feature-Vector AVP to inform the AAAH that it is
willing and able to assign a Home Agent for the Mobile Node. When
doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP
and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-
Agent-Host AVP contains the identity of the home agent that would be
assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP
contains the identity of the AAAF.
In the event that the mobile node requests a home agent in the
foreign network, and the AAAF authorizes its use, the AAAF MUST set
the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
This could happen when the AAA request is sent to "extend" a mobile
node's current session.
When the AAAH receives an AMR message, it first checks the
authentication data supplied by the mobile node, according to the
MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether
to authorize the mobile node. If the AMR indicates that the AAAF has
offered to allocate a Home Agent for the mobile node, then the AAAH
must decide whether its local policy would allow the user to have a
Home Agent in the foreign network. If so, and after checking
authorization from the data in the AMR message, the AAAH sends the
HAR message to Home Agent found in the AMR's MIP-Candidate-Home-
Agent-Host AVP. The HAR message does not in this case contain the
MIP-Home-Agent- Address, but includes the Destination-Host AVP set to
the value in the MIP-Candidate-Home-Agent-Host AVP.
et al. Calhoun expires September 2002 [Page 11]
Internet-Draft March 2002
If the HA hasn't yet been allocated by the foreign domain, the HAR
sent by the AAAH back to the foreign realm will not necessarily be
received by the same AAAF which sent the AMR. Therefore the AAAH MUST
always copy the MIP-Originating-Foreign-AAA AVP from the AMR message
to the HAR message. In cases when another AAAF, which may not reside
in the same domain, receives the HAR, thus the new AAAF will use the
MIP-Originating-Foreign-AAA AVP for policy decisions, such as
determining if the FA-HA Key should be encrypted or not.
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5: Home Agent allocated in Visited Realm
Upon receipt of a HAA from the Home Agent in the visited realm, the
AAAF forwards the HAA to the AAAH in the home realm. The AMA is then
constructed, and issued to the AAAF, and finally to the FA. If the
Result-Code indicates success, the HAA and AMA MUST include the MIP-
Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.
et al. Calhoun expires September 2002 [Page 12]
Internet-Draft March 2002
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<----Challenge----
Reg-Req (Response)->
------------AMR------------->
-----AMR---->
<----HAR-----
<-----HAR------
------HAA------>
-----HAA---->
<----AMA-----
<-------------AMA------------
<---Reg-Reply----
Figure 6: Mobile IP/Diameter Message Exchange
If the Mobile Node moves to another Foreign Network, it MAY either
request to keep the same Home Agent within the old foreign network,
or request to get a new one in the new foreign network. If the AAAH
is willing to provide the requested service, the mobile node will
have to interact with two AAAFs.
Figure 7 shows the message flows for a Mobile Node requesting to keep
the Home Agent assigned in Foreign network 1 when it moves to foreign
network 2. Upon reception of the AMR in Foreign network 2, the AAAF
follows the procedures described earlier and forwards AMR to the
Mobile Node's home network, i.e. its AAAH. If the Mobile Node was
successfully authenticated, the AAAH checks the identity of the
foreign and home agent to determine whether the user is in a third
realm. If this is the case, the AAAH must check whether the mobile is
still permitted to use the previously assigned Home Agent.
et al. Calhoun expires September 2002 [Page 13]
Internet-Draft March 2002
+---------------+ +---------------+ +-------------+
|Foreign net 2 | |Foreign net 1 | |Home network |
| | | | | |
Mobile Node | FA AAAF | | HA AAAF | | AAAH |
----------- | ---- ---- | | ---- ------ | | ------ |
+---------------+ +---------------+ +-------------+
<----Challenge----
Reg-Req (Response)->
---AMR--->
----------------AMR--------------->
<-----HAR-----
<---HAR----
----HAA--->
------HAA---->
<---------------AMA----------------
<--AMA----
<----Reg-Reply-----
Figure 7: Request to access Home Agent from new Foreign Network
If the Mobile Node is allowed to keep the Home Agent the AAAH then
sends a HAR, which contains the Mobile IP Registration Request
message data encapsulated in the MIP-Reg-Request AVP and the MIP-
Home-Agent-Address AVP with Home Agent address, as well as any
optional KDC session keys, to the AAAF in foreign network 1. Upon
reception the AAAF in foreign network 1 will forward the HAR to the
Home Agent if its local policy allows such service. If the AAAF does
not permit such service, it MUST return a
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
When the AAAF receives a HAA, the AAAF will forward the HAA back to
the AAAH. If successful, the HAA MUST include the MIP-Home-Agent-
Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send
back an AMA to the AAAF in foreign network 2.
If the old Foreign Network does not permit the use of its Home Agent
when the Mobile Node moves to a new foreign network, the AAAH or AAAF
MUST return an AMA with the Result-Code AVP set to
DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile
Node with an appropriate error. The Mobile Node MAY attempt to
request that a new Home Agent and Address be allocated. When the AAAH
transmits such an error, it MUST issue a Diameter Abort-Session-
Request message to the Home Agent to enable it to release any
resources.
et al. Calhoun expires September 2002 [Page 14]
Internet-Draft March 2002
1.5 Co-located Mobile Node
In the event that a Mobile Node registers with the Home Agent as a
co-located Mobile Node, there is no Foreign Agent involved.
Therefore, when the Home Agent receives the Registration Request, an
AMR message is sent to the local AAAH server, with the Co-Located-
Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent
also includes the Accounting-Multi-Session-Id AVP in the AMR sent to
the AAAH, as the AAAH may find this a useful piece of session-state
or log entry information.
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 8: Co-located Mobile Node
If the MN-HA-Key-Requested bit was set in the AMR message from the
Home Agent, the Home Agent and Mobile Node's session keys would be
present in the AMA message.
1.6 Diameter Session Termination
A Foreign and Home Agent following this specification MAY expect
their respective Diameter servers to maintain session state
information for each mobile node in their networks. In order for the
Diameter Server to release any resources allocated to a specific
mobile node, the mobility agents MUST send a Session-Termination-
Request (STR) to the Diameter server that authorized the service. The
Session-Termination-Request (STR) MUST be issued by the mobility
agents if the Authorization Lifetime has expired and no subsequent
MIP registration request have been received.
et al. Calhoun expires September 2002 [Page 15]
Internet-Draft March 2002
The Home Diameter server SHOULD only deallocate all resources after
the STR is received from the Home Agent. This ensures that a Mobile
Node that moves from one Foreign Agent to another (hand-off) does not
cause the Home Diameter Server to free all resources for the Mobile
Node.
In the event that the AAAF wishes to terminate a session, its Abort-
Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA.
Similarly, the AAAH SHOULD send its message to the Home Agent.
1.7 Advertising application support
Diameter nodes conforming to this specification MAY advertise support
by including the value of four (4) in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer command [DIAMBASE].
1.8 Fast Handoff support
This application requires that foreign agents issue an AMR upon
receipt of the first registration message from a mobile node,
regardless of the fact that the mobile node MAY have been previously
authorized to another foreign agent.
The Mobile IP Working Group is currently investigating fast handoff
proposals, and the Seamoby WG is looking at creating a protocol that
would allow AAA state information to be exchange between foreign
agents during a handoff. These proposals MAY allow future
enhancements to the Diameter protocol, in order to reduce the amount
of Diameter exchanges required during a handoff.
2.0 Command-Code Values
This section defines Command-Code [DIAMBASE] values that MUST be
supported by all Diameter implementations conforming to this
specification. The following Command Codes are defined in this
specification:
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Answer AMA 260 2.2
AA-Mobile-Node-Request AMR 260 2.1
Home-Agent-MIP-Answer HAA 262 2.4
Home-Agent-MIP-Request HAR 262 2.3
et al. Calhoun expires September 2002 [Page 16]
Internet-Draft March 2002
2.1 AA-Mobile-Node-Request
The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field
set to 260 and the 'R' bit set in the Command Flags field, is sent by
an attendant, acting as a Diameter client, to a server in order to
request the authentication and authorization of a Mobile Node. The
Foreign Agent (or Home Agent in the case of a co-located Mobile Node)
uses information found in the Registration Request to construct the
following AVPs that are to be included as part of the AMR:
home address (MIP-Mobile-Node-Address AVP),
home agent address (MIP-Home-Agent-Address AVP),
mobile node NAI (User-Name AVP [DIAMBASE]).
MN-HA Key Request (MIP-Feature-Vector AVP)
MN-FA Key Request (MIP-Feature-Vector AVP)
MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
If the mobile node's home address is zero, the foreign or home agent
MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the
home agent address is zero or all ones, the MIP-Home-Agent-Address
AVP MUST NOT be present in the AMR.
If a Foreign Agent is used in a visited network, the AAAF MAY set the
Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in
the AMR message to indicate that it is willing to assign a Home Agent
in the visited realm.
If the mobile node's home address is all ones, the foreign or home
agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.
et al. Calhoun expires September 2002 [Page 17]
Internet-Draft March 2002
Message Format
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
2.2 AA-Mobile-Node-Answer
The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field
set to 260 and the 'R' bit cleared in the Command Flags field, is
sent by the AAAH in response to the AA-Mobile-Node-Request message.
The User-Name MAY be included in the AMA if present in the AMR. The
Result-Code AVP MAY contain one of the values defined in section 3.0,
in addition to the values defined in [DIAMBASE].
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
include the MIP-Home-Agent-Address AVP, MUST include the MIP-Home-
Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP if and
only if the Co-Located-Mobile-Node bit was not set in the MIP-
Feature-Vector AVP. The MIP-Home-Agent-Address AVP contains the Home
Agent assigned to the Mobile Node, while the MIP-Mobile-Node-Address
AVP contains the home address that was assigned. The AMA message MUST
contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested
in the AMR, and they were present in the HAR. The MIP-MN-to-HA-Key
and MIP-HA-to-MN-Key AVPs MUST be present if the session keys were
requested in the AMR, and the Co-Located-Mobile-Node bit was set in
the MIP-Feature-Vector AVP.
et al. Calhoun expires September 2002 [Page 18]
Internet-Draft March 2002
An AMA message with the Result-Code AVP set to
DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP
if a dynamically assigned home agent was requested by the mobile
node. Upon receipt of this result code, the foreign agent MUST issue
the Registration Request to the Home Agent in the manner described in
[MOBILEIP].
An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH
MAY include mobile node session key AVPs (see Section 6.1) such as
the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP
is present in the AMA message, the foreign agent MUST include the
corresponding Mobile IP key distribution extension in the
Registration Reply it sends to the mobile node. This is to support
multi-roundtrip authentication mechanisms.
et al. Calhoun expires September 2002 [Page 19]
Internet-Draft March 2002
Message Format
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Accounting-Multi-Session-Id ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-Key ]
[ MIP-MN-to-HA-Key ]
[ MIP-FA-to-MN-Key ]
[ MIP-FA-to-HA-Key ]
[ MIP-HA-to-MN-Key ]
[ MIP-HA-to-FA-Key ]
[ MIP-Key-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Session-Timeout ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
2.3 Home-Agent-MIP-Request
The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field
set to 262 and the 'R' bit set in the Command Flags field, is sent by
the AAA to the Home Agent. If the Home Agent is to be assigned in a
foreign network, the HAR is issued by the AAAH and forwarded by the
AAAF. If the HAR message does not include a MIP-Mobile-Node-Address
AVP, and the Registration Request has 0.0.0.0 for the home address,
and the HAR is successfully processed, the Home Agent MUST allocate
one such address to the mobile node. If the home agent's local AAA
server allocates the mobile node's home address, it MUST include the
assigned address in an MIP-Mobile-Node-Address AVP.
When session keys are requested for use by the mobile node (see
et al. Calhoun expires September 2002 [Page 20]
Internet-Draft March 2002
section 5.0), the AAAH MUST create them and include them in the HAR
message. When a Foreign-Home session key is requested, it will be
created and distributed by the AAA server in the same realm as the
home agent.
Message Format
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Grace-Period }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Foreign-Agent-Host }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-Key ]
[ MIP-MN-to-FA-Key ]
[ MIP-HA-to-MN-Key ]
[ MIP-HA-to-FA-Key ]
[ MIP-Key-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Session-Timeout ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
2.4 Home-Agent-MIP-Answer
The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field
set to 262 and the 'R' bit cleared in the Command Flags field, is
sent by the Home Agent to its local AAA server in response to a Home-
Agent-MIP-Request. The User-Name MAY be included in the HAA if
present in the HAR. If the home agent allocated a home address for
the Mobile Node, the address MUST be included in the MIP-Mobile-Node-
Address AVP. The Result-Code AVP MAY contain one of the values
defined in section 3.0 instead of the values defined in [DIAMBASE].
et al. Calhoun expires September 2002 [Page 21]
Internet-Draft March 2002
Message Format
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Foreign-Agent-Host }
{ Accounting-Multi-Session-Id }
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
3.0 Result-Code AVP Values
This section defines new Result-Code [DIAMBASE] values that MUST be
supported by all Diameter implementations that conform to this
specification.
3.1 Transient Failures
Errors that fall within the transient failures category are used to
inform a peer that the request could not be satisfied at the time it
was received, but MAY be able to satisfy the request in the future.
DIAMETER_ERROR_MIP_REPLY_FAILURE 4005
This error code is used by the Home Agent when processing of
the Registration Request has failed.
DIAMETER_ERROR_HA_NOT_AVAILABLE 4006
This error code is used to inform the Foreign Agent that the
requested Home Agent cannot be assigned to the Mobile Node at
this time. The Foreign Agent MUST return a Mobile IP
Registration Reply to the Mobile Node with an appropriate error
code.
et al. Calhoun expires September 2002 [Page 22]
Internet-Draft March 2002
DIAMETER_ERROR_BAD_KEY 4007
This error code is used by the Home Agent to indicate to the
local Diameter server that the key generated is invalid.
3.2 Permanent Failures
Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted
again.
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024
This error is used by the AAAF to inform the AAAH that
allocation of a Home Agent in the Foreign Domain is not
permitted at this time.
4.0 Mandatory AVPs
The following table describes the Diameter AVPs defined in the Mobile
IP application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted.
Due to space constraints, the short form IPFiltrRule is used to
represent IPFilterRule and DiamIdent is used to represent
DiameterIdentity.
et al. Calhoun expires September 2002 [Page 23]
Internet-Draft March 2002
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Filter-Rule 342 4.9 IPFiltrRule| M | P | | V | Y |
MIP-Auth-Input- 338 4.6.2 Unsigned32 | M | P | | V | Y |
Data-Length | | | | | |
MIP- 339 4.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length | | | | | |
MIP- 340 4.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset | | | | | |
MIP-Candidate- 336 4.10 DiamIdent | M | P | | V | N |
Home-Agent-Host | | | | | |
MIP-FA-Challenge 344 4.7 OctetString| M | P | | V | Y |
MIP-Feature- 337 4.5 Unsigned32 | M | P | | V | Y |
Vector | | | | | |
MIP-Foreign- 330 4.8 DiamIdent | M | P | | V | Y |
Agent-Host | | | | | |
MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y |
Address | | | | | |
MIP-MN-AAA-Auth 322 4.6 Grouped | M | P | | V | Y |
MIP-MN-AAA-SPI 341 4.6.1 Unsigned32 | M | P | | V | Y |
MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y |
Address | | | | | |
MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y |
MIP-Originating- 347 4.11 Grouped | M | P | | V | Y |
Foreign-AAA | | | | | |
4.1 MIP-Reg-Request AVP
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and
contains the Mobile IP Registration Request [MOBILEIP] sent by the
Mobile Node to the Foreign Agent.
4.2 MIP-Reg-Reply AVP
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and
contains the Mobile IP Registration Reply [MOBILEIP] sent by the Home
Agent to the Foreign Agent.
4.3 MIP-Mobile-Node-Address AVP
The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and
contains the Mobile Node's Home Address.
et al. Calhoun expires September 2002 [Page 24]
Internet-Draft March 2002
4.4 MIP-Home-Agent-Address AVP
The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and
contains the Mobile Node's Home Agent Address.
4.5 MIP-Feature-Vector AVP
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
is added with flag values set by the Foreign Agent or by the AAAF
owned by the same administrative domain as the Foreign Agent. The
Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
Flag values currently defined include:
1 Mobile-Node-Home-Address-Requested
2 Home-Address-Allocatable-Only-in-Home-Realm
4 Home-Agent-Requested
8 Foreign-Home-Agent-Available
16 MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128 Home-Agent-In-Foreign-Network
256 Co-Located-Mobile-Node
The flags are set according to the following rules.
If the mobile node includes a valid home address (i.e., not equal to
0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign
Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP-
Feature-Vector AVP.
If the mobile node sets the home address field equal to 0.0.0.0 in
its Registration Request, the Foreign Agent sets the Mobile-Node-
Home-Address-Requested flag to one.
If the mobile node sets the home agent field equal to 255.255.255.255
in its Registration Request, the Foreign Agent sets both the Home-
Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-
Realm flag to one in the MIP-Feature-Vector AVP.
If the mobile node sets the home agent field equal to 0.0.0.0 in its
Registration Request, the Foreign Agent sets the Home-Agent-Requested
flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home-
Realm flag in the MIP-Feature-Vector AVP.
et al. Calhoun expires September 2002 [Page 25]
Internet-Draft March 2002
Whenever the Foreign Agent sets either the Mobile-Node-Home-Address-
Requested flag or the Home-Agent-Request flag to one, it MUST set the
MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set
to one if the mobile node includes a Generalized MN-HA Key Request
[MIPKEYS] extension, with the subtype set to AAA.
If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS]
extension with the AAA subtype in its Registration Request, the
Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP-
Feature-Vector AVP.
If the mobile node requests a home agent in the foreign network
either by setting the home address field to all ones, or by
specifying a home agent in the foreign network, and the AAAF
authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
Network bit to one.
If the Home Agent receives a Registration Request from the Mobile
Node indicating that the MN is acting as a Co-Located Mobile Node,
the Home Agent sets the Co-Located-Mobile-Node bit to one.
If the Foreign Agent's local policy allows it to receive AAA Session
Keys, and it does not have any existing keys with the Home Agent, it
MAY set the FA-HA-Key-Request flag.
The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and
Home-Agent-In-Foreign-Network flag to one.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized Foreign Agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP
flags. The AAAF then MAY set additional flags.Only the AAAF may set
the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
flags to one. This is done according to local administrative policy.
When the AAAF has finished setting additional flags according to its
local policy, then the AAAF transmits the AMR with the possibly
modified MIP-Feature-Vector AVP to the AAAH.
et al. Calhoun expires September 2002 [Page 26]
Internet-Draft March 2002
4.6 MIP-MN-AAA-Auth AVP
The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains
some ancillary data to simplify processing of the authentication data
in the Mobile IP Registration Request [MOBILEIP] by the target AAA
server. Its value has the following ABNF grammar:
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
4.6.1 MIP-MN-AAA-SPI AVP
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
indicates the algorithm by which the targeted AAA server (AAAH)
should attempt to validate the Authenticator computed by the mobile
node over the Registration Request data.
4.6.2 MIP-Auth-Input-Data-Length AVP
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type
Unsigned32 and contains the length, in bytes, of the Registration
Request data (data portion of MIP-Reg-Request AVP) that should be
used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used
to determine whether the Authenticator Data supplied by the Mobile
Node is valid.
4.6.3 MIP-Authenticator-Length AVP
The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32
and contains the length of the authenticator to be validated by the
targeted AAA server (i.e., AAAH).
4.6.4 MIP-Authenticator-Offset AVP
The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32
and contains the offset into the Registration Request Data, of the
authenticator to be validated by the targeted AAA server (i.e.,
AAAH).
et al. Calhoun expires September 2002 [Page 27]
Internet-Draft March 2002
4.7 MIP-FA-Challenge
The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and
contains the challenge advertised by the Foreign Agent to the Mobile
Node. This AVP MUST be present in the AMR if the Mobile Node used the
RADIUS-style MN-AAA computation algorithm.
4.8 MIP-Foreign-Agent-Host AVP
The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type
DiameterIdentity and contains the identity of the foreign agent. This
AVP is copied from the value of the Origin-Host AVP in the AMR.
4.9 MIP-Filter-Rule AVP
The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and
provides filter rules that need to be configured on the Foreign or
Home Agent for the user. One or more such AVPs MAY be present in an
authorization response.
4.10 MIP-Candidate-Home-Agent-Host
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type
DiameterIdentity and contains the identity of a home agent in the
foreign network that the AAAF proposes be dynamically assigned to the
mobile node.
4.11 MIP-Originating-Foreign-AAA AVP
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type
Grouped, and contains the identity of the AAAF, which issues the AMR
to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used
in cases when the home agent is or may be allocated in a foreign
domain. If present in the AMR, the AAAH MUST copy the MIP-
Originating-Foreign-AAA AVP into the HAR.
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
et al. Calhoun expires September 2002 [Page 28]
Internet-Draft March 2002
5.0 Key Distribution Center
The mobile node and mobility agents use session keys to compute
authentication extensions applied to registration messages, as
defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home.
If session keys are requested the AAA server(s) MUST return the key
material after the Mobile Node is successfully authenticated and
authorized.
If the AAAH does not communicate directly with the foreign agent, and
it does not wish for intermediate proxies to have access to the
session keys, they SHOULD be protected using the CMS security
application [CMS].
The SPI values are used as key identifiers, meaning that each session
key has its own SPI value; nodes that share a key also share an SPI.
The Mobile Node proposes SPIs for use in computing the Mobile-Foreign
and Mobile-Home authentication extensions, via the Mobile IP AAA Key
Request extensions [MIPKEYS], while the Home Agent allocates the
Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.
Once the session keys have been distributed, subsequent Mobile IP
registrations need not invoke the AAA infrastructure until the keys
expire. These registrations MUST include the Mobile-Home
authentication extension. In addition, subsequent registrations MUST
also include Mobile-Foreign authentication extension if the Mobile-
Foreign key was generated and distributed by AAA; similarly for
subsequent use of the Foreign-Home authentication extensions.
5.1 Authorization Lifetime vs. MIP Key Lifetime
The Diameter Mobile IP application makes use of two timers - the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP.
The Authorization-Lifetime contains the number of seconds before the
Mobile Node must issue a subsequent MIP registration request. The
content of the Authorization-Lifetime AVP corresponds to the Lifetime
field in the MIP header [MOBILEIP].
The MIP-Key-Lifetime AVP contains the number of seconds before
session keys destined for the Mobility Agents and the Mobile Node
expire. A value of zero indicates infinity (no timeout). If not zero,
the value of the MIP-Key-Lifetime AVP MUST be at least equal to the
value in the Authorization Lifetime AVP.
et al. Calhoun expires September 2002 [Page 29]
Internet-Draft March 2002
5.2 Key Material vs. Session Key
Each session key that is generated by the AAAH will generally be
distributed to two parties; for instance, a Mobile-Foreign is sent to
both the mobile node and the foreign agent.
The key sent to the mobile node is always in the form of key
material, which the AAAH does by generating a random [RANDOM] value
of at least 64 bits. The random value is used by the mobile node to
create the actual session key. The following is an example of a
session creation procedure, using MD5 as the hashing algorithm.
Additional algorithms are supported, and listed in [MIPKEYS].
MD5(AAA-Key | key material | node-address | AAA-Key)
Where:
- AAA-Key is the long term secret shared between the mobile
node and the AAAH.
- Key material is a random [RANDOM] value of at least 64 bits.
- node-address is the mobile node's identity. This is the
contents of the MIP-Mobile-Node-Address AVP, unless the value
of the AVP is all zero or ones, in which case of value of the
User-Name AVP is used instead.
The AAAH then generates the session key, which is destined for the
mobility agent, in this case the foreign agent, by following the
above procedures. It is important that the hashing algorithm used by
the mobile node to construct the session key is the same as the one
used by the AAAH in the session key generation procedure. The AAAH
therefore indicates the algorithm used along with the key material.
The session keys destined for mobility agents may be encoded using
the security association available between the AAA server and the
agents (e.g. IPSec, TLS, CMS).
The Foreign-Home session key is shared between two mobility agents:
the FA and HA. Since this key is not destined for the mobile node,
there is no need to follow the session key generation procedures
detailed above. Instead, the AAAH generates a random [RANDOM] value
of at least 64 bits for use as the Foreign-Home session key.
See sections 6.0 for details about the format of the AVPs used to
transport the session keys.
et al. Calhoun expires September 2002 [Page 30]
Internet-Draft March 2002
5.3 Distributing the Mobile-Home Session Key
If the mobile node does not have a Mobile-Home session key, then the
AAAH is likely to be the only entity trusted that is available to the
mobile node. Thus, the AAAH has to generate the Mobile-Home session
key, and encode it for eventual consumption by the mobile node and
home agent.
If the home agent is in the home realm, then AAAH can directly encode
the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include
that AVP in the HAR message for delivery to the home agent.
If, on the other hand, the home agent is to be allocated in the
visited realm, the AAAH transmits the HAR to the foreign home agent,
where, prior to delivery to the home agent, it is perused by the AAAF
hosting the home agent.
The AAAH also has to arrange for the key to be delivered to the
mobile node. Unfortunately, the AAA server only knows about Diameter
messages and AVPs, and the mobile node only knows about Mobile IP
messages and extensions [MOBILEIP]. For this purpose, AAAH encodes
the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP,
using its security association with the mobile node, which is added
to the HAR message, and delivered either to a local home agent, or to
the AAAF in the case where the home agent is in the visited network.
The AAAH has to rely on the home agent (that also understands
Diameter) to transfer the keying information into a Mobile IP
Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration
Reply message, using the SPI proposed by the Mobile Node in the MN-HA
Key Request From AAA Subtype extension. The home agent can format the
Reply message and extensions correctly for eventual delivery to the
mobile node. The resulting Registration Reply is added to the HAA's
MIP-Reg-Reply AVP.
After the HAA message is parsed by the AAAH, and transformed into an
AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually
be received by the the foreign agent. The foreign agent can then use
that AVP to recreate a Registration Reply message, containing the
Generalized MN-HA Key Reply extension, for delivery to the mobile
node.
In summary, the AAAH generates the Mobile-Home key material, which is
added to the MIP-MN-to-HA-Key AVP. The key material is then used to
compute the home agent's session key as specified in [MIPKEYS], which
is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered
to a home agent by including them in a HAR message sent from either
AAAH or AAAF. The home agent decodes the key for its own use. The
home agent also copies the encoded key material from the MIP-MN-to-
et al. Calhoun expires September 2002 [Page 31]
Internet-Draft March 2002
HA-Key AVP into a Generalized MN-HA Key Reply extension appended to
the Mobile IP Registration Reply message. This Registration Reply
message MUST also include the Mobile-Home authentication extension,
created using the newly allocated Mobile-Home session key. The home
agent then encodes the Registration Reply message and extensions into
a MIP-Reg-Reply AVP included as part of the HAA message to be sent
back to the AAA server.
5.4 Distributing the Mobile-Foreign Session Key
The Mobile-Foreign session key material is also generated by AAAH
(upon request) and is added to the MIP-MN-to-FA-Key AVP, which is
added to the HAR, and copied by the home agent into a Generalized MN-
FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply
message, using the SPI proposed by the Mobile Node in the MN-FA Key
Request From AAA Subtype extension. Further, the home agent includes
the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the
session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains
the session key used by the foreign agent in the computation of the
Mobile-Foreign authentication extension.
Upon receipt of the HAA, the Diameter server responsible for key
allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the
MIP-FA-to-HA-SPI. If the key is generated at the AAAF (home agent in
foreign domain), it adds the MIP-FA-to-HA Key AVP to the HAA and
sends it to the AAAH. Depending upon where the HA was located the
AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the
AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key
to the AMA. If the MIP-FA-to-MN-Key AVP was present in the AMA, the
foreign agent MUST include the Mobile-Foreign authentication
extension in the Registration Reply, using the newly distributed key.
5.5 Distributing the Foreign-Home Session Key
5.5.1 Home Agent in the home network
If the home agent is in the home realm, then the AAAH has to generate
the Foreign-Home session key. Otherwise, it is generated by the AAAF.
In the cases when the AAAH generates the Foreign-Home session key,
the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and
includes the AVP as part of the HAR message sent to the home agent.
The corresponding session key and algorithm that is to be sent to the
foreign agent is cached in the AAAH until the HAA is received.
et al. Calhoun expires September 2002 [Page 32]
Internet-Draft March 2002
Upon receipt of the HAR, the home agent recovers the Foreign-Home
session key, allocates an SPI to be used with the key. The allocated
SPI is included in the HAA's MIP-FA-to-HA SPI AVP.
Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP,
using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the
AMA.
5.5.2 Home Agent in foreign network
In the cases when the AAAF generates the Foreign-Home session key
(home agent in foreign domain), the AAAF will, upon receipt of the
HAR message, generate the Foreign-Home session key and include the
session key in the MIP-HA-to-FA-Key AVP as part of the HAR message
forwarded to the home agent. The corresponding session key and
algorithm that is to be sent to the foreign agent is cached in the
AAAF until the HAA is received.
Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP,
using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the
Foreign-Home session key destined for the foreign agent needs to be
encrypted.
If the session key needs to be encrypted, the AAAF will check if a
security association can be established using DSA messages defined in
the CMS application [CMS] with the originating host found in the MIP-
Originating-Foreign-AAA AVP. If the DSA establishment is successful,
the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-
Data AVP with the AAAF as originator and the recipient copied from
the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is
included by the AAAF in the HAA destined for the AAAH. Otherwise, if
the DSA establishment fails, the AAAF MUST return a Result-Code AVP
with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
If the session key does not need to be encrypted, the AAAF will add
MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward
the HAA to the AAAH.
In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the
HAA returned to the AAAH.
Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA
Key AVP if present or the CMS-Ecrypted-data AVP if present and not
destined for the AAAH into the AMA.
If a Foreign-Home session key was present in the AMA, the foreign
agent MUST include the Mobile-Foreign authentication extension in the
Registration Reply, using the newly distributed key.
et al. Calhoun expires September 2002 [Page 33]
Internet-Draft March 2002
5.6 Key Distribution Example
Figure 9 provides an example of subsequent Mobile IP message
exchange, assuming that AAAH distributed session keys for all three
MN-FA, FA-HA and HA-MN authentication extensions.
Mobile Node Foreign Agent Home Agent
----------- ------------- ----------
Reg-Req(MN-HA-Auth, MN-FA-Auth)-------->
Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->
<--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)
<--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)
Figure 9: Mobile IP Message Exchange
6.0 Key Distribution Center (KDC) AVPs
The Mobile-IP protocol defines a set of security associations shared
between the Mobile Node, Foreign Agent and Home Agents. These three
security associations (Mobile-Home, Mobile-Foreign, and Foreign-
Home), can be dynamically created by the AAAH. This requires that the
AAAH create Mobile-IP Session Keys, and that these keys be
distributed to the three mobile entities, via the Diameter Protocol.
AAA servers supporting the Diameter Mobile IP Application MUST
implement the KDC AVPs defined in this document. In other words, AAA
servers MUST be able to create three session keys: the Mobile-Home,
Mobile-Foreign, and Foreign-Home keys.
The names of the KDC AVPs indicate the two entities sharing the
security association defined by the encrypted key material; the
intended receiver of the AVP is the first named entity. So, for
instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key
encrypted in a way that allows it to be recovered by the mobile node.
If strong authentication and confidentiality of the session keys is
required, it is recommended that the CMS security application [CMS]
be used.
The following table describes the Diameter AVPs defined in the Mobile
IP application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted.
et al. Calhoun expires September 2002 [Page 34]
Internet-Draft March 2002
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Algorithm- 345 6.8 Enumerated | M | P | | V | Y |
Type | | | | | |
MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y |
MIP-FA-to-HA-SPI 318 6.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 6.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y |
MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y |
MIP-Key-Lifetime 367 6.13 Unsigned32 | M | P | | V | Y |
MIP-Key-Material 335 6.12 OctetString| M | P | | V | Y |
MIP-MN-to-FA-Key 325 6.5 Grouped | M | P | | V | Y |
MIP-MN-to-HA-Key 331 6.6 Grouped | M | P | | V | Y |
MIP-Replay-Mode 346 6.9 Enumerated | M | P | | V | Y |
MIP-Session-Key 343 6.7 OctetString| M | P | | V | Y |
6.1 MIP-FA-to-MN-Key AVP
The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and
contains the Foreign Agent's session key, which it shares with the
Mobile Node. Its Data field has the following ABNF grammar:
MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
6.2 MIP-FA-to-HA-Key AVP
The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and
contains the Foreign Agent's session key, which it shares with the
Home Agent. Its Data field has the following ABNF grammar:
MIP-FA-to-HA-Key ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
et al. Calhoun expires September 2002 [Page 35]
Internet-Draft March 2002
6.3 MIP-HA-to-FA-Key AVP
The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and
contains the Home Agent's session key, which it shares with the
Foreign Agent. Its Data field has the following ABNF grammar:
MIP-HA-to-FA-Key ::= < AVP Header: 329 >
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
6.4 MIP-HA-to-MN-Key AVP
The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and
contains the Home Agent's session key, which it shares with the
Mobile Node. Its Data field has the following ABNF grammar:
MIP-HA-to-MN-Key ::= < AVP Header: 332 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
6.5 MIP-MN-to-FA-Key AVP
The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and
contains the Mobile Node's key material, which it uses to derive the
session key it shares with the Foreign Agent. The Home Agent uses
this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key
from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA
SPI field is allocated by the Home Agent, but it SHOULD take into
consideration the SPI requested by the Mobile Node in the "MN-FA Key
Request From AAA Subtype" extension.
MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type }
{ MIP-Key-Material }
{ MIP-MN-AAA-SPI }
* [ AVP ]
et al. Calhoun expires September 2002 [Page 36]
Internet-Draft March 2002
6.6 MIP-MN-to-HA-Key AVP
The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and
contains the Mobile Node's key material, which it uses to derive the
session key it shares with the Home Agent. The Home Agent uses this
AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from
AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI
field is allocated by the Home Agent, but it SHOULD take into
consideration the SPI requested by the Mobile Node in the "MN-HA Key
Request From AAA Subtype" extension.
MIP-MN-to-HA-Key ::= < AVP Header: 331 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Key-Material }
{ MIP-MN-AAA-SPI }
* [ AVP ].fi
6.7 MIP-Session-Key AVP
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString
and contains the Session Key to be used between two Mobile IP
entities.
6.8 MIP-Algorithm-Type AVP
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and
contains the Algorithm identifier used to generate the associated
Mobile IP authentication extension. The following values are currently
defined:
1 Prefix+Suffix MD5 [MOBILEIP]
2 HMAC-MD5 [HMAC]
3 HMAC-SHA-1 [HMAC]
et al. Calhoun expires September 2002 [Page 37]
Internet-Draft March 2002
6.9 MIP-Replay-Mode AVP
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the Home Agent should use when
authenticating the Mobile Node.
The following values are supported (see [MOBILEIP] for more
information):
1 None
2 Timestamps
3 Nonces
6.10 MIP-FA-to-MN-SPI AVP
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and
contains the Security Parameter Index the Foreign Agent is to use to
refer to the session key it shares with the Mobile Node. The SPI
created MUST NOT be a value between zero (0) and 255, which is the
reserved namespace defined in [MOBILEIP]. This AVP MAY be added in
the HAA message by the Home Agent for the AAAH's use in MIP-FA-to-MN-
SPI AVP of the MIP-FA-to-MN-Key AVP.
6.11 MIP-FA-to-HA-SPI AVP
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and
contains the Security Parameter Index the Foreign Agent is to use to
refer to the session key it shares with the Home Agent. The SPI
created MUST NOT be a value between zero (0) and 255, which is the
reserved namespace defined in [MOBILEIP]. If FA-HA keys are being
generated, this AVP MUST be added in the HAA message by the Home
Agent for the AAAH's (or AAAF's) use in providing the value of the
MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP.
6.12 MIP-Key-Material AVP
The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and
contains the key material sent to the mobile node. The mobile node
follows the procedures in [MIPKEYS] to generate the session key used
to authenticate Mobile IP registration messages.
et al. Calhoun expires September 2002 [Page 38]
Internet-Draft March 2002
6.13 MIP-Key-Lifetime AVP
The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and
represents the period of time (in seconds) for which the session key
is valid. The session key MUST NOT be used if the lifetime has
expired; if the key lifetime expires while the session to which it
applies is still active, either the session key MUST be changed or
the or the session MUST be terminated.
7.0 Accounting AVPs
This section will define the Accounting AVPs that are specific to
Mobile IP, and MUST be included in all Accounting-Request messages.
These AVPs MAY be present in the corresponding Accounting-Answer
messages as well.
7.1 Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64,
and contains the number of octets in IP packets received from the
user.
7.2 Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type
Unsigned64, and contains the number of octets in IP packets sent to
the user.
7.3 Acct-Session-Time AVP
The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates
the length of the current session in seconds.
7.4 Accounting-Input-Packets AVP
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64,
and contains the number of IP packets received from the user.
7.5 Accounting-Output-Packets AVP
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64,
and contains the number of IP packets sent to the user.
et al. Calhoun expires September 2002 [Page 39]
Internet-Draft March 2002
8.0 AVP Occurrence Tables
The following tables presents the AVPs defined in this document, and
specifies in which Diameter messages they MAY, or MAY NOT be present.
Note that AVPs that can only be present within a Grouped AVP are not
represented in this table.
The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.
8.1 Mobile IP Command AVP Table
The table in this section is limited to the Command Codes defined in
this specification.
et al. Calhoun expires September 2002 [Page 40]
Internet-Draft March 2002
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Grace-Period | 0-1 | 0-1 | 1 | 0 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 |
MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA-to-MN-Key | 0 | 0-1 | 0 | 0 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Foreign-Agent-Host | 0 | 0 | 1 | 1 |
MIP-HA-to-FA-Key | 0 | 0-1 | 0-1 | 0 |
MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-MN-to-FA-Key | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
Session-Timeout | 0 | 1 | 1 | 0 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
et al. Calhoun expires September 2002 [Page 41]
Internet-Draft March 2002
8.2 Accounting AVP Table
The table in this section is used to represent which AVPs defined in
this document are to be present in the Accounting messages, defined
in [DIAMBASE].
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Accounting-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
-------------------------------------|------+------+
9.0 IANA Considerations
This section contains the namespaces that have either been created in
this specification, or the values assigned to existing namespaces
managed by IANA.
9.1 Command Codes
This specification assigns the values 260 and 262 from the Command
Code namespace defined in [DIAMBASE]. See section 2.0 for the
assignment of the namespace in this specification.
9.2 AVP Codes
This specification assigns the values 318-347 and 363-367 from the
AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0
for the assignment of the namespace in this specification.
et al. Calhoun expires September 2002 [Page 42]
Internet-Draft March 2002
9.3 Result-Code AVP Values
This specification assigns the values 4005-4007, and 5024 from the
Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE].
See section 3.0 for the assignment of the namespace in this
specification.
9.4 MIP-Feature-Vector AVP Values
There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that
are available for assignment. This document assigns bits 1-9, as
listed in section 4.5. The remaining bits should only be assigned via
Standards Action [IANA].
9.5 MIP-Algorithm-Type AVP Values
As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345)
defines the values 1-3. All remaining values are available for
assignment via Designated Expert [IANA].
9.6 MIP-Replay-Mode AVP Values
As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346)
defines the values 1-3. All remaining values, except zero, are
available for assignment via Designated Expert [IANA].
9.7 Application Identifier
This specification assigns the value four (4) to the Application
Identifier namespace defined in [DIAMBASE]. See section 1.7 for more
information.
10.0 Security Considerations
This specification describes the Diameter Application necessary to
authenticate and authorize a Mobile IP Mobile Node. The
authentication algorithm used is dependent upon the transforms
available by the Mobile IP protocol, and [MIPCHAL]. This
specification also defines a method by which the home Diameter server
can create and distribute session keys to be used to authenticate
Mobile IP registration messages. The keys SHOULD be be protected
using the methods defined in [CMS].
et al. Calhoun expires September 2002 [Page 43]
Internet-Draft March 2002
11.0 References
11.1 Normative
[DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
"Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt,
IETF work in progress, November 2001.
[IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con¡
siderations Section in RFCs", BCP 26, RFC 2434, October
1998
[MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 2002, Octo¡
ber 1996.
[MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response
Extensions". RFC 3012. November 2000.
[NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC
2486. January 1999.
[CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security
Application", draft-ietf-aaa-diameter-cms-sec-03.txt,
IETF work in progress, November 2001.
[HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-
Hashing for Message Authentication. RFC 2104, February
1997.
[MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile
IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in
progress, July 2001.
11.2 Informative
[MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica¡
tion, Authorization, and Accounting Requirements". RFC
2977. October 2000.
[CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements
for AAA", RFC 3141, June 2001.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro¡
tocols", RFC 2477, January 1999.
et al. Calhoun expires September 2002 [Page 44]
Internet-Draft March 2002
[MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden¡
tifier Extension", RFC 2794, March 2000.
[RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random¡
ness Recommendations for Security. Request for Comments
(Informational) 1750, Internet Engineering Task Force,
December 1994.
12.0 Acknowledgements
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and
Pankaj Patel for their participation in the pre-IETF Document Reading
Party, to Erik Guttman for his very useful proposed text, and to
Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful
contributed text.
The authors would also like to thank the participants of 3GPP2's TSG-
P working group for their valuable feedback and also the following
people for their contribution in the development of the protocol:
Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael
Chen, Henry Haverinen
Pat Calhoun would like to thank Sun Microsystems since most of the
effort put into this document was done while he was in their employ.
13.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Black Storm Networks
250 Cambridge Avenue, Suite 200
Palo Alto, California, 94306
USA
Phone: +1 650-617-2932
Fax: +1 650-786-6445
E-mail: pcalhoun@bstormnetworks.com
et al. Calhoun expires September 2002 [Page 45]
Internet-Draft March 2002
Tony Johansson
Ericsson Inc
2100 Shattuck Avenue
Berkeley, California 94704
USA
Phone: +1 510-541-8783
Fax: +1 510-666-3900
E-Mail: tony.johansson@ericsson.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1 650-625-2986
Fax: +1 650-625-2502
E-Mail: charliep@iprg.nokia.com
14.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu¡
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop¡
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim¡
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS¡
CLAIMS 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.
et al. Calhoun expires September 2002 [Page 46]
Internet-Draft March 2002
15.0 Expiration Date
This memo is filed as <draft-ietf-aaa-diameter-mobileip-09.txt> and
expires in September 2002.
et al. Calhoun expires September 2002 [Page 47]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/