RFC 4004
Diameter Mobile IPv4 Application
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.45.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 ] [ 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 to the mobile node. When it is necessary to protect the session keys and SPIs from un-trusted Diameter agents, end-to-end security mechanisms such as TLS or IPSec are required to eliminate all Diameter Agents between the FA or HA and the AAAH, as outlined above. In [MIPKEYS], the mobility security associations are established via nonces transmitted to the mobile node via Mobile IPv4. To provide the nonces, the AAAH must generate a random [RANDOM] value of at least 128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the MN-HA and MN-FA session keys. More details of the MN-HA and the MN-FA session key creation procedures are found in [MIPKEYS]. The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce. The FA-HA and HA-FA session key is shared between the FA and HA. The AAAH generates a random [RANDOM] value of at least 128 bits for use as this session key. See sections 9 for details about the format of the AVPs used to transport the session keys.8.3. Distributing the Mobile-Home Session Key
If the mobile node does not have an MN-HA session key, then the AAAH is likely to be the only trusted entity that is available to the mobile node. Thus, the AAAH has to generate the MN-HA session key. The distribution of the HA-MN (session) key to the HA is specified in sections 1.2 and 3.4. The HA and AAAH establish a security association (IPSec or TLS) and transport the key over it. If no security association exists between the AAAH and the home agent and a security association cannot be established, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAAH only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IPv4 messages and extensions [MOBILEIP]. For this purpose, AAAH includes the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added to the HAR (for FA COA style Mobile IPv4) or to the AMA (for collocated COA-style Mobile IPv4 messages) and delivered either to a local home agent or a home agent in the visited network. Note that the mobile node will use the nonce to create the MN-HA session key by using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the home agent (which also understands Diameter) to transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply message. The HA includes the SPIs proposed by the mobile node and the home agent in the "Generalized MN-HA Key Generation Nonce Request" 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. The AAAH parses the HAA message, transforms it into an AMA message containing an MIP-Reg-Reply AVP, and sends the AMA message to the foreign agent. The foreign agent then uses that AVP to recreate a Registration Reply message containing the "Generalized MN-HA Key Generation Nonce Reply" extension for delivery to the mobile node. In summary, the AAAH generates the MN-HA nonce, which is added to the MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR or AMA messages. The home agent retains the session key for its own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a "Generalized MN-HA Key Generation Nonce Reply" extension, which is appended to the Mobile IPv4 Registration Reply message. This Registration Reply message MUST also include the HA-MN authentication extension, which is created by using the newly allocated HA-MN session key. The home agent then includes the Registration Reply message and extensions into a MIP-Reg-Reply AVP as part of the HAA message to be sent back to the AAA server. The key derived by the MN from the MN-HA session nonce is identical to the HA-MN session key provided to the HA.8.4. Distributing the Mobile-Foreign Session Key
The MN-FA session nonce is also generated by AAAH (upon request) and added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and copied by the home agent into a "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration Reply message. The HA also includes the SPIs proposed by the mobile
node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. The AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in the computation of the FA-MN authentication extension. The key derived by the MN from the MN-FA session nonce is identical to the FA-MN session key provided to the FA.8.5. Distributing the Foreign-Home Session Key
If the foreign agent requests an FA-HA session key, it also includes a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the home agent for this purpose. The AAAH generates the FA-HA session key, which is identical to the HA-FA session key, and distributes that to both the HA and the FA over respective security associations by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA conveys the SPI that the FA MUST use in the HAA; this is similar to the way in which the FA conveys that the SPI that the HA MUST use in the AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA AVPs, respectively, along with the session key. Refer to Figures 2, 3, 4, and 6 for the messages involved. Note that if multiple MNs are registered on the same FA and HA pair, then multiple mobility security associations would be distributed. However, only one is required to protect the Mobile IP control traffic between FA and HA. This creates an unacceptable level of state (i.e., to store the two SPIs and shared key for each FA-HA mobility security association). To improve scalability, the FA and HA may discard FA-HA mobility security associations prior to the time when they actually expire. However, if a proper discard policy is not chosen, this could cause Mobile IP messages in transit or waiting in queues for transmission to fail authentication. The FA MUST always use the FA-HA security association with the latest expiry time when computing authentication extensions on outgoing messages. The FA MAY discard HA-FA mobility security associations 10 seconds after a new HA-FA mobility security association arrives with a later expiry time. The HA SHOULD use the HA-FA mobility security association that has the latest expiry time when computing authentication extensions in outgoing messages. However, when the HA receives a new HA-FA mobility security association with a later expiry time, the HA SHOULD wait 4 seconds for the AMA to propagate to the FA before using the new association. Note that the HA always uses the mobility security association from the HAR when constructing the Mobile IP Registration Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility
security association once it receives a message authenticated by a FA-HA mobility security association with a later expiry time.
(page 38 continued on part 3)
