Diameter Mobile IPv4 Application
Extracted elements (32)
All session keys (MN-HA, MN-FA, FA-HA) are generated by the AAAH even when the home agent is dynamically allocated in the foreign network. This centralizes key generation in the home administrative domain regardless of where the HA resides.
Mobile nodes cannot receive session keys via Diameter because they only speak Mobile IPv4. The AAAH therefore delivers nonces (not keys) to the MN via the Home Agent's Mobile IPv4 Registration Reply using the 'Generalized MN-HA Key Generation Nonce Reply' extension; the MN derives session keys from the nonce combined with its long-term MN-AAA shared secret.
The Acct-Multi-Session-Id AVP is introduced to correlate accounting records across Mobile IPv4 handoffs, where a mobile node may visit many foreign agents. The HA generates this identifier once for a new session and returns it unchanged in every subsequent HAA, allowing billing systems to treat the full mobility session as a single unit.
Mobile nodes interact with the HA and FA using only Mobile IPv4 and do not implement Diameter. The FA and HA act as Diameter clients on the MN's behalf, extracting relevant fields from Mobile IPv4 Registration Requests to construct Diameter AVPs.
The Diameter Mobile IPv4 Application is not applicable to the Mobile IPv6 protocol.
AAA redirect agents and relay agents MUST NOT maintain session-state. The AAAH, AAAF, proxies, and relay agents MUST maintain transaction state.
An AMA message with Result-Code DIAMETER_SUCCESS MUST include MIP-Home-Agent-Address and MIP-Mobile-Node-Address AVPs. It MUST contain MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested and present in the HAR; MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA MUST be present if session keys were requested and Co-Located-Mobile-Node was set.
If exposing session keys to Diameter agents along the route represents an unacceptable security risk, the keys MUST be protected by IPSec or TLS security associations established directly between the HA and AAAH, or between the FA and AAAF.
If no security association exists between the AAAH and the home agent and one cannot be established, the AAAH MUST return a Result-Code AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
If non-zero, the MIP-MSA-Lifetime AVP value MUST be at least equal to the Authorization-Lifetime AVP. A value of zero in MIP-MSA-Lifetime indicates infinity (no timeout).
If session keys are requested, the AAAH MUST return the keys and nonces after the mobile node is successfully authenticated and authorized.
Mobility agents MUST issue a 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 receiving the STR from the home agent, not from a foreign agent.
RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions because re-authentication can only be initiated by the mobile node, which does not participate in Diameter exchanges.
The AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR to the HAR. If the MIP-Home-Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the HAR.
The AAAH must generate a random nonce of at least 128 bits for delivery to the mobile node via the Registration Reply, and must generate a random value of at least 128 bits for use as the FA-HA session key.
The AAAH MUST use a different Session-Id in the HAR/HAA exchange than the one used in the AMR/AMA exchange. If session-stateful, the AAAH MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session.
The home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for a mobile node's session. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in accounting messages to enable billing correlation across handoffs.
The value 2 MUST be used as the Application-Id in all AMR/AMA and HAR/HAA commands, and in all ACR/ACA commands because this application defines new mandatory accounting AVPs. The value 0 SHOULD be used for STR/STA and ASR/ASA commands.
When deallocating a mobile node's resources, the home Diameter server (and the foreign Diameter server if an HA is allocated in a foreign network) MUST destroy all session keys that may still be valid.
When the FA detects a home agent address of 0.0.0.0 or 255.255.255.255 in the Registration Request, it MUST add a MIP-Feature-Vector AVP with Home-Agent-Requested set to one; address 255.255.255.255 additionally requires Home-Address-Allocatable-Only-in-Home-Realm set to one.
The AA-Mobile-Node-Request (AMR), Command-Code 260 with 'R' bit set, is sent by the FA (or HA for co-located MN) to the AAAF to request authentication and authorization. Mandatory AVPs include Session-Id, Auth-Application-Id, User-Name, Destination-Realm, Origin-Host, Origin-Realm, MIP-Reg-Request, and MIP-MN-AAA-Auth.
The Home-Agent-MIP-Request (HAR), Command-Code 262 with 'R' bit set, is sent by the AAAH to the Home Agent carrying the encapsulated Mobile IPv4 Registration Request and session keys. Mandatory AVPs include Authorization-Lifetime, Auth-Session-State, MIP-Reg-Request, User-Name, Destination-Realm, and MIP-Feature-Vector.
The MIP-Feature-Vector AVP (AVP Code 337, type Unsigned32) carries nine defined flag bits: Mobile-Node-Home-Address-Requested (1), Home-Address-Allocatable-Only-in-Home-Realm (2), Home-Agent-Requested (4), Foreign-Home-Agent-Available (8), MN-HA-Key-Request (16), MN-FA-Key-Request (32), FA-HA-Key-Request (64), Home-Agent-In-Foreign-Network (128), Co-Located-Mobile-Node (256).
The MIP-MN-AAA-Auth grouped AVP (AVP Code 322) carries ancillary data to simplify authentication processing: MIP-MN-AAA-SPI (code 341, Unsigned32), MIP-Auth-Input-Data-Length (code 338, Unsigned32), MIP-Authenticator-Length (code 339, Unsigned32), and MIP-Authenticator-Offset (code 340, Unsigned32).
The MIP-Originating-Foreign-AAA AVP (AVP Code 347, type Grouped) identifies the AAAF that issues the AMR; it contains Origin-Realm and Origin-Host sub-AVPs and MUST only be used when the home agent is or may be allocated in a foreign domain.
This document registers Application-ID 2 for the Diameter Mobile IPv4 Application in the Diameter Application Identifiers registry.
This document registers AVP Codes: MIP-Reg-Request (320), MIP-Reg-Reply (321), MIP-MN-AAA-Auth (322), MIP-Mobile-Node-Address (333), MIP-Home-Agent-Address (334), MIP-Candidate-Home-Agent-Host (336), MIP-Feature-Vector (337), MIP-Auth-Input-Data-Length (338), MIP-Authenticator-Length (339), MIP-Authenticator-Offset (340), MIP-MN-AAA-SPI (341), MIP-Filter-Rule (342), MIP-FA-Challenge (344), MIP-Originating-Foreign-AAA (347), MIP-Home-Agent-Host (348).
This document registers Diameter Command Codes 260 (AA-Mobile-Node-Request/Answer, AMR/AMA) and 262 (Home-Agent-MIP-Request/Answer, HAR/HAA) in the Diameter Command Codes registry.
This document registers new Diameter Result-Code values: transient failures DIAMETER_ERROR_MIP_REPLY_FAILURE (4005), DIAMETER_ERROR_HA_NOT_AVAILABLE (4006), DIAMETER_ERROR_BAD_KEY (4007), DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED (4008); permanent failures DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE (5024) and DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION (5025).
A single session key is shared in both directions for each MSA pair (e.g., the same key is used for MN-FA and FA-MN authentication extensions), even though SPIs may differ per direction. The security implications of this symmetric key distribution model are acknowledged by the specification.
Session keys distributed via Diameter are exposed to all Diameter proxy and relay agents along the path. To prevent this, end-to-end IPSec or TLS security associations must be established directly between FA/HA and AAAH, eliminating all intermediate Diameter agents from the key transport path.
The MIP-MN-AAA-Auth grouped AVP (code 322) has the ABNF structure: MIP-MN-AAA-SPI (mandatory), MIP-Auth-Input-Data-Length (mandatory), MIP-Authenticator-Length (mandatory), MIP-Authenticator-Offset (mandatory). MIP-Auth-Input-Data-Length is the byte length of the Registration Request data to hash; MIP-Authenticator-Offset is the byte offset into Registration Request data where the authenticator begins.