| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7. 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.
Figure 8 shows a signaling diagram that indicates a secure way to set
up the necessary security associations when using redirect servers.
The Proxy AAA represents any AAA server or servers that the HA may
use. This applies to the visited or home network.
Local redirect
HA Proxy AAA Agent AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA
3.4. Key Distribution
To allow the scaling of wireless data access across administrative
domains, it is necessary to minimize the number of pre-existing
Mobility Security Associations (MSAs) required. This means that each
Foreign Agent should not be required to have a pre-configured MSA
with each Home Agent on the Internet, nor should the mobile node be
required to have a pre-configured MSA (as defined in [MOBILEIP]) with
any specific foreign agent. Furthermore, when the mobile node
requests a dynamically allocated home agent, it is likely to receive
the address of a home agent for which it has no available mobility
security association.
The Diameter Mobile IPv4 application solves this by including key
distribution functionality, which means that after a Mobile Node is
authenticated the authorization phase includes the generation of
session keys and nonces. Specifically, three session keys and two
nonces are generated:
- K1: The MN-HA Session Key, which will be part of the MSA between
the Mobile Node and the Home Agent. The MN-HA Session Key
is derived from a nonce generated by AAA. The mobile node
obtains that nonce in the Registration Reply and generates
this key using the same formula that AAA uses.
- K2: The MN-FA Key, which will be part of the MSA between the
Mobile Node and the Foreign Agent. The MN-FA Key is derived
from a nonce generated by AAA. The mobile node obtains that
nonce in the Registration Reply and generates the MN-FA key
using the same formula that AAA uses.
- K3: The FA-HA Key, which will be part of the MSA between the
Foreign Agent and the Home Agent.
The same session key is used in both directions between two entities;
e.g., the Mobile Node and the Foreign Agent use the same session key
for the MN-FA and the FA-MN authentication extensions. The security
implications of this are examined in section 13. However, the SPIs
may be different for the MN-FA and the FA-MN authentication
extensions. The SPI for the MN-FA MSA is used on messages sent from
the MN to the FA, and the SPI for the FA-MN MSA is used on messages
sent from the FA to the MN.
All keys and nonces are generated by the AAAH, even if a Home Agent
is dynamically allocated in the foreign network.
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity
using the keys created by the DIAMETER server.
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session
Key and Nonce Distribution
The keys destined for the foreign and home agent are propagated to
the mobility agents via the Diameter protocol. If exposing keys to
the Diameter Agents along the way represents an unacceptable security
risk, then the keys MUST be protected either by IPSec or TLS security
associations that exist directly between the HA and AAAH or the FA
and AAAF, as explained above.
The keys destined for the mobile node MUST also be propagated via the
Mobile IPv4 protocol and therefore MUST follow the mechanisms
described in [MIPKEYS] instead. In [MIPKEYS], the mobile node
receives a nonce for each key it needs, and the mobile node will use
the nonce and the long-term shared secret to create the keys (see
section 8).
Once the session keys have been established and propagated, the
mobility devices can exchange registration information directly, as
defined in [MOBILEIP], without the need of the Diameter
infrastructure. However, the session keys have a lifetime, after
which the Diameter infrastructure MUST be invoked again if new
session keys and nonces are to be acquired.
4. Diameter Protocol Considerations
This section details the relationship of the Diameter Mobile IPv4
application to the Diameter base protocol.
This document specifies Diameter Application-ID 2. Diameter nodes
conforming to this specification MAY advertise support by including
the value of two (2) in the Auth-Application-Id or the Acct-
Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two
(2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA
commands. The value of two (2) MUST be used as the Application-Id in
all ACR/ACA commands, as this application defines new, mandatory AVPs
for accounting. The value of zero (0) SHOULD be used as the
Application-Id in all STR/STA and ASR/ASA commands, as these are
defined in the Diameter base protocol and no additional mandatory
AVPs for those commands are defined in this document.
Given the nature of Mobile IPv4, re-authentication can only be
initiated by a mobile node, which does not participate in the
Diameter message exchanges. Therefore, Diameter server initiated
re-auth does not apply to this application, and RAR/RAA commands MUST
NOT be sent for Diameter Mobile IPv4 sessions.
4.1. Diameter Session Management
The AAAH and AAAF 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.
A mobile node’s session is identified via its identity in the User-
Name AVP and 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 without
modification for this application. However, as the MN may interact
with more than one FA during the life of its session, it is important
for the Diameter Mobile IPv4 application to distinguish the two
pieces of the session (some state at the FA, some state at the HA)
and to manage them independently. The following sub-sections give
further details.
4.1.1. Session Identifiers
During creation of the AMR, the FA will choose a session identifier.
During the creation of the HAR, the AAAH MUST use a different session
identifier than that used in the AMR/AMA. If the AAAH is session-
stateful, it MUST 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.
When the HA is first allocated, it MUST create and include an Acct-
Multi-Session-Id AVP in the HAA returned to the AAAH. This
identifier will be kept constant for the life of the Mobile IPv4
session, as detailed in the next subsection.
4.1.2. Managing Sessions during Mobile IPv4 Handoffs
Given the nature of Mobile IPv4, 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, as this
could affect billing systems. Furthermore, foreign agents usually do
not communicate between each other, which implies that AAA
information cannot be exchanged between these entities.
A handoff registration request from a mobile node will cause the FA
to send an AMR to its AAAF. The AMR will include a new session
identifier and MAY be sent to a new AAAF (i.e., a AAAF different from
that used by the previous FA). However, the AMR shall be received by
the AAAH to which the user is currently registered (possibly via the
redirect mechanism depicted in Figure 3).
As 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 an existing service, then the HA MUST be able to
modify its internal session state information to reflect the new
session identifier.
For correlation to occur, accounting records must have some
commonality across handoffs. Therefore, the home agent MUST send the
same Acct-Multi-Session-Id AVP value in all HAAs for the mobile’s
session. That is, the HA generates a unique Acct-Multi-Session-Id
when receiving an HAR for a new session and returns this same value
in every HAA for the session. This Acct-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 Acct-Multi-Session-Id in the
accounting messages, as depicted in Figure 10.
4.1.3. 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. For a Diameter
Server to release any resources allocated to a specific mobile node,
that server has to receive a Session-Termination-Request (STR) from a
mobility agent. The mobility agents MUST issue the Session-
Termination-Request (STR) if the Authorization Lifetime has expired
and no subsequent MIP registration request has been received.
The AAAH 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 (for example, as a result of
a handover) does not cause the Home Diameter Server to free all
resources for the mobile node. Therefore, an STR from a foreign
agent would free the session from the foreign agent, but not the
session state associated with the home agent (see Figure 10).
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 10. Session Termination and Session Identifiers
When deallocating all of the mobile node’s resources, the home
Diameter server (and the foreign Diameter server in the case of an HA
allocated in foreign network) MUST destroy all session keys that may
still be valid.
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.
5. 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-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
5.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 (i.e., the Foreign Agent), acting as a Diameter client,
to an AAAF 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, 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)
Home Agent NAI (MIP-Home-Agent-Host AVP)
Home AAA server NAI (Destination-Host AVP [DIAMBASE])
Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI 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 home 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.
If the mobile node includes the home agent NAI and the home AAA
server NAI [AAANAI], the foreign agent MUST include the MIP-Home-
Agent-Host AVP and the Destination-Host AVP in the AMR.
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 }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
5.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 it is present in the AMR.
The Result-Code AVP MAY contain one of the values defined in section
6, 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-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-MSA and MIP-FA-to-MN-MSA if they were requested in the
AMR and were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-
to-MN-MSA 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.
Message Format
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]