    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

    Calhoun, et al.             Standards Track                     [Page 1]

    RFC 4004                      Diameter MIP                   August 2005

           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

    Calhoun, et al.             Standards Track                     [Page 2]

    RFC 4004                      Diameter MIP                   August 2005

           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.

    Calhoun, et al.             Standards Track                     [Page 3]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                     [Page 4]

    RFC 4004                      Diameter MIP                   August 2005

       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

    Calhoun, et al.             Standards Track                     [Page 5]

    RFC 4004                      Diameter MIP                   August 2005

       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

    Calhoun, et al.             Standards Track                     [Page 6]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                     [Page 7]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                     [Page 8]

    RFC 4004                      Diameter MIP                   August 2005

       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

    Calhoun, et al.             Standards Track                     [Page 9]

    RFC 4004                      Diameter MIP                   August 2005

       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).

    Calhoun, et al.             Standards Track                    [Page 10]

    RFC 4004                      Diameter MIP                   August 2005

                                      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

    Calhoun, et al.             Standards Track                    [Page 11]

    RFC 4004                      Diameter MIP                   August 2005

       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-

    Calhoun, et al.             Standards Track                    [Page 12]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                    [Page 13]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                    [Page 14]

    RFC 4004                      Diameter MIP                   August 2005

                                  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.

    Calhoun, et al.             Standards Track                    [Page 15]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    Calhoun, et al.             Standards Track                    [Page 16]

    RFC 4004                      Diameter MIP                   August 2005

                                                 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.

    Calhoun, et al.             Standards Track                    [Page 17]

    RFC 4004                      Diameter MIP                   August 2005

                                           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.

    Calhoun, et al.             Standards Track                    [Page 18]

    RFC 4004                      Diameter MIP                   August 2005

         - 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.

    Calhoun, et al.             Standards Track                    [Page 19]

    RFC 4004                      Diameter MIP                   August 2005

       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.

    4.  Diameter Protocol Considerations

       This section details the relationship of the Diameter Mobile IPv4
       application to the Diameter base protocol.

       This document specifies Diameter Application-ID 2.  Diameter nodes
       conforming to this specification MAY advertise support by including
       the value of two (2) in the Auth-Application-Id or the Acct-
       Application-Id AVP of the Capabilities-Exchange-Request and
       Capabilities-Exchange-Answer commands [DIAMBASE].  The value of two
       (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA
       commands.  The value of two (2) MUST be used as the Application-Id in
       all ACR/ACA commands, as this application defines new, mandatory AVPs
       for accounting.  The value of zero (0) SHOULD be used as the
       Application-Id in all STR/STA and ASR/ASA commands, as these are
       defined in the Diameter base protocol and no additional mandatory
       AVPs for those commands are defined in this document.

       Given the nature of Mobile IPv4, re-authentication can only be
       initiated by a mobile node, which does not participate in the
       Diameter message exchanges.  Therefore, Diameter server initiated
       re-auth does not apply to this application, and RAR/RAA commands MUST
       NOT be sent for Diameter Mobile IPv4 sessions.

    4.1.  Diameter Session Management

       The AAAH and AAAF MAY maintain session-state or MAY be session-
       stateless.  AAA redirect agents and AAA relay agents MUST NOT
       maintain session-state.  The AAAH, AAAF, proxies and relays agents
       MUST maintain transaction state.

       A mobile node's session is identified via its identity in the User-
       Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent-
       Address AVPs.  This is necessary in order to allow the session state

    Calhoun, et al.             Standards Track                    [Page 20]

    RFC 4004                      Diameter MIP                   August 2005

       machine, defined in the base protocol [DIAMBASE], to be used without
       modification for this application.  However, as the MN may interact
       with more than one FA during the life of its session, it is important
       for the Diameter Mobile IPv4 application to distinguish the two
       pieces of the session (some state at the FA, some state at the HA)
       and to manage them independently.  The following sub-sections give
       further details.

    4.1.1.  Session Identifiers

       During creation of the AMR, the FA will choose a session identifier.
       During the creation of the HAR, the AAAH MUST use a different session
       identifier than that used in the AMR/AMA.  If the AAAH is session-
       stateful, it MUST send the same session identifier for all HARs
       initiated on behalf of a given mobile node's session.  Otherwise, if
       the AAAH is session-stateless, it will manufacture a unique session-
       id for every HAR.

       When the HA is first allocated, it MUST create and include an Acct-
       Multi-Session-Id AVP in the HAA returned to the AAAH.  This
       identifier will be kept constant for the life of the Mobile IPv4
       session, as detailed in the next subsection.

    4.1.2.  Managing Sessions during Mobile IPv4 Handoffs

       Given the nature of Mobile IPv4, a mobile node MAY receive service
       from many foreign agents during a period of time.  However, the home
       realm should not view these handoffs as different sessions, as this
       could affect billing systems.  Furthermore, foreign agents usually do
       not communicate between each other, which implies that AAA
       information cannot be exchanged between these entities.

       A handoff registration request from a mobile node will cause the FA
       to send an AMR to its AAAF.  The AMR will include a new session
       identifier and MAY be sent to a new AAAF (i.e., a AAAF different from
       that used by the previous FA).  However, the AMR shall be received by
       the AAAH to which the user is currently registered (possibly via the
       redirect mechanism depicted in Figure 3).

       As the AAAH may be session-stateless, it is necessary for the
       resulting HAR received by the HA to be identified as a continuation
       of an existing session.  If the HA receives an HAR for a mobile node
       with a new session identifier and the HA can guarantee that this
       request is to extend an existing service, then the HA MUST be able to
       modify its internal session state information to reflect the new
       session identifier.

    Calhoun, et al.             Standards Track                    [Page 21]

    RFC 4004                      Diameter MIP                   August 2005

       For correlation to occur, accounting records must have some
       commonality across handoffs.  Therefore, the home agent MUST send the
       same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's
       session.  That is, the HA generates a unique Acct-Multi-Session-Id
       when receiving an HAR for a new session and returns this same value
       in every HAA for the session.  This Acct-Multi-Session-Id AVP will be
       returned to the foreign agent by the AAAH in the AMA.  Both the
       foreign and home agents MUST include the Acct-Multi-Session-Id in the
       accounting messages, as depicted in Figure 10.

    4.1.3.  Diameter Session Termination

       A foreign and home agent following this specification MAY expect
       their respective Diameter servers to maintain session state
       information for each mobile node in their networks.  For a Diameter
       Server to release any resources allocated to a specific mobile node,
       that server has to receive a Session-Termination-Request (STR) from a
       mobility agent.  The mobility agents MUST issue the Session-
       Termination-Request (STR) if the Authorization Lifetime has expired
       and no subsequent MIP registration request has been received.

       The AAAH SHOULD only deallocate all resources after the STR is
       received from the home agent.  This ensures that a mobile node that
       moves from one foreign agent to another (for example, as a result of
       a handover) does not cause the Home Diameter Server to free all
       resources for the mobile node.  Therefore, an STR from a foreign
       agent would free the session from the foreign agent, but not the
       session state associated with the home agent (see Figure 10).

                  STR, Session-Id = foo       STR, Session-Id = bar
                  --------------------->      <--------------------
             +----+      +------+      +------+                    +----+
             | FA |      | AAAF |      | AAAH |                    | HA |
             +----+      +------+      +------+                    +----+
                  <---------------------      --------------------->
                  STA, Session-Id = foo       STA, Session-Id = bar

                Figure 10.  Session Termination and Session Identifiers

       When deallocating all of the mobile node's resources, the home
       Diameter server (and the foreign Diameter server in the case of an HA
       allocated in foreign network) MUST destroy all session keys that may
       still be valid.

       In the event that the AAAF wishes to terminate a session, its Abort-
       Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA.
       Similarly, the AAAH SHOULD send its message to the Home Agent.

    Calhoun, et al.             Standards Track                    [Page 22]

    RFC 4004                      Diameter MIP                   August 2005

    5.  Command-Code Values

       This section defines Command-Code [DIAMBASE] values that MUST be
       supported by all Diameter implementations conforming to this
       specification.  The following Command Codes are defined in this
       specification:

             Command-Name             Abbreviation    Code       Section
             -----------------------------------------------------------
             AA-Mobile-Node-Request       AMR         260          5.1
             AA-Mobile-Node-Answer        AMA         260          5.2
             Home-Agent-MIP-Request       HAR         262          5.3
             Home-Agent-MIP-Answer        HAA         262          5.4

    5.1.  AA-Mobile-Node-Request

       The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field
       set to 260 and the 'R' bit set in the Command Flags field, is sent by
       an attendant (i.e., the Foreign Agent), acting as a Diameter client,
       to an AAAF in order to request the authentication and authorization
       of a mobile node.  The foreign agent (or home agent in the case of a
       co-located Mobile Node) uses information found in the Registration
       Request to construct the following AVPs, to be included as part of
       the AMR:

                 Home Address (MIP-Mobile-Node-Address AVP)
                 Home Agent Address (MIP-Home-Agent-Address AVP)
                 Mobile Node NAI (User-Name AVP [DIAMBASE])
                 MN-HA Key Request (MIP-Feature-Vector AVP)
                 MN-FA Key Request (MIP-Feature-Vector AVP)
                 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
                 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
                 Home Agent NAI (MIP-Home-Agent-Host AVP)
                 Home AAA server NAI (Destination-Host AVP [DIAMBASE])
                 Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)

       If the mobile node's home address is zero, the foreign or home agent
       MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR.  If the
       home agent address is zero or all ones, the MIP-Home-Agent-Address
       AVP MUST NOT be present in the AMR.

       If a home agent is used in a visited network, the AAAF MAY set the
       Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in
       the AMR message to indicate that it is willing to assign a Home Agent
       in the visited realm.

    Calhoun, et al.             Standards Track                    [Page 23]

    RFC 4004                      Diameter MIP                   August 2005

       If the mobile node's home address is all ones, the foreign or home
       agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.

       If the mobile node includes the home agent NAI and the home AAA
       server NAI [AAANAI], the foreign agent MUST include the MIP-Home-
       Agent-Host AVP and the Destination-Host AVP in the AMR.

          Message Format

             <AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
                                          < Session-ID >
                                          { Auth-Application-Id }
                                          { User-Name }
                                          { Destination-Realm }
                                          { Origin-Host }
                                          { Origin-Realm }
                                          { MIP-Reg-Request }
                                          { MIP-MN-AAA-Auth }
                                          [ Acct-Multi-Session-Id ]
                                          [ Destination-Host ]
                                          [ Origin-State-Id ]
                                          [ MIP-Mobile-Node-Address ]
                                          [ MIP-Home-Agent-Address ]
                                          [ MIP-Feature-Vector ]
                                          [ MIP-Originating-Foreign-AAA ]
                                          [ Authorization-Lifetime ]
                                          [ Auth-Session-State ]
                                          [ MIP-FA-Challenge ]
                                          [ MIP-Candidate-Home-Agent-Host ]
                                          [ MIP-Home-Agent-Host ]
                                          [ MIP-HA-to-FA-SPI ]
                                        * [ Proxy-Info ]
                                        * [ Route-Record ]
                                        * [ AVP ]

    Calhoun, et al.             Standards Track                    [Page 24]

    RFC 4004                      Diameter MIP                   August 2005

    5.2.  AA-Mobile-Node-Answer

       The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field
       set to 260 and the 'R' bit cleared in the Command Flags field, is
       sent by the AAAH in response to the AA-Mobile-Node-Request message.
       The User-Name MAY be included in the AMA if it is present in the AMR.
       The Result-Code AVP MAY contain one of the values defined in section
       6, in addition to the values defined in [DIAMBASE].

       An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
       include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-
       Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if
       the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector
       AVP.  The MIP-Home-Agent-Address AVP contains the Home Agent assigned
       to the mobile node, while the MIP-Mobile-Node-Address AVP contains
       the home address that was assigned.  The AMA message MUST contain the
       MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the
       AMR and were present in the HAR.  The MIP-MN-to-HA-MSA and MIP-HA-
       to-MN-MSA AVPs MUST be present if the session keys were requested in
       the AMR and the Co-Located-Mobile-Node bit was set in the MIP-
       Feature-Vector AVP.

          Message Format

             <AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
                                         < Session-Id >
                                         { Auth-Application-Id }
                                         { Result-Code }
                                         { Origin-Host }
                                         { Origin-Realm }
                                         [ Acct-Multi-Session-Id ]
                                         [ User-Name ]
                                         [ Authorization-Lifetime ]
                                         [ Auth-Session-State ]
                                         [ Error-Message ]
                                         [ Error-Reporting-Host ]
                                         [ Re-Auth-Request-Type ]
                                         [ MIP-Feature-Vector ]
                                         [ MIP-Reg-Reply ]
                                         [ MIP-MN-to-FA-MSA ]
                                         [ MIP-MN-to-HA-MSA ]
                                         [ MIP-FA-to-MN-MSA ]
                                         [ MIP-FA-to-HA-MSA ]
                                         [ MIP-HA-to-MN-MSA ]
                                         [ MIP-MSA-Lifetime ]
                                         [ MIP-Home-Agent-Address ]
                                         [ MIP-Mobile-Node-Address ]
                                       * [ MIP-Filter-Rule ]

    Calhoun, et al.             Standards Track                    [Page 25]

    RFC 4004                      Diameter MIP                   August 2005

                                         [ Origin-State-Id ]
                                       * [ Proxy-Info ]
                                       * [ AVP ]

    5.3.  Home-Agent-MIP-Request

       The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the
       Command-Code field set to 262 and the 'R' bit set in the Command
       Flags field, to the Home Agent.  If the Home Agent is to be assigned
       in a foreign network, the HAR is issued by the AAAH and forwarded by
       the AAAF to the HA if no redirect servers are involved.  If any are,
       the HAR is sent directly to the HA via a security association.  If
       the HAR message does not include a MIP-Mobile-Node-Address AVP, the
       Registration Request has 0.0.0.0 for the home address, and the HAR is
       successfully processed, the Home Agent MUST allocate the mobile nodes
       address.  If, on the other hand, the home agent's local AAA server
       allocates the mobile node's home address, the local AAA server MUST
       include the assigned address in a MIP-Mobile-Node-Address AVP.

       When session keys are requested for use by the mobile node, the AAAH
       MUST create them and include them in the HAR message.  When a FA-HA
       session key is requested, it will be created and distributed by the
       AAAH server.

          Message Format

             <Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
                                          < Session-Id >
                                          { Auth-Application-Id }
                                          { Authorization-Lifetime }
                                          { Auth-Session-State }
                                          { MIP-Reg-Request }
                                          { Origin-Host }
                                          { Origin-Realm }
                                          { User-Name }
                                          { Destination-Realm }
                                          { MIP-Feature-Vector }
                                          [ Destination-Host ]
                                          [ MIP-MN-to-HA-MSA ]
                                          [ MIP-MN-to-FA-MSA ]
                                          [ MIP-HA-to-MN-MSA ]
                                          [ MIP-HA-to-FA-MSA ]
                                          [ MIP-MSA-Lifetime ]
                                          [ MIP-Originating-Foreign-AAA ]
                                          [ MIP-Mobile-Node-Address ]
                                          [ MIP-Home-Agent-Address ]
                                        * [ MIP-Filter-Rule ]
                                          [ Origin-State-Id ]

    Calhoun, et al.             Standards Track                    [Page 26]

    RFC 4004                      Diameter MIP                   August 2005

                                        * [ Proxy-Info ]
                                        * [ Route-Record ]
                                        * [ AVP ]

    5.4.  Home-Agent-MIP-Answer

       In response to a Home-Agent-MIP-Request, the Home Agent sends the
       Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set
       to 262 and the 'R' bit cleared in the Command Flags field, to its
       local AAA server.  The User-Name MAY be included in the HAA if it is
       present in the HAR.  If the home agent allocated a home address for
       the mobile node, the address MUST be included in the MIP-Mobile-
       Node-Address AVP.  The Result-Code AVP MAY contain one of the values
       defined in section 6 instead of the values defined in [DIAMBASE].

          Message Format

             <Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
                                         < Session-Id >
                                         { Auth-Application-Id }
                                         { Result-Code }
                                         { Origin-Host }
                                         { Origin-Realm }
                                         [ Acct-Multi-Session-Id ]
                                         [ User-Name ]
                                         [ Error-Reporting-Host ]
                                         [ Error-Message ]
                                         [ MIP-Reg-Reply ]
                                         [ MIP-Home-Agent-Address ]
                                         [ MIP-Mobile-Node-Address ]
                                         [ MIP-FA-to-HA-SPI ]
                                         [ MIP-FA-to-MN-SPI ]
                                         [ Origin-State-Id ]
                                       * [ Proxy-Info ]
                                       * [ AVP ]

    6.  Result-Code AVP Values

       This section defines new Result-Code [DIAMBASE] values that MUST be
       supported by all Diameter implementations that conform to this
       specification.

    Calhoun, et al.             Standards Track                    [Page 27]

    RFC 4004                      Diameter MIP                   August 2005

    6.1.  Transient Failures

       Errors in the transient failures category are used to inform a peer
       that the request could not be satisfied at the time it was received,
       but that it may be able to satisfy the request in the future.

             DIAMETER_ERROR_MIP_REPLY_FAILURE    4005
                This error code is used by the home agent when processing of
                the Registration Request has failed.

             DIAMETER_ERROR_HA_NOT_AVAILABLE     4006
                This error code is used to inform the foreign agent that the
                requested Home Agent cannot be assigned to the mobile node
                at this time.  The foreign agent MUST return a Mobile IPv4
                Registration Reply to the mobile node with an appropriate
                error code.

             DIAMETER_ERROR_BAD_KEY              4007
                This error code is used by the home agent to indicate to the
                local Diameter server that the key generated is invalid.

             DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED   4008
                This error code is used by a mobility agent to indicate to
                the home Diameter server that the requested packet filter
                Rules cannot be supported.

    6.2.  Permanent Failures

       Errors that fall within the permanent failures category are used to
       inform the peer that the request failed and SHOULD NOT be attempted
       again.

             DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024
                This error is used by the AAAF to inform the AAAH that
                allocation of a home agent in the foreign domain is not
                permitted at this time.

             DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025
                This error is used by the AAAF/AAAH to inform the peer that
                the requested Mobile IPv4 session keys could not be
                delivered via a security association.

    7.  Mandatory AVPs

       The following table describes the Diameter AVPs defined in the Mobile
       IPv4 application; their AVP Code values, types, and possible flag
       values; and whether the AVP MAY be encrypted.

    Calhoun, et al.             Standards Track                    [Page 28]

    RFC 4004                      Diameter MIP                   August 2005

       Due to space constraints, the short form IPFiltrRule is used to
       represent IPFilterRule, and DiamIdent is used to represent
       DiameterIdentity.

                                                +--------------------------+
                                                |    AVP Flag rules        |
                                                |----+-----+----+-----|----+
                       AVP  Section             |    |     |SHLD| MUST|MAY |
       Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
       -----------------------------------------|----+-----+----+-----|----|
       MIP-Reg-Request  320  7.1     OctetString| M  |  P  |    |  V  | Y  |
       MIP-Reg-Reply    321  7.2     OctetString| M  |  P  |    |  V  | Y  |
       MIP-MN-AAA-Auth  322  7.6     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-Mobile-Node- 333  7.3     Address    | M  |  P  |    |  V  | Y  |
         Address
       MIP-Home-Agent-  334  7.4     Address    | M  |  P  |    |  V  | Y  |
         Address
       MIP-Candidate-   336  7.9     DiamIdent  | M  |  P  |    |  V  | N  |
         Home-Agent-Host
       MIP-Feature-     337  7.5     Unsigned32 | M  |  P  |    |  V  | Y  |
         Vector
       MIP-Auth-Input-  338  7.6.2   Unsigned32 | M  |  P  |    |  V  | Y  |
         Data-Length
       MIP-             339  7.6.3   Unsigned32 | M  |  P  |    |  V  | Y  |
         Authenticator-Length
       MIP-             340  7.6.4   Unsigned32 | M  |  P  |    |  V  | Y  |
         Authenticator-Offset
       MIP-MN-AAA-SPI   341  7.6.1   Unsigned32 | M  |  P  |    |  V  | Y  |
       MIP-Filter-Rule  342  7.8     IPFiltrRule| M  |  P  |    |  V  | Y  |
       MIP-FA-Challenge 344  7.7     OctetString| M  |  P  |    |  V  | Y  |

       MIP-Originating- 347  7.10    Grouped    | M  |  P  |    |  V  | Y  |
       Foreign-AAA
       MIP-Home-Agent-  348  7.11    DiamIdent  | M  |  P  |    |  V  | N  |
         Host

    7.1.  MIP-Reg-Request AVP

       The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and
       contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the
       mobile node to the foreign agent.

    7.2.  MIP-Reg-Reply AVP

       The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and
       contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the
       home agent to the foreign agent.

    Calhoun, et al.             Standards Track                    [Page 29]

    RFC 4004                      Diameter MIP                   August 2005

    7.3.  MIP-Mobile-Node-Address AVP

       The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and
       contains the mobile node's home IP address.

    7.4.  MIP-Home-Agent-Address AVP

       The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and
       contains the mobile node's home agent IP address.

    7.5.  MIP-Feature-Vector AVP

       The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
       is added with flag values set by the foreign agent or by the AAAF
       owned by the same administrative domain as the foreign agent.  The
       foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR
       message it sends to the AAAF.

          Flag values currently defined include the following:

                1   Mobile-Node-Home-Address-Requested
                2   Home-Address-Allocatable-Only-in-Home-Realm
                4   Home-Agent-Requested
                8   Foreign-Home-Agent-Available
                16  MN-HA-Key-Request
                32  MN-FA-Key-Request
                64  FA-HA-Key-Request
                128 Home-Agent-In-Foreign-Network
                256 Co-Located-Mobile-Node

       The flags are set according to the following rules.

       If the mobile node includes a valid home address (i.e., one not equal
       to 0.0.0.0 or 255.255.255.255) in its Registration Request, the
       foreign agent sets the Mobile-Node-Home-Address-Requested flag in the
       MIP-Feature-Vector AVP to zero.

       If the mobile node sets the home agent field equal to 255.255.255.255
       in its Registration Request, the foreign agent sets both the Home-
       Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-
       Realm flag to one in the MIP-Feature-Vector AVP.

    Calhoun, et al.             Standards Track                    [Page 30]

    RFC 4004                      Diameter MIP                   August 2005

       If the mobile node sets the home agent field equal to 0.0.0.0 in its
       Registration Request, the foreign agent sets the Home-Agent-Requested
       flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-
       Realm flag in the MIP-Feature-Vector AVP.

       Whenever the foreign agent sets either the
       Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested
       flag to one, it MUST set the MN-HA-Key-Request flag to one.  The MN-
       HA-Key-Request flag is also set to one if the mobile node includes a
       "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension,
       with the subtype set to AAA.

       If the mobile node includes a "Generalized MN-FA Key Generation Nonce
       Request" [MIPKEYS] extension with the AAA subtype (1) in its
       Registration Request, the foreign agent sets the MN-FA-Key-Request
       flag to one in the MIP-Feature-Vector AVP.

       If the mobile node requests a home agent in the foreign network
       either by setting the home address field to all ones, or by
       specifying a home agent in the foreign network, and the AAAF
       authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
       Network bit to one.

       If the AAAF is willing and able to assign a home agent in the foreign
       network, the AAAF sets the Foreign-Home-Agent-Available flag to one.

       If the Home Agent receives a Registration Request from the mobile
       node indicating that the MN is acting as a co-located mobile node,
       the home agent sets the Co-Located-Mobile-Node bit to one.

       If the foreign agent's local policy allows it to receive AAA session
       keys and it does not have any existing FA-HA key with the home agent,
       the foreign agent MAY set the FA-HA-Key-Request flag.

       The foreign agent MUST NOT set the Foreign-Home-Agent-Available and
       Home-Agent-In-Foreign-Network flag both to one.

       When the AAAF receives the AMR message, it MUST first verify that the
       sender was an authorized foreign agent.  The AAAF then takes any
       actions indicated by the settings of the MIP-Feature-Vector AVP
       flags.  The AAAF then MAY set additional flags.  Only the AAAF may
       set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-
       Network flags to one.  This is done according to local administrative
       policy.  When the AAAF has finished setting additional flags
       according to its local policy, then the AAAF transmits the AMR with
       the possibly modified MIP-Feature-Vector AVP to the AAAH.

    Calhoun, et al.             Standards Track                    [Page 31]

    RFC 4004                      Diameter MIP                   August 2005

    7.6.  MIP-MN-AAA-Auth AVP

       The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains
       some ancillary data to simplify processing of the authentication data
       in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the
       target AAA server.  Its value has the following ABNF grammar:

             MIP-MN-AAA-Auth ::= < AVP Header: 322 >
                                 { MIP-MN-AAA-SPI }
                                 { MIP-Auth-Input-Data-Length }
                                 { MIP-Authenticator-Length }
                                 { MIP-Authenticator-Offset }
                               * [ AVP ]

    7.6.1.  MIP-MN-AAA-SPI AVP

       The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
       indicates the MSA by which the targeted AAA server (AAAH) should
       attempt to validate the Authenticator computed by the mobile node
       over the Registration Request data.

    7.6.2.  MIP-Auth-Input-Data-Length AVP

       The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type
       Unsigned32 and contains the length, in bytes, of the Registration
       Request data (data portion of MIP-Reg-Request AVP) that should be
       used as input to the algorithm, as indicated by the MN-AAA-SPI AVP,
       used to determine whether the Authenticator Data supplied by the
       mobile node is valid.

    7.6.3.  MIP-Authenticator-Length AVP

       The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32
       and contains the length of the authenticator to be validated by the
       targeted AAA server (i.e., AAAH).

    7.6.4.  MIP-Authenticator-Offset AVP

       The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32
       and contains the offset into the Registration Request Data, of the
       authenticator to be validated by the targeted AAA server (i.e.,
       AAAH).

    Calhoun, et al.             Standards Track                    [Page 32]

    RFC 4004                      Diameter MIP                   August 2005

    7.7.  MIP-FA-Challenge AVP

       The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and
       contains the challenge advertised by the foreign agent to the mobile
       node.  This AVP MUST be present in the AMR if the mobile node used
       the RADIUS-style MN-AAA computation algorithm [MIPCHAL].

    7.8.  MIP-Filter-Rule AVP

       The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and
       provides filter rules that have to be configured on the foreign or
       home agent for the user.  The packet filtering rules are set by the
       AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if
       destined for the home agent and/or in the AMA if destined for the
       foreign agent.

    7.9.  MIP-Candidate-Home-Agent-Host

       The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type
       DiameterIdentity and contains the identity of a home agent in the
       foreign network that the AAAF proposes to be dynamically assigned to
       the mobile node.

    7.10.  MIP-Originating-Foreign-AAA AVP

       The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped
       and contains the identity of the AAAF, which issues the AMR to the
       AAAH.  The MIP-Originating-Foreign-AAA AVP MUST only be used in cases
       when the home agent is or may be allocated in a foreign domain.  If
       the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH
       MUST copy it into the HAR.

             MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
                                              { Origin-Realm }
                                              { Origin-Host }
                                            * [ AVP ]

    7.11.  MIP-Home-Agent-Host AVP

       The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and
       contains the identity of the assigned Home Agent.  If the MIP-Home-
       Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the
       HAR.

             MIP-Home-Agent-Host ::= < AVP Header: 348 >
                                      { Destination-Realm }
                                      { Destination-Host }
                                    * [ AVP ]

    Calhoun, et al.             Standards Track                    [Page 33]

    RFC 4004                      Diameter MIP                   August 2005

    8.  Key Distribution

       The mobile node and mobility agents use session keys (i.e.,
       the MN-FA, FA-HA, and MN-HA session keys) to compute authentication
       extensions applied to MIP registration messages, as defined in
       [MOBILEIP].  If session keys are requested, the AAAH MUST return the
       keys and nonces after the mobile node is successfully authenticated
       and authorized.

       The SPI values are used as key identifiers, and each session key has
       its own SPI value; nodes that share a key can have multiple different
       SPIs all referring to the same key.  In all cases, the entity that
       receives an authentication extension (i.e., that verifies the
       authentication extension) is providing the entity that sends the
       authentication extension (i.e., that computes the authentication
       extension) the value of the SPI to use for that computation.  Note
       that the keys in this model are symmetric in that they are used in
       both directions, even though the SPIs do not have to be symmetric.

       The mobile node allocates SPIs for use in the FA-MN and HA-MN
       mobility security associations, via the Mobile IPv4 AAA Key Request
       extensions [MIPKEYS].  The home agent allocates SPIs for the MN-HA
       and FA-HA mobility security association.  The foreign agent chooses
       SPIs for the MN-FA and HA-FA mobility security associations.

       Once the session keys and nonces have been distributed, subsequent
       Mobile IPv4 registrations need not invoke the AAA infrastructure
       until the keys expire.  As mandated by Mobile IPv4, these
       registrations MUST include the MN-HA authentication extension.
       Likewise, subsequent registrations MUST also include MN-FA
       authentication extension if the MN-FA session key was generated and
       distributed by AAA.  The same hold true for subsequent use of the
       FA-HA authentication extensions.

    8.1.  Authorization Lifetime vs. MIP Key Lifetime

       The Diameter Mobile IPv4 application makes use of two timers: the
       Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.

       The Authorization-Lifetime contains the number of seconds before the
       mobile node must issue a subsequent MIP registration request.  The
       content of the Authorization-Lifetime AVP corresponds to the Lifetime
       field in the MIP header [MOBILEIP].

       The MIP-MSA-Lifetime AVP contains the number of seconds before
       session keys destined for the mobility agents and the mobile node
       expire.  A value of zero indicates infinity (no timeout).  If not

    Calhoun, et al.             Standards Track                    [Page 34]

    RFC 4004                      Diameter MIP                   August 2005

       zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to
       the value in the Authorization Lifetime AVP.

    8.2.  Nonce vs. Session Key

       As described in section 3.4, the AAAH generates session keys and
       transmits them to the home agent and foreign agent.  The AAAH
       generates nonces that correspond to the same keys and transmits them
       to the mobile node.  When it is necessary to protect the session keys
       and SPIs from un-trusted Diameter agents, end-to-end security
       mechanisms such as TLS or IPSec are required to eliminate all
       Diameter Agents between the FA or HA and the AAAH, as outlined above.

       In [MIPKEYS], the mobility security associations are established via
       nonces transmitted to the mobile node via Mobile IPv4.  To provide
       the nonces, the AAAH must generate a random [RANDOM] value of at
       least 128 bits [MIPKEYS].  The mobile node then uses the nonce to
       derive the MN-HA and MN-FA session keys.

       More details of the MN-HA and the MN-FA session key creation
       procedures are found in [MIPKEYS].

       The hashing algorithm used by the mobile node to construct the
       session key has to be the same as that used by the AAAH in the
       session key generation procedure.  The AAAH therefore indicates the
       algorithm used along with the nonce.

       The FA-HA and HA-FA session key is shared between the FA and HA.  The
       AAAH generates a random [RANDOM] value of at least 128 bits for use
       as this session key.

       See sections 9 for details about the format of the AVPs used to
       transport the session keys.

    8.3.  Distributing the Mobile-Home Session Key

       If the mobile node does not have an MN-HA session key, then the AAAH
       is likely to be the only trusted entity that is available to the
       mobile node.  Thus, the AAAH has to generate the MN-HA session key.

       The distribution of the HA-MN (session) key to the HA is specified in
       sections 1.2 and 3.4.  The HA and AAAH establish a security
       association (IPSec or TLS) and transport the key over it.  If no
       security association exists between the AAAH and the home agent and a
       security association cannot be established, the AAAH MUST return a
       Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.

    Calhoun, et al.             Standards Track                    [Page 35]

    RFC 4004                      Diameter MIP                   August 2005

       The AAAH also has to arrange for the key to be delivered to the
       mobile node.  Unfortunately, the AAAH only knows about Diameter
       messages and AVPs, and the mobile node only knows about Mobile IPv4
       messages and extensions [MOBILEIP].  For this purpose, AAAH includes
       the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added
       to the HAR (for FA COA style Mobile IPv4) or to the AMA (for
       collocated COA-style Mobile IPv4 messages) and delivered either to a
       local home agent or a home agent in the visited network.  Note that
       the mobile node will use the nonce to create the MN-HA session key by
       using the MN-AAA key it shares with the AAAH [MIPKEYS].  The AAAH has
       to rely on the home agent (which also understands Diameter) to
       transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key
       Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply
       message.  The HA includes the SPIs proposed by the mobile node and
       the home agent in the "Generalized MN-HA Key Generation Nonce
       Request" extension.  The home agent can format the Reply message and
       extensions correctly for eventual delivery to the mobile node.  The
       resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP.

       The AAAH parses the HAA message, transforms it into an AMA message
       containing an MIP-Reg-Reply AVP, and sends the AMA message to the
       foreign agent.  The foreign agent then uses that AVP to recreate a
       Registration Reply message containing the "Generalized MN-HA Key
       Generation Nonce Reply" extension for delivery to the mobile node.

       In summary, the AAAH generates the MN-HA nonce, which is added to the
       MIP-MN-to-HA-MSA AVP, and a session key, which is added to the
       MIP-HA-to-MN-MSA AVP.  These AVPs are delivered to the home agent in
       HAR or AMA messages.  The home agent retains the session key for its
       own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a
       "Generalized MN-HA Key Generation Nonce Reply" extension, which is
       appended to the Mobile IPv4 Registration Reply message.  This
       Registration Reply message MUST also include the HA-MN authentication
       extension, which is created by using the newly allocated HA-MN
       session key.  The home agent then includes the Registration Reply
       message and extensions into a MIP-Reg-Reply AVP as part of the HAA
       message to be sent back to the AAA server.

       The key derived by the MN from the MN-HA session nonce is identical
       to the HA-MN session key provided to the HA.

    8.4.  Distributing the Mobile-Foreign Session Key

       The MN-FA session nonce is also generated by AAAH (upon request) and
       added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and
       copied by the home agent into a "Generalized MN-FA Key Generation
       Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration
       Reply message.  The HA also includes the SPIs proposed by the mobile

    Calhoun, et al.             Standards Track                    [Page 36]

    RFC 4004                      Diameter MIP                   August 2005

       node and foreign agent in the "Generalized MN-FA Key Generation Nonce
       Request" extension.  The AAAH includes the FA-MN session key in the
       MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in
       the computation of the FA-MN authentication extension.

       The key derived by the MN from the MN-FA session nonce is identical
       to the FA-MN session key provided to the FA.

    8.5.  Distributing the Foreign-Home Session Key

       If the foreign agent requests an FA-HA session key, it also includes
       a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the
       home agent for this purpose.  The AAAH generates the FA-HA session
       key, which is identical to the HA-FA session key, and distributes
       that to both the HA and the FA over respective security associations
       by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs.  The HA
       conveys the SPI that the FA MUST use in the HAA; this is similar to
       the way in which the FA conveys that the SPI that the HA MUST use in
       the AMR.  The AAAH later includes these SPIs in the MIP-FA-HA-MSA and
       MIP-HA-FA-MSA AVPs, respectively, along with the session key.

       Refer to Figures 2, 3, 4, and 6 for the messages involved.

       Note that if multiple MNs are registered on the same FA and HA pair,
       then multiple mobility security associations would be distributed.
       However, only one is required to protect the Mobile IP control
       traffic between FA and HA.  This creates an unacceptable level of
       state (i.e., to store the two SPIs and shared key for each FA-HA
       mobility security association).  To improve scalability, the FA and
       HA may discard FA-HA mobility security associations prior to the time
       when they actually expire.  However, if a proper discard policy is
       not chosen, this could cause Mobile IP messages in transit or waiting
       in queues for transmission to fail authentication.

       The FA MUST always use the FA-HA security association with the latest
       expiry time when computing authentication extensions on outgoing
       messages.  The FA MAY discard HA-FA mobility security associations 10
       seconds after a new HA-FA mobility security association arrives with
       a later expiry time.

       The HA SHOULD use the HA-FA mobility security association that has
       the latest expiry time when computing authentication extensions in
       outgoing messages.  However, when the HA receives a new HA-FA
       mobility security association with a later expiry time, the HA SHOULD
       wait 4 seconds for the AMA to propagate to the FA before using the
       new association.  Note that the HA always uses the mobility security
       association from the HAR when constructing the Mobile IP Registration
       Reply in the corresponding HAA.  The HA MAY discard an FA-HA mobility

    Calhoun, et al.             Standards Track                    [Page 37]

    RFC 4004                      Diameter MIP                   August 2005

       security association once it receives a message authenticated by a
       FA-HA mobility security association with a later expiry time.

    9.  Key Distribution AVPs

       The Mobile-IP protocol defines a set of mobility security
       associations shared between the mobile node, foreign agent, and home
       agent.  These three mobility security associations (MN-HA, MN-FA, and
       FA-HA) are dynamically created by the AAAH and have previously been
       described in sections 3.4 and 8.  AAA servers supporting the Diameter
       Mobile IP Application MUST implement the key distribution AVPs
       defined in this document.

       The names of the key distribution AVPs indicate the two entities
       sharing the mobility security association.  The first named entity in
       the AVP name will use the mobility security association to create
       authentication extensions using the given SPI and key.  The second
       named entity in the AVP name will use the mobility security
       association to verify the authentication extensions of received
       Mobile IP messages.

       For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce,
       which the mobile node will use to derive the MN-HA Key, and the
       MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent.  Note
       that mobility security associations are unidirectional; however, this
       application delivers only one key that is shared between both
       unidirectional security associations that exist between two peers.
       The security considerations of using the same key in each direction
       are given in section 13.  The SPIs are, however, unique to each
       unidirectional security association and are chosen by the peer that
       will receive the Mobile IP messages authenticated with that security
       association.

       The following table describes the Diameter AVPs defined in the Mobile
       IP application and their AVP Code values, types, and possible flag
       values.

    Calhoun, et al.             Standards Track                    [Page 38]

    RFC 4004                      Diameter MIP                   August 2005

                                                +--------------------------+
                                                |       AVP Flag Rules     |
                                                |----+-----+----+-----|----+
                       AVP  Section             |    |     |SHLD| MUST|MAY |
       Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
       -----------------------------------------|----+-----+----+-----|----|
       MIP-FA-to-HA-SPI 318  9.11    Unsigned32 | M  |  P  |    |  V  | Y  |
       MIP-FA-to-MN-SPI 319  9.10    Unsigned32 | M  |  P  |    |  V  | Y  |
       MIP-HA-to-FA-SPI 323  9.14    Unsigned32 | M  |  P  |    |  V  | Y  |
       MIP-MN-to-FA-MSA 325  9.5     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-FA-to-MN-MSA 326  9.1     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-FA-to-HA-MSA 328  9.2     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-HA-to-FA-MSA 329  9.3     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-MN-to-HA-MSA 331  9.6     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-HA-to-MN-MSA 332  9.4     Grouped    | M  |  P  |    |  V  | Y  |
       MIP-Nonce        335  9.12    OctetString| M  |  P  |    |  V  | Y  |
       MIP-Session-Key  343  9.7     OctetString| M  |  P  |    |  V  | Y  |
       MIP-Algorithm-   345  9.8     Enumerated | M  |  P  |    |  V  | Y  |
         Type
       MIP-Replay-Mode  346  9.9     Enumerated | M  |  P  |    |  V  | Y  |
       MIP-MSA-Lifetime 367  9.13    Unsigned32 | M  |  P  |    |  V  | Y  |

    9.1.  MIP-FA-to-MN-MSA AVP

       The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and
       contains the FA-MN session key.  This AVP is conveyed to the FA in an
       AMA message.  The MN allocates the MIP-FA-to-MN-SPI.  The FA creates
       an FA-MN authentication extension by using the session key and
       algorithm, and the MN verifies that extension by using the same
       session key and algorithm.  The data field of this AVP has the
       following ABNF grammar:

             MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
                                  { MIP-FA-to-MN-SPI }
                                  { MIP-Algorithm-Type }
                                  { MIP-Session-Key }
                                * [ AVP ]

    9.2.  MIP-FA-to-HA-MSA AVP

       The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and
       contains the FA-HA session key.  This AVP is conveyed to the FA in an
       AMA message.  The HA allocates the MIP-FA-to-HA-SPI.  The FA creates
       the FA-HA authentication extension by using the session key and
       algorithm, and the HA verifies that extension by using the same key
       and algorithm.  The AVP's data field has the following ABNF grammar:

    Calhoun, et al.             Standards Track                    [Page 39]

    RFC 4004                      Diameter MIP                   August 2005

             MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
                                  { MIP-FA-to-HA-SPI }
                                  { MIP-Algorithm-Type }
                                  { MIP-Session-Key }
                                * [ AVP ]

    9.3.  MIP-HA-to-FA-MSA AVP

       The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and
       contains the Home Agent's session key, which it shares with the
       foreign agent.  This AVP is conveyed to the HA in an HAR message.
       The FA allocates the MIP-HA-to-FA-SPI.  The HA creates the HA-FA
       authentication extension by using the session key and algorithm, and
       the FA verifies that extension by using the same session key and
       algorithm.  The AVP's data field has the following ABNF grammar:

             MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
                                  { MIP-HA-to-FA-SPI   }
                                  { MIP-Algorithm-Type }
                                  { MIP-Session-Key }
                                * [ AVP ]

    9.4.  MIP-HA-to-MN-MSA AVP

       The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and
       contains the HA-MN session key.  This AVP is conveyed to the HA in an
       HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile
       IPv4.  The MN allocates the MIP-HA-to-MN-SPI.  The HA creates the
       HA-MN authentication extension by using the session key and
       algorithm, and the MN verifies that extension by using the same key
       and algorithm.  The AVP's field has the following ABNF grammar:

             MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
                                  { MIP-HA-to-MN-SPI   }
                                  { MIP-Algorithm-Type }
                                  { MIP-Replay-Mode }
                                  { MIP-Session-Key }
                                * [ AVP ]

    9.5.  MIP-MN-to-FA-MSA AVP

       The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and
       contains the MN-FA session nonce, which the mobile node uses to
       derive the MN-FA session key.  This AVP is conveyed to the HA in an
       HAR message.  The FA allocates the MIP-MN-to-FA-SPI.  The MN creates
       the MN-FA authentication extension by using the session key and
       algorithm, and the FA verifies that extension using the same key and
       algorithm.

    Calhoun, et al.             Standards Track                    [Page 40]

    RFC 4004                      Diameter MIP                   August 2005

       The home agent uses this AVP in the construction of the Mobile IP
       "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].

             MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
                                  { MIP-MN-FA-SPI }
                                  { MIP-Algorithm-Type }
                                  { MIP-nonce }
                                * [ AVP ]

    9.6.  MIP-MN-to-HA-MSA AVP

       The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and
       contains the MN-HA session nonce, which the mobile node uses to
       derive the MN-HA session key.  This AVP is conveyed to the HA in an
       HAR message for FA COA Mobile IPv4 and in an AMR for collocated
       Mobile IPv4.  The HA allocates the MIP-MN-to-HA-SPI.  The MN creates
       the MN-FA authentication extension using the session key and
       algorithm, and the HA verifies that extension using the same session
       key and algorithm.

       The Home Agent uses this AVP in the construction of the Mobile IP
       "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].

             MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
                                  { MIP-MN-HA-SPI }
                                  { MIP-Algorithm-Type }
                                  { MIP-Replay-Mode }
                                  { MIP-nonce }
                                * [ AVP ]

    9.7.  MIP-Session-Key AVP

       The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
       contains the Session Key for the associated Mobile IPv4
       authentication extension.  The HAAA selects the session key.

    9.8.  MIP-Algorithm-Type AVP

       The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and
       contains the Algorithm identifier for the associated Mobile IPv4
       authentication extension.  The HAAA selects the algorithm type.  The
       following values are currently defined:

             2   HMAC-SHA-1 [HMAC]

    Calhoun, et al.             Standards Track                    [Page 41]

    RFC 4004                      Diameter MIP                   August 2005

    9.9.  MIP-Replay-Mode AVP

       The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
       contains the replay mode the Home Agent for authenticating the mobile
       node.  The HAAA selects the replay mode.

       The following values are supported (see [MOBILEIP] for more
       information):

             1   None
             2   Timestamps
             3   Nonces

    9.10.  MIP-FA-to-MN-SPI AVP

       The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it
       contains the Security Parameter Index the FA that and MN use to refer
       to the FA-MN mobility security association.  The MN allocates the
       SPI, and it MUST NOT have a value between zero (0) and 255, which is
       the reserved namespace defined in [MOBILEIP].

    9.11.  MIP-FA-to-HA-SPI AVP

       The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and
       contains the Security Parameter Index the FA and HA use to refer to
       the FA-HA mobility security association.  The HA allocates the SPI,
       and it MUST NOT have a value between zero (0) and 255, which is the
       reserved namespace defined in [MOBILEIP].

    9.12.  MIP-Nonce AVP

       The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains
       the nonce sent to the mobile node for the associated authentication
       extension.  The mobile node follows the procedures in [MIPKEYS] to
       generate the session key used to authenticate Mobile IPv4
       registration messages.  The HAAA selects the nonce.

    9.13.  MIP-MSA-Lifetime AVP

       The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and
       represents the period of time (in seconds) for which the session key
       or nonce is valid.  The associated session key or nonce, as the case
       may be, MUST NOT be used if the lifetime has expired; if the session
       key or nonce lifetime expires while the session to which it applies
       is still active, either the session key or nonce MUST be changed or
       the association Mobile IPv4 session MUST be terminated.

    Calhoun, et al.             Standards Track                    [Page 42]

    RFC 4004                      Diameter MIP                   August 2005

    9.14.  MIP-HA-to-FA-SPI AVP

       The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and
       contains the Security Parameter Index the HA and FA use to refer to
       the HA-FA mobility security association.  The FA allocates the SPI,
       and it MUST NOT have a value between zero (0) and 255, which is the
       reserved namespace defined in [MOBILEIP].

    10.  Accounting AVPs

    10.1.  Accounting-Input-Octets AVP

       The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64,
       and contains the number of octets in IP packets received from the
       user.  This AVP MUST be included in all Accounting-Request messages
       and MAY be present in the corresponding Accounting-Answer messages as
       well.

    10.2.  Accounting-Output-Octets AVP

       The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
       and contains the number of octets in IP packets sent to the user.
       This AVP MUST be included in all Accounting-Request messages and MAY
       be present in the corresponding Accounting-Answer messages as well.

    10.3.  Acct-Session-Time AVP

       The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates
       the length of the current session in seconds.  This AVP MUST be
       included in all Accounting-Request messages and MAY be present in the
       corresponding Accounting-Answer messages as well.

    10.4.  Accounting-Input-Packets AVP

       The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and
       contains the number of IP packets received from the user.  This AVP
       MUST be included in all Accounting-Request messages and MAY be
       present in the corresponding Accounting-Answer messages as well.

    10.5.  Accounting-Output-Packets AVP

       The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64
       and contains the number of IP packets sent to the user.  This AVP
       MUST be included in all Accounting-Request messages and MAY be
       present in the corresponding Accounting-Answer messages as well.

    Calhoun, et al.             Standards Track                    [Page 43]

    RFC 4004                      Diameter MIP                   August 2005

    10.6.  Event-Timestamp AVP

       The Event-Timestamp (AVP Code 55) is of type Time and MAY be included
       in an Accounting-Request message to record the time at which this
       event occurred on the mobility agent, in seconds since January 1,
       1970, 00:00 UTC.

    11.  AVP Occurrence Tables

       The following tables present the AVPs defined in this document and
       their occurrences in Diameter messages.  Note that AVPs that can only
       be present within a Grouped AVP are not represented in this table.

       The table uses the following symbols:

             0      The AVP MUST NOT be present in the message.
             0+     Zero or more instances of the AVP MAY be present in the
                    message.
             0 - 1  Zero or one instance of the AVP MAY be present in the
                    message.
             1      One instance of the AVP MUST be present in the message.

    11.1.  Mobile IP Command AVP Table

       The table in this section is limited to the Command Codes defined in
       this specification.

                                        +-----------------------+
                                        |      Command-Code     |
                                        |-----+-----+-----+-----+
          Attribute Name                | AMR | AMA | HAR | HAA |
          ------------------------------|-----+-----+-----+-----+
          Authorization-Lifetime        | 0-1 | 0-1 | 1   | 0   |
          Auth-Application-Id           | 1   | 1   | 1   | 1   |
          Auth-Session-State            | 0-1 | 0-1 | 1   | 0   |
          Acct-Multi-Session-Id         | 0-1 | 0-1 | 0   | 0-1 |
          Destination-Host              | 0-1 | 0   | 0-1 | 0   |
          Destination-Realm             | 1   | 0   | 1   | 0   |
          Error-Message                 | 0   | 0-1 | 0   | 0-1 |
          Error-Reporting-Host          | 0   | 0-1 | 0   | 0-1 |
          MIP-Candidate-Home-Agent-Host | 0-1 | 0   | 0-1 | 0   |
          MIP-Home-Agent-Host           | 0-1 | 0   | 0-1 | 0   |
          MIP-Originating-Foreign-AAA   | 0-1 | 0   | 0-1 | 0   |
          MIP-FA-Challenge              | 0-1 | 0   | 0   | 0   |
          MIP-FA-to-MN-MSA              | 0   | 0-1 | 0   | 0   |
          MIP-FA-to-HA-MSA              | 0   | 0-1 | 0   | 0   |
          MIP-HA-to-FA-MSA              | 0   | 0   | 0-1 | 0   |
          MIP-HA-to-MN-MSA              | 0   | 0-1 | 0-1 | 0   |

    Calhoun, et al.             Standards Track                    [Page 44]

    RFC 4004                      Diameter MIP                   August 2005

          MIP-MN-to-FA-MSA              | 0   | 0   | 0-1 | 0   |
          MIP-MN-to-HA-MSA              | 0   | 0-1 | 0-1 | 0   |
          MIP-FA-to-HA-SPI              | 0   | 0   | 0   | 0-1 |
          MIP-HA-to-FA-SPI              | 0   | 0   | 0   | 0-1 |

          MIP-FA-to-MN-SPI              | 0   | 0   | 0   | 0-1 |
          MIP-MN-to-FA-SPI              | 0   | 0   | 0   | 0-1 |

          MIP-HA-to-MN-SPI              | 0   | 0   | 0   | 0-1 |
          MIP-MN-to-HA-SPI              | 0   | 0   | 0   | 0-1 |
          MIP-Feature-Vector            | 0-1 | 0-1 | 1   | 0   |
          MIP-Filter-Rule               | 0   | 0+  | 0+  | 0   |
          MIP-Home-Agent-Address        | 0-1 | 0-1 | 0-1 | 0-1 |
          MIP-MSA-Lifetime              | 0   | 0-1 | 0-1 | 0   |
          MIP-MN-AAA-Auth               | 1   | 0   | 0   | 0   |
          MIP-Mobile-Node-Address       | 0-1 | 0-1 | 0-1 | 0-1 |
          MIP-Reg-Reply                 | 0   | 0-1 | 0   | 0-1 |
          MIP-Reg-Request               | 1   | 0   | 1   | 0   |
          Origin-Host                   | 1   | 1   | 1   | 1   |
          Origin-Realm                  | 1   | 1   | 1   | 1   |
          Origin-State-Id               | 0-1 | 0-1 | 0-1 | 0-1 |
          Proxy-Info                    | 0+  | 0+  | 0+  | 0+  |
          Redirect-Host                 | 0   | 0+  | 0   | 0+  |
          Redirect-Host-Usage           | 0   | 0-1 | 0   | 0-1 |
          Redirect-Max-Cache-Time       | 0   | 0-1 | 0   | 0-1 |
          Result-Code                   | 0   | 1   | 0   | 1   |
          Re-Auth-Request-Type          | 0   | 0-1 | 0   | 0   |
          Route-Record                  | 0+  | 0   | 0+  | 0   |
          Session-Id                    | 1   | 1   | 1   | 1   |
          User-Name                     | 1   | 0-1 | 1   | 0-1 |
          ------------------------------|-----+-----+-----+-----|

    Calhoun, et al.             Standards Track                    [Page 45]

    RFC 4004                      Diameter MIP                   August 2005

    11.2.  Accounting AVP Table

       The table in this section is used to represent which AVPs defined in
       this document are to be present in the Accounting messages, as
       defined in [DIAMBASE].

                                               +-------------+
                                               | Command-Code|
                                               |------+------+
          Attribute Name                       |  ACR |  ACA |
          -------------------------------------|------+------+
          Accounting-Input-Octets              |  1   |  0-1 |
          Accounting-Input-Packets             |  1   |  0-1 |
          Accounting-Output-Octets             |  1   |  0-1 |
          Accounting-Output-Packets            |  1   |  0-1 |
          Acct-Multi-Session-Id                |  1   |  0-1 |
          Acct-Session-Time                    |  1   |  0-1 |
          MIP-Feature-Vector                   |  1   |  0-1 |
          MIP-Home-Agent-Address               |  1   |  0-1 |
          MIP-Mobile-Node-Address              |  1   |  0-1 |
          Event-Timestamp                      | 0-1  |   0  |
          -------------------------------------|------+------+

    12.  IANA Considerations

       This section contains the namespaces that have either been created in
       this specification or had their values assigned to existing
       namespaces managed by IANA.

    12.1.  Command Codes

       This specification assigns the values 260 and 262 from the Command
       Code namespace defined in [DIAMBASE].  See section 5 for the
       assignment of the namespace in this specification.

    12.2.  AVP Codes

       This specification assigns the values 318 - 348 and 363 - 367 from
       the AVP Code namespace defined in [DIAMBASE].  See sections 7, 9, and
       10 for the assignment of the namespace in this specification.

    12.3.  Result-Code AVP Values

       This specification assigns the values 4005 - 4008 and 5024 - 5025
       from the Result-Code AVP (AVP Code 268) value namespace defined in
       [DIAMBASE].  See section 6 for the assignment of the namespace in
       this specification.

    Calhoun, et al.             Standards Track                    [Page 46]

    RFC 4004                      Diameter MIP                   August 2005

    12.4.  MIP-Feature-Vector AVP Values

       There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that
       are available for assignment.  This document assigns bits 1 - 9, as
       listed in section 7.5.  The remaining bits should only be assigned
       via Standards Action [IANA].

    12.5.  MIP-Algorithm-Type AVP Values

       As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345)
       defines the value 2.  All remaining values, except zero, are
       available for assignment via Designated Expert [IANA].

    12.6.  MIP-Replay-Mode AVP Values

       As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346)
       defines the values 1 - 3.  All remaining values, except zero, are
       available for assignment via Designated Expert [IANA].

    12.7.  Application Identifier

       This specification uses the value two (2) to the Application
       Identifier namespace defined in [DIAMBASE].  See section 4 for more
       information.

    13.  Security Considerations

       This specification describes a Mobile IPv4 Diameter Application for
       authenticating and authorizing a Mobile IPv4 mobile node.  The
       authentication algorithm used is dependent on the transforms used
       within the Mobile IPv4 protocol, and [MIPCHAL].  This specification,
       in conjunction with [MIPKEYS], also defines a method by which the
       home Diameter server can create and distribute session keys and
       nonces for use in authenticating and integrity-protecting Mobile IPv4
       registration messages [MOBILEIP].  The key distribution is
       asymmetric, as communication with the mobile node occurs via the
       Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to
       the Home Agent and Foreign Agent occurs via the Diameter protocol.
       Where untrusted Diameter agents are present, end-to-end security MUST
       be used.  The end-to-end security takes the form of TLS or IPSec
       security associations between the AAAH and the FA and between the
       AAAH and the HA.  These connections will be authenticated with the
       use of public keys and certificates; however, the identities that
       appear in the certificates must be authorized and bound to a
       particular Mobile IPv4 Diameter session before the AAAH can safely
       begin distribution of keys.

    Calhoun, et al.             Standards Track                    [Page 47]

    RFC 4004                      Diameter MIP                   August 2005

       Note that the direct connections are established as a result of
       Diameter redirect messages.  For example, in Figure 3, the FA gets a
       redirect response containing the Redirect-Host AVP of the AAAH.  This
       is the identity that should be matched against the certificate
       presented by the AAAH when the secure connection is established.  In
       this case, the network of Diameter proxies and redirect agents is
       trusted with the task of returning the correct AAAH identity to the
       FA.

       The AAAH must also make an authorization decision when the FA
       establishes the connection.  If the AAAH and the redirect server are
       one and the same, then the AAAH may have observed and noted the
       original AMR message that contained the identity of the FA and so may
       authorize the establishment of a TLS or IPSec connection from the
       same entity.  Otherwise, the AAAH would need to maintain a list of
       all authorized visited domains (roaming partners) and authorize TLS
       or IPSec connections based on this list.  Note that establishment of
       the connection is only the first step, and the AAAH has another
       opportunity to deny service upon receipt of the AMR message itself.
       At this step, the AAAH can check the internal AVPs of the AMR to
       ensure that the FA is valid; for example, it can check that the
       Mobile IP COA is equal to the IP address used as the endpoint of the
       TLS or IPSec connection.  However, such a policy would prevent the FA
       from using different interfaces for AAA and Mobile IP tunnel packets
       and may not be desirable in every deployment situation.

       A similar set of considerations applies to the connection between
       AAAH and HA when those entities are in different administrative
       domains.  However, here the roles are reversed because it is the AAAH
       that contacts the HA via the HAR.  The identity of the candidate HA
       is given to the AAAH in the AMR, and the AAAH should expect to
       receive the same identity in the public key certificates during TLS
       or IPSec negotiation.  The HA may authorize individual connections by
       acting as its own redirect server, or it may maintain a list of
       trusted roaming partners.

       This application creates and distributes a single session key for
       each pair of MSAs between two entities; e.g., the same session key is
       used for the MN-HA MSA and the HA-MN MSA.  This is safe to do from a
       security perspective, as the session keys are only used with keyed
       hash functions to generate authenticator values that protect the
       integrity of each Mobile IP control message.  Mobile IP messages have
       built-in replay protection with the use of timestamps or nonces
       [MOBILEIP], and, due to the nature of the protocol, requests are
       always different bitwise from responses, at least in the message type
       code.  This avoids problems that might arise in other situations

    Calhoun, et al.             Standards Track                    [Page 48]

    RFC 4004                      Diameter MIP                   August 2005

       where an attacker could mount a replay or reflection attack if the
       same key were used (for example) to encrypt otherwise unprotected
       traffic on more than one connection leg in the network.

       Nonces are sent to the mobile node, which are used to generate the
       session keys via the HMAC-SHA-1 one-way function.  Because the nonces
       and authentication extensions may be observed by anyone with access
       to a clear-text copy of the Registration Reply, the pre-shared key
       between the mobile node and the home Diameter server would be
       vulnerable to an offline dictionary attack if it did not contain
       enough entropy.  To prevent this, the pre-shared key between the
       mobile node and the home Diameter server SHOULD be a randomly chosen
       quantity of at least 96 bits.

       Because the session key is determined by the long-term secret and the
       nonce, the nonce SHOULD be temporally and globally unique; if the
       nonce were to repeat, then so would the session key.  To prevent
       this, a nonce is strongly recommended to be a random [RANDOM] value
       of at least 128 bits.  The long-term secret between the MN and AAAH
       MUST be refreshed periodically, to guard against recovery of the
       long-term secret due to nonce reuse or other factors.  This is
       accomplished by using out-of-band mechanisms, which are not specified
       in this document.

       Note that it is not recommended to set the MIP-MSA-Lifetime AVP value
       to zero, as keeping session keys for a long time (no refresh)
       increases the level of vulnerability.

    14.  References

    14.1.  Normative References

       [ABNF]         Crocker, D. and P. Overell, "Augmented BNF for Syntax
                      Specifications: ABNF", RFC 2234, November 1997.

       [DIAMBASE]     Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                      J. Arkko, "Diameter Base Protocol", RFC 3588,
                      September 2003.

       [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
                      an IANA Considerations Section in RFCs", BCP 26, RFC
                      2434, October 1998.

       [MOBILEIP]     Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
                      August 2002.

    Calhoun, et al.             Standards Track                    [Page 49]

    RFC 4004                      Diameter MIP                   August 2005

       [MIPCHAL]      Perkins, C. and P. Calhoun, "Mobile IPv4
                      Challenge/Response Extensions", RFC 3012, November
                      2000.

       [NAI]          Aboba, B. and M. Beadles, "The Network Access
                      Identifier", RFC 2486, January 1999.

       [HMAC]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                      Keyed-Hashing for Message Authentication", RFC 2104,
                      February 1997.

       [MIPKEYS]      Perkins, C. and P. Calhoun, "Authentication,
                      Authorization, and Accounting (AAA) Registration Keys
                      for Mobile IP", RFC 3957, March 2005.

       [AAANAI]       Johansson, F. and T. Johansson, "Mobile IPv4 Extension
                      for Carrying Network Access Identifiers", RFC 3846,
                      June 2004.

       [IPSEC]        Kent, S. and R. Atkinson, "Security Architecture for
                      the Internet Protocol", RFC 2401, November 1998.

       [TLS]          Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
                      J., and T. Wright, "Transport Layer Security (TLS)
                      Extensions", RFC 3546, June 2003.

       [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
                      Requirement Levels", BCP 14, RFC 2119, March 1997.

    14.2.  Informative References

       [MIPREQ]       Glass, S., Hiller, T., Jacobs, S., and C. Perkins,
                      "Mobile IP Authentication, Authorization, and
                      Accounting Requirements", RFC 2977, October 2000.

       [CDMA2000]     Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety,
                      G., Sivalingham, S., Lim, B., McCann, P., Shiino, H.,
                      Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford,
                      M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu,
                      Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed,
                      "CDMA2000 Wireless Data Requirements for AAA", RFC
                      3141, June 2001.

       [EVALROAM]     Aboba, B. and G. Zorn, "Criteria for Evaluating
                      Roaming Protocols", RFC 2477, January 1999.

       [MIPNAI]       Calhoun, P. and C. Perkins, "Mobile IP Network Access
                      Identifier Extension for IPv4", RFC 2794, March 2000.

    Calhoun, et al.             Standards Track                    [Page 50]

    RFC 4004                      Diameter MIP                   August 2005

       [RANDOM]       Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                      "Randomness Requirements for Security", BCP 106, RFC
                      4086, June 2005.

    15.  Acknowledgements

       The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and
       Pankaj Patel for their participation in the pre-IETF Document Reading
       Party; Erik Guttman for his very useful proposed text; and to Fredrik
       Johansson, Martin Julien, and Bob Kopacz for their very useful
       contributed text.

       The authors would also like to thank the participants of 3GPP2's
       TSG-X working group for their valuable feedback, and the following
       people for their contribution in the development of the protocol:
       Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael
       Chen, Henry Haverinen, and Johan Johansson.  General redirect server
       text due to Pasi Eronen was borrowed from Diameter-EAP.

       Pat Calhoun would like to thank Sun Microsystems, as most of the
       effort put into this document was done while he was in their employ.

    Authors' Addresses

       Questions about this memo can be directed to:

       Pat Calhoun
       Cisco Systems, Inc.
       170 West Tasman Drive
       San Jose, CA 95134
       USA

       Phone: +1 408-853-5269
       EMail: pcalhoun@cisco.com

       Tony Johansson
       Bytemobile, Inc.
       2029 Stierlin Court
       Mountain View, CA 94043

       Phone: +1 650-641-7817
       Fax:   +1 650-641-7701
       EMail: tony.johansson@bytemobile.com

    Calhoun, et al.             Standards Track                    [Page 51]

    RFC 4004                      Diameter MIP                   August 2005

       Charles E. Perkins
       Nokia Research Center
       313 Fairchild Drive
       Mountain View, CA 94043
       USA

       Phone: +1 650-625-2986
       Fax:   +1 650-625-2502
       EMail: Charles.Perkins@nokia.com

       Tom Hiller
       Lucent Technologies
       1960 Lucent Lane
       Naperville, IL 60566
       USA

       Phone: +1 630-979-7673
       EMail: tomhiller@lucent.com

       Peter J. McCann
       Lucent Technologies
       1960 Lucent Lane
       Naperville, IL 60563
       USA

       Phone: +1 630-713-9359
       Fax:   +1 630-713-1921
       EMail: mccap@lucent.com

    Calhoun, et al.             Standards Track                    [Page 52]

    RFC 4004                      Diameter MIP                   August 2005

    Full Copyright Statement

       Copyright (C) The Internet Society (2005).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

       This document and the information contained herein are provided on an
       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
       OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
       ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
       INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
       INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
       WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be claimed to
       pertain to the implementation or use of the technology described in
       this document or the extent to which any license under such rights
       might or might not be available; nor does it represent that it has
       made any independent effort to identify any such rights.  Information
       on the procedures with respect to rights in RFC documents can be
       found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the use of
       such proprietary rights by implementers or users of this
       specification can be obtained from the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that may be required to implement
       this standard.  Please address the information to the IETF at ietf-
       ipr@ietf.org.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Calhoun, et al.             Standards Track                    [Page 53]