RFC 4004
Diameter Mobile IPv4 Application
Network Working Group Request for Comments: 4004 P. Calhoun Category: Standards Track Cisco Systems, Inc. T. Johansson Bytemobile Inc C. Perkins Nokia Research Center T. Hiller, Ed. P. McCann Lucent Technologies August 2005 Diameter Mobile IPv4 Application Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).Abstract
This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4 1.2. Mobility Security Associations. . . . . . . . . . . . . . 4 1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Structure of the Document . . . . . . . . . . . . . . . . 7 2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7 3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .53
1. Introduction
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point
of attachment to the Internet while maintaining its fixed home
address. Packets directed to the home address are intercepted by a
Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at
its current point of attachment. Optionally, a Foreign Agent (FA)
may be deployed at this point of attachment, which can serve as the
tunnel endpoint and may also provide access control for the visited
network link. In this role, the FA has to authenticate each MN that
may attach to it, whether the MN is from the same or a different
administrative domain. The FA has to verify that the MN is
authorized to attach and use resources in the foreign domain. Also,
the FA must provide information to the home administrative domain
about the resources used by the MN while it is attached in the
foreign domain.
The Authentication, Authorization, and Accounting (AAA) requirements
for Mobile IPv4 are described in detail in other documents [MIPREQ,
CDMA2000]. This document specifies a Diameter application to meet
these requirements. This application is not applicable to the Mobile
IPv6 protocol.
Message formats (e.g., as in section 5.1) are specified as lists of Attribute-Value Pairs (AVPs) using the syntax as described in RFC 2234 [ABNF]. This includes the use of the "*" symbol to denote zero or more occurrences of an AVP. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].1.1. Entities and Relationships
The Diameter Mobile IPv4 Application supports the HA and FA in providing Mobile IPv4 service to MNs. Both the HA and FA act as Diameter clients. The MNs interact with the HA and FA by using only Mobile IPv4 and therefore do not implement Diameter. The FA, when present, is always assumed to exist in the visited administrative domain. The HA may be statically or dynamically allocated to the MN in the home administrative domain or may be dynamically allocated to the MN in a visited administrative domain. The home domain contains a home AAA server (AAAH), and the visited domain contains a foreign AAA server (AAAF). When the MN is "at home" (present on its home network), the AAAH and AAAF may be the same.1.2. Mobility Security Associations
The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a Mobility Security Association (MSA) between the MN and HA (MN-HA MSA). The MN-HA MSA is used to authenticate, by using a keyed hash- style algorithm, the Mobile IP Registration Request that is sent from the MN to the HA. It is important to authenticate Registration Requests, as they inform the HA about the MN's current Care-of- Address, which is the destination for tunneled packets from the home network. Without authentication, malicious attackers would be able to redirect packets to anywhere on the Internet. The MSA comprises an agreement on a Security Parameters Index (SPI, a 32-bit number) that will be used to refer to the MSA, an algorithm that will be used to compute keyed hashes over messages, and a shared secret key. To enable authentication of a message, the sender appends a Mobile IP Authentication Extension that contains the SPI and the result of running the keyed hash over the entire previous contents of the message. The recipient checks the Authentication Extension by looking up the MSA based on the SPI, re-computing the keyed hash, and verifying that the result is equal to the contents of the received Authentication Extension.
The base Mobile IPv4 protocol also supports an optional MSA between the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by the FA to authenticate each Registration Request passing through it on the way to the HA. Although not critical to the operation of the base protocol, the MN-FA MSA is useful when the FA has to know the authenticity of a Registration Request; e.g., when it will be generating accounting records for a session. The MN-FA MSA may also be useful in future work related to handoff optimization. Similarly, Mobile IPv4 supports an optional MSA between the FA and HA (FA-HA MSA). The FA-HA MSA is useful for authenticating messages between the FA and HA, such as when the HA seeks to inform the FA that it has revoked a Mobile IP registration. Note that configuration of MSAs that involve FAs is substantially more difficult than configuring the one between the MN and HA, because the MN and HA are often in the same administrative domain and the MN will retain the same HA for long periods of time. In contrast, the MN is likely to encounter many FAs over time and may often find itself in foreign administrative domains. The base Mobile IPv4 protocol assumes that MNs are identified by their static home IP addresses and that all MSAs are statically preconfigured. The Diameter Mobile IPv4 application, together with extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 protocol, allows an MN to be dynamically assigned a home address and/or home agent when it attaches to the Internet. This set of specifications also supports the dynamic configuration of the MN-HA, MN-FA, and FA-HA MSAs. The dynamic configuration of these relationships is important to support deployments in which the MN can attach to a visited network without having a pre-established relationship with it. Initially, the MN is assumed to have a long-term AAA security association only with the AAAH. This security association is indexed by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, an algorithm, and a shared secret key. The MN enters a visited network and requests service from some FA by sending a Mobile IPv4 Registration Request. The FA contacts an AAAF in its own administrative domain to authenticate and authorize the request for service. The AAAF and AAAH may establish a Diameter session directly with each other, such as via a Diameter Redirect, or may pass messages via a network of Diameter proxies. Where the AAAF and AAAH route messages to each other through proxies, rather than a direct connection, transitive trust is assumed. MNs can include their Network Access Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI], which serves in place of the home address to identify the MN. The NAI is used to route Diameter messages toward the correct
AAAH. This use of the NAI is consistent with the roaming model defined by the ROAMOPS Working Group [EVALROAM, RFC2607]. The AAAH can authenticate the Registration Request with the use of the MN-AAA security association [MIPCHAL]. If authentication is successful, the AAAH then generates and distributes MSAs to the MN, HA, and FA. For each of the MSA pairs that involve the MN (i.e., MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and then hashes it together with the MN-AAA shared key to derive the session key for the MSA pair. The nonces are sent to the HA that includes them in the Registration Reply, which enables the MN to derive the same keys [MIPKEYS]. At the same time, the AAAH must distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to the FA. These are sent in Diameter AVPs and must be independently secured by using IPSec or TLS between the AAAH and the FA and between the AAAH and the HA. See section 8 for more information on key derivation and distribution. Note that MSAs in Mobile IP are unidirectional in that, for example, the MN-HA MSA (used to protect traffic from the MN to the HA) and the HA-MN MSA (used to protect traffic from the HA to the MN) can use different SPIs, algorithms, and shared secrets. This is true of the base Mobile IP protocol despite common existing practice during manual configuration of MSAs in which all parameters are set to the same value in both directions. This document supports the use of different SPIs in each direction; however, it only supports the distribution of a single session key for each pair of MSAs between two nodes. The security implications of this are discussed in section 13. This document sometimes names only one of the two unidirectional MSAs when referring to the distribution of the single shared secret and the pair of SPIs for the pair of MSAs between two entities.1.3. Handoff
In addition to supporting the derivation and transport of the MN-HA, MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff. When an MN moves from one point of attachment to another, the MN can continue the same Mobile IPv4 session by using its existing HA and home address. The MN accomplishes this by sending a Mobile IPv4 Registration Request from its new point of attachment. To enable a single set of accounting records to be maintained for the entire session, including handoffs, it is necessary to allow the AAAH to bind the new registration to the pre-existing session. To enable the Mobile IPv4 Registration Request to be routed to the same AAAH, the MN SHOULD
include the AAAH NAI [AAANAI] in such re-registrations. Also, to assist the AAAH in routing the messages to the MN's existing HA the mobile node SHOULD include the HA NAI [AAANAI] in such re- registrations. If the mobile node does not support the Mobile IPv4 AAA NAI extension [AAANAI], this functionality is not available.1.4. Structure of the Document
The remainder of this document is structured as follows. Section 2 provides acronym definitions. Section 3 provides some examples and message flows illustrating both the Mobile IPv4 and Diameter messages that occur when a mobile node attaches to the Internet. Section 4 defines the relationship of this application to the Diameter Base Protocol. Section 5 defines the new command codes. Section 6 defines the new result codes used by this application. Section 7 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 gives an overview of the key distribution capability, and Section 9 defines the key distribution AVPs. Section 10 defines the accounting AVPs, and section 11 contains a listing of all AVPs and their occurrence in Diameter commands. Finally, sections 12 and 13 give IANA and security considerations, respectively.2. Acronyms
AAAH Authentication, Authorization, and Accounting Home AAAF Authentication, Authorization, and Accounting Foreign AMA AA-Mobile-Node-Answer AMR AA-Mobile-Node-Request ASR Abort-Session-Request AVP Attribute Value Pair CoA Care-of-Address FA Foreign Agent FQDN Fully Qualified Domain Name HA Home Agent HAA Home-Agent-MIP-Answer HAR Home-Agent-MIP-Request MN Mobile Node MSA Mobility Security Association NAI Network Access Identifier RRQ Registration Request SPI Security Parameters Index STR Session-Termination-Request3. Scenarios and Message Flows
This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
In this document, the role of the "attendant" [MIPREQ] is performed by either the FA (when it is present in a visited network) or the HA (for co-located mobile nodes not registering via an FA), and these terms will be used interchangeably in the following scenarios.3.1. Inter-Realm Mobile IPv4
When a mobile node requests service by issuing a Registration Request to the foreign agent, the foreign agent creates the AA-Mobile-Node- Request (AMR) message, which includes the AVPs defined in section 7. The Home Address, Home Agent, Mobile Node NAI, and other important fields are extracted from the registration messages for possible inclusion as Diameter AVPs. The AMR message is then forwarded to the local Diameter server, known as the AAA-Foreign, or AAAF. Visited Realm Home Realm +-----------+ +-----------+ |example.net| AMR/AMA |example.org| | AAAF |<------------------->| AAAH | +->| server | server-server | server | | +-----------+ communication +-----------+ | ^ ^ | AMR/AMA | client-server | HAR/HAA | | communication | v v v +---------+ +---------+ +---------+ | Foreign | | Foreign | | Home | | Agent | | Agent | | Agent | +---------+ +---------+ +---------+ ^ | 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 | v +--------+ +---------+ | Mobile | Registration | Home | | Node |-------------->| Agent | +--------+ Request +---------+ Figure 7. Co-located Mobile Node If the MN-HA-Key-Requested bit was set in the AMR message from the Home Agent, the home agent and mobile node's session keys would be present in the AMA message. Figure 8 shows a signaling diagram that indicates a secure way to set up the necessary security associations when using redirect servers. The Proxy AAA represents any AAA server or servers that the HA may use. This applies to the visited or home network.
Local redirect HA Proxy AAA Agent AAAH AMR ---------------> AMR (Redirect) --------------------> AMA (Redirect) <--------------------- AMA (Redirect) <---------------- Setup Security Association <------------------------------------------------------> AMR -------------------------------------------------------> AMA (MN-HA key) <------------------------------------------------------- Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA3.4. Key Distribution
To allow the scaling of wireless data access across administrative domains, it is necessary to minimize the number of pre-existing Mobility Security Associations (MSAs) required. This means that each Foreign Agent should not be required to have a pre-configured MSA with each Home Agent on the Internet, nor should the mobile node be required to have a pre-configured MSA (as defined in [MOBILEIP]) with any specific foreign agent. Furthermore, when the mobile node requests a dynamically allocated home agent, it is likely to receive the address of a home agent for which it has no available mobility security association. The Diameter Mobile IPv4 application solves this by including key distribution functionality, which means that after a Mobile Node is authenticated the authorization phase includes the generation of session keys and nonces. Specifically, three session keys and two nonces are generated: - K1: The MN-HA Session Key, which will be part of the MSA between the Mobile Node and the Home Agent. The MN-HA Session Key is derived from a nonce generated by AAA. The mobile node obtains that nonce in the Registration Reply and generates this key using the same formula that AAA uses.
- K2: The MN-FA Key, which will be part of the MSA between the
Mobile Node and the Foreign Agent. The MN-FA Key is derived
from a nonce generated by AAA. The mobile node obtains that
nonce in the Registration Reply and generates the MN-FA key
using the same formula that AAA uses.
- K3: The FA-HA Key, which will be part of the MSA between the
Foreign Agent and the Home Agent.
The same session key is used in both directions between two entities;
e.g., the Mobile Node and the Foreign Agent use the same session key
for the MN-FA and the FA-MN authentication extensions. The security
implications of this are examined in section 13. However, the SPIs
may be different for the MN-FA and the FA-MN authentication
extensions. The SPI for the MN-FA MSA is used on messages sent from
the MN to the FA, and the SPI for the FA-MN MSA is used on messages
sent from the FA to the MN.
All keys and nonces are generated by the AAAH, even if a Home Agent
is dynamically allocated in the foreign network.
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity
using the keys created by the DIAMETER server.
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session
Key and Nonce Distribution
The keys destined for the foreign and home agent are propagated to
the mobility agents via the Diameter protocol. If exposing keys to
the Diameter Agents along the way represents an unacceptable security
risk, then the keys MUST be protected either by IPSec or TLS security
associations that exist directly between the HA and AAAH or the FA
and AAAF, as explained above.
The keys destined for the mobile node MUST also be propagated via the Mobile IPv4 protocol and therefore MUST follow the mechanisms described in [MIPKEYS] instead. In [MIPKEYS], the mobile node receives a nonce for each key it needs, and the mobile node will use the nonce and the long-term shared secret to create the keys (see section 8). Once the session keys have been established and propagated, the mobility devices can exchange registration information directly, as defined in [MOBILEIP], without the need of the Diameter infrastructure. However, the session keys have a lifetime, after which the Diameter infrastructure MUST be invoked again if new session keys and nonces are to be acquired.
(page 20 continued on part 2)
