[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
5.3. Home-Agent-MIP-Request
The AAA sends 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, 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 to the HA if no redirect servers are involved. If any are,
the HAR is sent directly to the HA via a security association. If
the HAR message does not include a MIP-Mobile-Node-Address AVP, the
Registration Request has 0.0.0.0 for the home address, and the HAR is
successfully processed, the Home Agent MUST allocate the mobile nodes
address. If, on the other hand, the home agent’s local AAA server
allocates the mobile node’s home address, the local AAA server MUST
include the assigned address in a MIP-Mobile-Node-Address AVP.
When session keys are requested for use by the mobile node, the AAAH
MUST create them and include them in the HAR message. When a FA-HA
session key is requested, it will be created and distributed by the
AAAH server.
Message Format
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
5.4. Home-Agent-MIP-Answer
In response to a Home-Agent-MIP-Request, the Home Agent sends 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, to its
local AAA server. The User-Name MAY be included in the HAA if it is
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 6 instead of the values defined in [DIAMBASE].
Message Format
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-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 ]
* [ Proxy-Info ]
* [ AVP ]
6. 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.
6.1. Transient Failures
Errors in the transient failures category are used to inform a peer
that the request could not be satisfied at the time it was received,
but that it 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 IPv4
Registration Reply to the mobile node with an appropriate
error code.
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.
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008
This error code is used by a mobility agent to indicate to
the home Diameter server that the requested packet filter
Rules cannot be supported.
6.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.
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025
This error is used by the AAAF/AAAH to inform the peer that
the requested Mobile IPv4 session keys could not be
delivered via a security association.
7. Mandatory AVPs
The following table describes the Diameter AVPs defined in the Mobile
IPv4 application; their AVP Code values, types, and 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.
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N |
Host
7.1. MIP-Reg-Request AVP
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and
contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the
mobile node to the foreign agent.
7.2. MIP-Reg-Reply AVP
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and
contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the
home agent to the foreign agent.
7.3. MIP-Mobile-Node-Address AVP
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and
contains the mobile node’s home IP address.
7.4. MIP-Home-Agent-Address AVP
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and
contains the mobile node’s home agent IP address.
7.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 the following:
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., one not equal
to 0.0.0.0 or 255.255.255.255) in its Registration Request, the
foreign agent sets the Mobile-Node-Home-Address-Requested flag in the
MIP-Feature-Vector AVP to zero.
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.
Whenever the foreign agent sets either the
Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested
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 Generation Nonce Request" [MIPKEYS] extension,
with the subtype set to AAA.
If the mobile node includes a "Generalized MN-FA Key Generation Nonce
Request" [MIPKEYS] extension with the AAA subtype (1) 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 AAAF is willing and able to assign a home agent in the foreign
network, the AAAF sets the Foreign-Home-Agent-Available flag 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 FA-HA key with the home agent,
the foreign agent 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 both 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.
7.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 IPv4 Registration Request [MOBILEIP, MIPCHAL] 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 ]
7.6.1. MIP-MN-AAA-SPI AVP
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
indicates the MSA by which the targeted AAA server (AAAH) should
attempt to validate the Authenticator computed by the mobile node
over the Registration Request data.
7.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, as indicated by the MN-AAA-SPI AVP,
used to determine whether the Authenticator Data supplied by the
mobile node is valid.
7.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).
7.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).
7.7. MIP-FA-Challenge AVP
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 [MIPCHAL].
7.8. MIP-Filter-Rule AVP
The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and
provides filter rules that have to be configured on the foreign or
home agent for the user. The packet filtering rules are set by the
AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if
destined for the home agent and/or in the AMA if destined for the
foreign agent.
7.9. 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 to be dynamically assigned to
the mobile node.
7.10. MIP-Originating-Foreign-AAA AVP
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is 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
the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH
MUST copy it into the HAR.
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]
7.11. MIP-Home-Agent-Host AVP
The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and
contains the identity of the assigned Home Agent. If the MIP-Home-
Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the
HAR.
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
8. Key Distribution
The mobile node and mobility agents use session keys (i.e.,
the MN-FA, FA-HA, and MN-HA session keys) to compute authentication
extensions applied to MIP registration messages, as defined in
[MOBILEIP]. If session keys are requested, the AAAH MUST return the
keys and nonces after the mobile node is successfully authenticated
and authorized.
The SPI values are used as key identifiers, and each session key has
its own SPI value; nodes that share a key can have multiple different
SPIs all referring to the same key. In all cases, the entity that
receives an authentication extension (i.e., that verifies the
authentication extension) is providing the entity that sends the
authentication extension (i.e., that computes the authentication
extension) the value of the SPI to use for that computation. Note
that the keys in this model are symmetric in that they are used in
both directions, even though the SPIs do not have to be symmetric.
The mobile node allocates SPIs for use in the FA-MN and HA-MN
mobility security associations, via the Mobile IPv4 AAA Key Request
extensions [MIPKEYS]. The home agent allocates SPIs for the MN-HA
and FA-HA mobility security association. The foreign agent chooses
SPIs for the MN-FA and HA-FA mobility security associations.
Once the session keys and nonces have been distributed, subsequent
Mobile IPv4 registrations need not invoke the AAA infrastructure
until the keys expire. As mandated by Mobile IPv4, these
registrations MUST include the MN-HA authentication extension.
Likewise, subsequent registrations MUST also include MN-FA
authentication extension if the MN-FA session key was generated and
distributed by AAA. The same hold true for subsequent use of the
FA-HA authentication extensions.
8.1. Authorization Lifetime vs. MIP Key Lifetime
The Diameter Mobile IPv4 application makes use of two timers: the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-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-MSA-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-MSA-Lifetime AVP MUST be at least equal to
the value in the Authorization Lifetime AVP.
8.2. Nonce vs. Session Key
As described in section 3.4, the AAAH generates session keys and
transmits them to the home agent and foreign agent. The AAAH
generates nonces that correspond to the same keys and transmits them