Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4004

Diameter Mobile IPv4 Application

Pages: 53
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC4004 - Page 1
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
Top   ToC   RFC4004 - Page 2
       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
Top   ToC   RFC4004 - Page 3
       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.
Top   ToC   RFC4004 - Page 4
   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.
Top   ToC   RFC4004 - Page 5
   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
Top   ToC   RFC4004 - Page 6
   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
Top   ToC   RFC4004 - Page 7
   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-Request

3. Scenarios and Message Flows

This section presents four scenarios illustrating Diameter Mobile IPv4 application and describes the operation of key distribution.
Top   ToC   RFC4004 - Page 8
   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.
Top   ToC   RFC4004 - Page 9
   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
Top   ToC   RFC4004 - Page 10
   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).
Top   ToC   RFC4004 - Page 11
                                  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
Top   ToC   RFC4004 - Page 12
   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-
Top   ToC   RFC4004 - Page 13
   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.
Top   ToC   RFC4004 - Page 14
   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.
Top   ToC   RFC4004 - Page 15
                              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.
Top   ToC   RFC4004 - Page 16
   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.
Top   ToC   RFC4004 - Page 17
                                             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.
Top   ToC   RFC4004 - Page 18
                                       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/AMA

3.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.
Top   ToC   RFC4004 - Page 19
     - 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.
Top   ToC   RFC4004 - Page 20
   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)

Next Section