Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction
Extracted elements (30)
Mobile IPv6 bootstrapping AVPs are only included in the first DER message; subsequent DER messages required by the EAP method do not include them, because authentication and authorization for the mobility service occur together during EAP authentication.
The preferred accounting model is the split accounting model using the Diameter Base Accounting Application Identifier (value 3), because it permits centralized accounting for several applications by routing accounting messages independently from Mobile IPv6 application messages.
When the HA also acts as an IKEv2 responder for conventional IPsec VPN access, it may not know whether IKEv2 is being used for Mobile IPv6 or VPN. One solution is to use different responder identities for each role, allowing the MN to indicate the preferred type via the IDr payload in IKE_AUTH.
An MIA message with Result-Code set to DIAMETER_SUCCESS MUST include the MIP-Mobile-Node-Address AVP.
If the MIP6-Agent-Info AVP is present in an answer message and Result-Code is DIAMETER_SUCCESS_RELOCATE_HA, the HA MUST initiate an HA switch procedure towards the MN. For any other result code, the HA SHOULD initiate the switch.
It is RECOMMENDED that the HA sends an accounting request message every time it receives a Binding Update, for both the IKEv2/EAP and the Mobile IPv6 Authentication Protocol scenarios.
The Application-ID field of the Diameter Header in a DER message MUST be set to the Diameter Mobile IPv6 IKE Application ID (value 7).
The associated session key (MIP-Session-Key) MUST NOT be used if the MIP-MSA-Lifetime has expired.
The Auth-Request-Type AVP in the DER message MUST be set to AUTHORIZE_AUTHENTICATE, since the MN is both authenticated and authorized for the mobility service during EAP authentication.
The HA MUST be able to act as a Diameter client collecting accounting records and MUST support the accounting procedures and the Accounting Session State Machine as defined in RFC 3588.
The HA MUST copy the MN-NAI mobility option value to the User-Name AVP in subsequent Diameter request messages when the Mobile IPv6 Authentication Protocol is used.
The HA MUST support the Authorization Session State Machine defined in RFC 3588. Each SA created between the MN and HA as a result of IKEv2 negotiation or a Mobile IPv6 Authentication Protocol exchange corresponds to one Diameter session.
When the HA receives an Abort-Session-Request (ASR) message, it MUST terminate the corresponding SA and MUST take further actions to terminate the corresponding Mobile IPv6 binding.
When the HA receives an STR (Session-Termination-Request), it MUST terminate the corresponding Mobile IPv6 binding and also terminate the corresponding SA.
When the MIP6-Auth-Mode AVP is set to MIP6_AUTH_MN_AAA, the Auth-Request-Type AVP MUST be set to AUTHORIZE_AUTHENTICATE. If the Diameter server does not support the proposed mode, it MUST fail authentication and MUST set Result-Code to DIAMETER_ERROR_MIP6_AUTH_MODE.
When using IKEv2 with EAP for Mobile IPv6 bootstrapping, EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to man-in-the-middle attacks.
The MIP-Authenticator AVP (AVP Code 488, OctetString) carries the Authenticator Data extracted from the MN-AAA Mobility Message Authentication Option in the received Binding Update. It MUST be present in the MIR when MIP6-Auth-Mode is MIP6_AUTH_MN_AAA.
The MIP-MAC-Mobility-Data AVP (AVP Code 489, OctetString) contains the MAC_Mobility_Data calculated by the HA for the MN-AAA Mobility Message Authentication Option as defined in RFC 4285. It MUST be present in the MIR when MIP6-Auth-Mode is MIP6_AUTH_MN_AAA.
The MIP-MN-HA-MSA AVP (AVP Code 492, Grouped) contains session-related information for the Mobile IPv6 Authentication Protocol, including MIP-Session-Key (mandatory), MIP-MSA-Lifetime (mandatory), and optionally MIP-MN-HA-SPI, MIP-Algorithm-Type, and MIP-Replay-Mode. Absence of MIP-Replay-Mode MUST be treated as no replay protection selected.
The MIP-Timestamp AVP (AVP Code 490, OctetString) contains an 8-octet (64-bit) timestamp value extracted from the Mobility message replay protection option defined in RFC 4285.
The MIP6-Auth-Mode AVP (AVP Code 494, Enumerated) conveys the Mobile IPv6 Authentication Protocol mode used. This specification defines only one value, MIP6_AUTH_MN_AAA (value 1), for the case where the MN-AAA security association is used to authenticate the Binding Update.
The Service-Selection AVP (AVP Code 493, UTF8String) identifies the service or external network with which the mobility service should be associated; it can be extracted from the IKEv2 IDr payload or the Service Selection Mobility Option in the BU. If present in both request and reply, it SHOULD contain the same service name.
Two new Diameter application identifiers are defined: Diameter Mobile IPv6 IKE (MIP6I) with value 7, used when the MN authenticates via IKEv2, and Diameter Mobile IPv6 Auth (MIP6A) with value 8, used when the MN authenticates via the Mobile IPv6 Authentication Protocol.
IANA created a new 'MIP6 Authentication Mode Registry' for the enumerated MIP6-Auth-Mode AVP, initially containing MIP6_AUTH_MN_AAA (value 1). New values require Specification Required policy. Value 0 is reserved; maximum is 2^32-1.
IANA registered a new Command Code for MIP6-Request/Answer (MIR/MIA) with value 325, and two new Application Identifiers: Diameter Mobile IPv6 IKE (MIP6I) = 7 and Diameter Mobile IPv6 Auth (MIP6A) = 8, in the Diameter namespace.
IANA registered new AVP Codes for MIP-Careof-Address (487), MIP-Authenticator (488), MIP-MAC-Mobility-Data (489), MIP-Timestamp (490), MIP-MN-HA-SPI (491), MIP-MN-HA-MSA (492), Service-Selection (493), and MIP6-Auth-Mode (494).
IANA registered two new Result-Code AVP values: DIAMETER_SUCCESS_RELOCATE_HA (2009), indicating the MN must be switched to another HA, and DIAMETER_ERROR_MIP6_AUTH_MODE (5041), indicating the requested auth mode is unsupported.
Diameter messages between the HA and Diameter server may traverse AAA brokers or Diameter agents, so security relies on the properties of those intermediary networks and agents. The specification does not define how the Diameter server derives MN-HA session keys, leaving security properties deployment-specific.
The MIP6-Answer (MIA) command uses Command-Code 325 with the 'R' bit cleared. A successful MIA (Result-Code DIAMETER_SUCCESS) MUST include the MIP-Mobile-Node-Address AVP.
The MIP6-Request (MIR) command uses Command-Code 325 with the 'R' bit set. It is mandatory to include User-Name, Auth-Application-Id, Destination-Realm, Origin-Host, Origin-Realm, Auth-Request-Type, MIP6-Auth-Mode, 1-2 MIP-Mobile-Node-Address AVPs, MIP6-Agent-Info, and MIP-Careof-Address.