+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
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 forwarded to another Diameter server known as the AAA-Home, or
AAAH. Figure 1 shows an example in which a mobile node
(mn@example.org) requests service from a foreign provider
(example.net). The request received by the AAAF is forwarded to
example.org’s AAAH server.
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 5.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 IPv4/Diameter Message Exchange
The foreign agent (as shown in Figure 2) MAY provide a challenge,
which would give it direct control over the replay protection in the
Mobile IPv4 registration process, as described in [MIPCHAL]. The
mobile node includes the Challenge and MN-AAA authentication
extension to enable authorization by the AAAH. If the authentication
data supplied in the MN-AAA extension is invalid, the AAAH returns
the response (AMA) with the Result-Code AVP set to
DIAMETER_AUTHENTICATION_REJECTED.
The above scenario causes the MN-FA and MN-HA keys to be exposed to
Diameter agents all along the Diameter route. If this is a concern,
a more secure approach is to eliminate the AAAF and other Diameter
agents, as shown in Figure 3.
Redirect
FA AAAF Agent AAAH
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
Setup Security Association
<-------------------------------------------------->
AMR
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
Figure 3. Use of a Redirect Server with AMR/AMA
In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based
security association with the AAAH directly and runs the AMR/AMA
exchange over it. This provides end-to-end security for secret keys
that may have to be distributed.
Figure 4 shows the interaction between the AAAH and HA with the help
of a redirect agent. When the AAAH and HA are in the same network,
it is likely that the AAAH knows the IP address of the HA, so the
redirect server would therefore not be needed; however, it is shown
anyway for completeness. The redirect server will most likely be
used in the case where the HA is allocated in a foreign network (see
section 3.2 for more details of HA allocation in foreign networks).
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4. Use of a Redirect Server with HAR/HAA
As in Figure 2, the FA of Figure 3 would still provide the challenge
and the mobile sends the RRQ, etc.; however, these steps were
eliminated from Figure 3 to reduce clutter. The redirect server
eliminates the AAAF and any other Diameter agents from seeing the
keys as they are transported to the FA and HA. Note that the message
flows in Figures 3 and 4 apply only to the initial authentication and
key exchange. Accounting messages would still be sent via Diameter
agents, not via the direct connection, unless network policies
dictate otherwise.
A mobile node that supports the AAA NAI extension [AAANAI], which has
been previously authenticated and authorized, MUST always include the
assigned home agent in the HA Identity subtype of the AAA NAI
extension, and the authorizing Home AAA server in the AAAH Identity
subtype of the AAA NAI extension, when re-authenticating. Therefore,
in the event that the AMR generated by the FA is for a session that
was previously authorized, it MUST include the Destination-Host AVP,
with the identity of the AAAH found in the AAAH-NAI, and the MIP-
Home-Agent-Host AVP with the identity and realm of the assigned HA
found in the HA-NAI. If, on the other hand, the mobile node does not
support the AAA NAI extension, the FA may not have the identity of
the AAAH and the identity and realm of the assigned HA. This means
that without support of the AAA NAI extension, the FA may not be able
to guarantee that the AMR will be destined to the same AAAH, which
previously authenticated and authorized the mobile node, as the FA
may not know the identity of the AAAH.
If the mobile node was successfully authenticated, the AAAH then
determines which Home Agent to use for the session. First, the AAAH
checks whether an HA has been requested by the MN by checking the
MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The
administrative domain owning the HA may be determined from the realm
portion of the MIP-Home-Agent-Host AVP, or by checking the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and
the value of the MIP-Originating-Foreign-AAA AVP. If the requested
HA belongs to a permitted administrative domain, the AAAH SHOULD use
the given HA for the session. Otherwise, the AAAH returns the
response (AMA) with the Result-Code AVP set to either
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or
DIAMETER_ERROR_HA_NOT_AVAILABLE.
If the MN has not requested any particular HA, then an HA MUST be
dynamically allocated. In this case the MIP-Feature-Vector will have
the Home-Agent-Requested flag set. If the Home-Address-Allocatable-
Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent-
Available flag is set, then the AAAH SHOULD allow the foreign realm
to allocate the HA (see section 3.2) but MAY allocate one itself in
the home realm if dictated by local policy. If the Home-Address-
Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST
allocate an HA in the home realm on behalf of the MN. Allocation of
the HA can be done in a variety of ways, including by using a load-
balancing algorithm to keep the load on all home agents equal. The
actual algorithm used and the method of discovering the home agents
are outside the scope of this specification.
The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains
the Mobile IPv4 Registration Request message data encapsulated in the
MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer
to Figure 4 if the AAAH does not have a direct path to the HA. The
AAAH MAY allocate a home address for the mobile node, and the Home
Agent MUST support home address allocation. In the event that the
AAAH handles address allocation, it includes the home address in a
MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP
informs the Home Agent that it must perform the home address
allocation.
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. In the creation of the Registration Reply, the Home Agent
MUST include the HA NAI and the AAAH NAI, which will be created from
the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home
address is needed, the home agent MUST also assign one and include
the address in both the Registration Reply and the MIP-Mobile-Node-
Address AVP.
Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
(AMA) message, which includes the same Acct-Multi-Session-Id
contained in the HAA and the MIP-Home-Agent-Address and MIP-Mobile-
Node-Address AVPs in the AMA message. See Figures 3 and 4 for the
use of the redirect agent for the secure transport of the HAA and AMA
messages.
See section 4.1 for information on the management of sessions and
session identifiers by the Diameter Mobile IPv4 entities.
3.2. Allocation of Home Agent in Foreign Network
The Diameter Mobile IPv4 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 set to
255.255.255.255, the foreign agent 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 with 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 in order 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
(i.e., a DiameterIdentity, which is an FQDN) 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. The AAAF now
sends the AMR to the AAAH. However, as discussed above, the use of
Diameter agents between the FA and AAAH would expose the MN-FA key.
If this is deemed undesirable, a redirect server approach SHOULD be
utilized to communicate the AMR to the AAAH. This causes the FA to
communicate the AMR directly to the AAAH via a security association.
If the mobile node with AAA NAI extension support [AAANAI] has been
previously authorized by the AAAH, now has to be re-authenticated,
and requests to keep the assigned home agent in the foreign network,
the mobile node MUST include the HA NAI and the AAAH NAI in the
registration request to the FA. Upon receipt, the FA will create the
AMR, including the MIP-Home-Agent-Address AVP and the Destination-
Host AVP based on the AAAH NAI, and include the MIP-Home-Agent-Host
AVP based on the home agent NAI. If the AAAF authorizes the use of
the requested home agent, the AAAF MUST set the Home-Agent-In-
Foreign-Network bit in the MIP-Feature-Vector AVP.
If the mobile node has to be re-authenticated but does not support
the AAA NAI extension, it sends a registration request without the
AAA NAI and the HA NAI, even though it has previously been authorized
by the AAAH and requests to keep the assigned home agent in the
foreign network. Upon receipt, the FA will create the AMR, including
the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of
the requested home agent, and if it knows that the agent is in its
own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit
in the MIP-Feature-Vector AVP.
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 (i.e., the
Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP),
or if the AMR indicates that the AAAF has offered a previously
allocated Home Agent for the mobile node (i.e., the Home-Agent-In-
Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH
must decide whether its local policy would allow the user to have or
keep a home agent in the foreign network. Assuming that the mobile
node is permitted to do so, the AAAH determines the IP address of the
HA based upon the FQDN of the HA by using DNS or learns it via an
MIP-Home-Agent-Address AVP in a redirect response to an HAR (i.e., if
the redirect server adds this AVP to the HAA). Then it sends an HAR
message to Home Agent by including the Destination-Host AVP set to
the value found in the AMR’s MIP-Candidate-Home-Agent-Host AVP or
MIP-Home-Agent-Host AVP. If DNS is used to determine the HA IP
address, it is assumed that the HA has a public address and that it
can be resolved by DNS.
Security considerations may require that the HAR be sent directly
from the AAAH to the HA without the use of intermediary Diameter
agents. This requires that a security association between the AAAH
and HA be established, as in Figure 4. If no security association
can be established, the AAAH MUST return an AMA with the Result-Code
AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
If Diameter agents are being used (e.g., if there is no redirect
server) the AAAH sends the HAR to the originating AAAF. In this HAR
the Destination-Host AVP is set to the value found in the AMR’s MIP-
Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the
MIP-Candidate-Home-Agent-Host AVP found in the AMR is copied into the
HAR.
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 receives the HAR, this new AAAF will send the HAR to the HA.
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 an 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.
If exposing keys to the Diameter Agents along the way represents an
unacceptable security risk, then the redirect approach depicted in
Figures 3 and 4 MUST be used instead.
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in
Visited Realm
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 AAAH will have to
provide services for both visited networks; e.g., key refresh.
3.3. Co-located Mobile Node
If a mobile node registers with the Home Agent as a co-located mobile
node, no foreign agent is 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 Acct-
Multi-Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent
to the AAAH, as the AAAH may find this piece of session-state or log
entry information useful.
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA