AAA Working Group                                         Pat R. Calhoun
Internet-Draft                                                 Airespace
Category: Standards Track                                 Tony Johansson
<draft-ietf-aaa-diameter-mobileip-14.txt>                 Bytemobile Inc
                                                      Charles E. Perkins
                                                   Nokia Research Center
                                                              April 2003



                     Diameter Mobile IP Application


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 2003.  All Rights Reserved.

Abstract

   This document specifies a Diameter application that allows a Diameter
   server to authenticate, authorize and collect accounting information
   for Mobile IP 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.




Calhoun et al.            expires October 2003                  [Page 1]


Internet-Draft                                                April 2003


Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Inter-Realm Mobile IP
            1.3  Support for Mobile IP Handoffs
            1.4  Allocation of Home Agent in Foreign Network
            1.5  Co-located Mobile Node
            1.6  Key Distribution Center (KDC)
            1.7  Diameter Session Termination
            1.8  Advertising Application support
            1.9  Fast Handoff support
            1.10  IP filter rule support
      2.0  Command-Code Values
            2.1  AA-Mobile-Node-Request
            2.2  AA-Mobile-Node-Answer
            2.3  Home-Agent-MIP-Request
            2.4  Home-Agent-MIP-Answer
      3.0  Result-Code AVP Values
            3.1  Transient Failures
            3.2  Permanent Failures
      4.0  Diameter AVPs
            4.1  MIP-Reg-Request AVP
            4.2  MIP-Reg-Reply AVP
            4.3  MIP-Mobile-Node-Address AVP
            4.4  MIP-Home-Agent-Address AVP
            4.5  MIP-Feature-Vector AVP
            4.6  MIP-MN-AAA-Auth AVP
                  4.6.1  MIP-MN-AAA-SPI AVP
                  4.6.2  MIP-Auth-Input-Data-Length AVP
                  4.6.3  MIP-Authenticator-Length AVP
                  4.6.4  MIP-Authenticator-Offset AVP
            4.7  MIP-FA-Challenge AVP
            4.8  MIP-Filter-Rule AVP
            4.9  MIP-Candidate-Home-Agent-Host
            4.10 MIP-Originating-Foreign-AAA AVP
            4.11 MIP-Home-Agent-Host AVP
      5.0  Key Distribution Center
            5.1  Authorization Lifetime vs. MIP Key Lifetime
            5.2  Key Material vs. Session Key
            5.3  Distributing the Mobile-Home Session Key
            5.4  Distributing the Mobile-Foreign Session Key
            5.5  Distributing the Foreign-Home Session Key
            5.6  Key Distribution Example
      6.0  Key Distribution Center (KDC) AVPs
            6.1  MIP-FA-to-MN-Key AVP
            6.2  MIP-FA-to-HA-Key AVP
            6.3  MIP-HA-to-FA-Key AVP



Calhoun et al.            expires October 2003                  [Page 2]


Internet-Draft                                                April 2003


            6.4  MIP-HA-to-MN-Key AVP
            6.5  MIP-MN-to-FA-Key AVP
            6.6  MIP-MN-to-HA-Key AVP
            6.7  MIP-Session-Key AVP
            6.8  MIP-Algorithm-Type AVP
            6.9  MIP-Replay-Mode AVP
            6.10 MIP-FA-to-MN-SPI
            6.11 MIP-FA-to-HA-SPI
            6.12 MIP-Key-Material AVP
            6.13 MIP-Key-Lifetime AVP
      7.0  Accounting AVPs
            7.1  Accounting-Input-Octets AVP
            7.2  Accounting-Output-Octets AVP
            7.3  Acct-Session-Time AVP
            7.4  Accounting-Input-Packets AVP
            7.5  Accounting-Output-Packets AVP
            7.6  Event-Timestamp AVP
      8.0  AVP Table
            8.1  Mobile IP Command AVP Table
            8.2  Accounting AVP Table
      9.0  IANA Considerations
            9.1  Command Codes
            9.2  AVP Codes
            9.3  Result-Code AVP Values
            9.4  MIP-Feature-Vector AVP Values
            9.5  MIP-Algorithm-Type AVP Values
            9.6  MIP-Replay-Mode AVP Values
            9.7  Application Identifier
      10.0 Security Considerations
      11.0 References
            11.1  Normative
            11.2  Informative
      12.0  Acknowledgements
      13.0  Authors' Addresses
      14.0  Full Copyright Statement
      15.0  Intellectual Property Considerations















Calhoun et al.            expires October 2003                  [Page 3]


Internet-Draft                                                April 2003


1.0  Introduction

   Mobile IP, as defined in [MOBILEIP], defines a method that allows a
   mobile node to change its point of attachment to the Internet with
   minimal service disruption. Mobile IP does not provide any specific
   support for mobility across disparate administrative domains, and
   therefore does not specify how usage can be accounted for, which has
   limited the applicability of Mobile IP in a IPv4 commercial
   deployment.  The Mobile IP specification as defined in [MOBILEIP]
   recommends mobile nodes to have a static home address and a home
   agent. However this may not be always possible in certain deployment
   scenarios. Recent developments in areas that impact IP mobility in
   the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile
   nodes do not have a static home agent and home address. In addition,
   another specification [MIPNAI] allows a mobile node to use its NAI
   instead of its home address, which better accommodates current
   administrative practice.

   This document specifies Application-ID 4 to the Diameter base
   protocol [DIAMBASE] that allows a Diameter server to authenticate,
   authorize and collect accounting information for Mobile IP services
   rendered to a mobile node. This application MUST NOT be used in
   conjunction with the Mobile IPv6 protocol.

   Combined with the Inter-Realm capability of the Diameter base
   protocol, this application allows mobile nodes to receive service
   from foreign service providers. The Diameter Accounting messages will
   be used by the foreign and home agents to transfer usage information
   to the Diameter servers.

   The Mobile IP protocol [MOBILEIP] specifies a security model that
   requires that mobile nodes and home agents share a pre-existing
   security association, which leads to scaling and configuration
   issues. This specification defines Diameter functions that allow the
   AAA server to act as a Key Distribution Center (KDC), whereby dynamic
   session keys are created and distributed to the mobility entities for
   the purposes of securing Mobile IP Registration messages.














Calhoun et al.            expires October 2003                  [Page 4]


Internet-Draft                                                April 2003


   Strong authentication and confidentiality of session keys is
   required, and it is recommended to be provided using the CMS security
   application [CMS], but may be provided via other security mechanisms,
   e.g. using mutually authenticated TLS or IPsec, when deployed in an
   environment without Diameter agents, then hop-by-hop security is
   sufficient for protecting session keys. (It should be noted that the
   CMS security application is referenced as informative in this
   application and the usage is only a recommendation.) However, if a
   home AAA server is explicitly configured to need the CMS security
   application for this domain/transaction then it will not proceed
   without it, that is, the requested service MUST fail if CMS isn't
   available.

   As with the Diameter base protocol, AAA servers implementing the
   Mobile IP application can process users' identities supplied in a
   Network Access Identifier (NAI) format [NAI], which is used for
   Diameter message routing purposes.  Mobile nodes include their NAI in
   Registration messages, as defined in [MIPNAI]. The use of the NAI is
   consistent with the roaming model defined by the ROAMOPS Working
   Group [EVALROAM].

   A home AAA server (AAAH) and foreign AAA server (AAAF), which support
   the Mobile-IP authentication application 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.

   Given the nature of Mobile IP, a 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.

   Furthermore, the nature of Mobile IP also means that the mobile node
   will do handoffs between different foreign agents. To guarantee that
   a registered user always ends up in the same initial AAAH, the mobile
   node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist
   the AAAH in routing the messages to a mobile node's home agent the
   mobile node SHOULD always include the HA NAI [AAANAI]. If the mobile
   node does not support the Mobile IP AAA NAI extension [AAANAI], this
   MAY limit the functionality that can be offered to such a mobile
   node.

   The Diameter Mobile-IP Application meets the requirements specified
   in [MIPREQ, CDMA2000]. Later subsections in this introductory section
   provide some examples and message flows of the Mobile IP and Diameter
   messages that occur when a mobile node requests service in a foreign
   network. In this document, the role of the "attendant" [MIPREQ] is
   performed by either the home agents (for co-located mobile nodes) or



Calhoun et al.            expires October 2003                  [Page 5]


Internet-Draft                                                April 2003


   foreign agents for the Mobile-IP Application, and these terms will be
   used interchangeably.


1.1  Requirements language

   In this document, the key words "MAY", "MUST", "MUST NOT",
   "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
   interpreted as described in [KEYWORDS].

1.2  Inter-Realm Mobile IP

   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
   2.1.  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
                     +--------+                     +--------+
                     |abc.com |       AMR/AMA       |xyz.com |
                     |  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@xyz.com
                           +--------+
                      Figure 1: Inter-Realm Mobility


   Upon receiving the AMR, the AAAF follows the procedures outlined in



Calhoun et al.            expires October 2003                  [Page 6]


Internet-Draft                                                April 2003


   [DIAMBASE] to determine whether the AMR should be processed locally,
   or if it should be forwarded to another Diameter server, known as the
   AAA-Home, or AAAH.  Figure 1 shows an example in which a mobile node
   (mn@xyz.com) requests service from a foreign provider (abc.com). The
   request received by the AAAF is forwarded to xyz.com's AAAH server.

   Figure 2 shows the message flows involved when the foreign agent
   invokes the AAA infrastructure to request that a mobile node be
   authenticated and authorized. Note that it is not required that the
   foreign agent invoke AAA services every time a Registration Request
   is received from the mobile, but rather only when the prior
   authorization from the AAAH expires. The expiration time of the
   authorization is communicated through the Authorization-Lifetime AVP
   in the AA-Mobile-Node-Answer (AMA, see section 2.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 IP/Diameter Message Exchange

   The foreign agent (as shown in Figure 2) MAY provide a challenge,
   which gives it direct control over the replay protection in the
   Mobile IP registration process, as described in [MIPCHAL].  The
   mobile node includes the Challenge and MN-AAA authentication



Calhoun et al.            expires October 2003                  [Page 7]


Internet-Draft                                                April 2003


   extension to enable authorization by AAAH. If the authentication data
   supplied in the MN-AAA extension is invalid, AAAH returns the
   response (AMA) with the Result-Code AVP set to
   DIAMETER_AUTHENTICATION_REJECTED.

   A mobile node with AAA NAI extension support [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. So, 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, since the FA
   may not know the identity of the AAAH.

   If the mobile node was successfully authenticated, the AAAH checks if
   the home agent was located in the foreign realm, by checking Home-
   Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other
   AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating-
   Foreign-AAA AVP may also be used to verify the location of the home
   agent. If the home agent is located in the foreign realm, then the
   AAAH sends an HAR message to the home agent, which contains a MIP-
   Reg-Request AVP.

   If the home agent was not located in the foreign realm, the AAAH
   checks for the MIP-Home-Agent-Address AVP and if present the MIP-
   Home-Agent-Host AVP. If one was specified, the AAAH checks that the
   address is that of a known home agent and that the mobile node is
   allowed to request this particular home agent, and that the home
   agent's identity is included in the MIP-Home-Agent-Host AVP. If no
   home agent was specified, and if the MIP-Feature-Vector has the Home-
   Agent-Requested flag set, and if allowed by policy in the home realm,
   the AAAH SHOULD allocate a home agent on behalf of the mobile node.
   This can be done in a variety of ways, including using a load
   balancing algorithm in order to keep the load on all home agents
   equal. The actual algorithm used and the method of discovering the
   home agents is outside the scope of this specification.

   The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains
   the Mobile IP Registration Request message data encapsulated in the
   MIP-Reg-Request AVP, to the assigned or requested Home Agent. The



Calhoun et al.            expires October 2003                  [Page 8]


Internet-Draft                                                April 2003


   AAAH MAY allocate a home address for the mobile node, while the Home
   Agent MUST support home address allocation. In the event the AAAH
   handles address allocation, it includes it in a MIP-Mobile-Node-
   Address AVP within the HAR.  The absence of this AVP informs the Home
   Agent to perform the allocation.

   During the creation of the HAR, the AAAH MUST use a different session
   identifier than the one used in the AMR/AMA (see Figure 2). 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.

   A mobile node's session is identified via its identity in the User-
   Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address
   AVPs. This is necessary in order to allow the session state machine,
   defined in the base protocol [DIAMBASE], to be used unmodified with
   this application. Therefore, an STR from a foreign agent would free
   the session from the foreign agent, but not the one towards the home
   agent (see figure 3).

           STR, Session-Id = foo       STR, Session-Id = bar
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           STA, Session-Id = foo       STA, Session-Id = bar
            Figure 3: Session Termination and Session Identifiers

   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 within the MIP-Mobile-Node-Address
   AVP.

   The HA MUST include an Acct-Multi-Session-Id AVP in the HAA returned
   to the AAAH.









Calhoun et al.            expires October 2003                  [Page 9]


Internet-Draft                                                April 2003


   Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
   (AMA) message, includes the Acct-Multi-Session-Id that was present in
   the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs
   in the AMA message.

1.3  Support for Mobile IP Handoffs

   Given the nature of Mobile IP, 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, since this
   could affect billing systems. Furthermore, many foreign agents do not
   communicate, which makes it quite difficult for AAA information to be
   exchanged between these entities. Therefore, it MUST be assumed that
   a foreign agent is not aware that a registration request from a
   mobile node has been previously authorized.

   A handoff registration request from a mobile node will cause an AMR
   to be sent to its AAAF. The AMR will include a new session
   identifier, and MAY be sent to an AAAF in the visited network other
   than the AAAF, which received the previous AMR. However, with the
   usage of the AAA NAI, this AMR is guaranteed to be received by the
   AAAH to which the user is currently registered.

   Since 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 service for an existing service, then the HA
   MUST be able to modify its internal session state information to
   reflect the new session identifier.

   It is necessary for accounting records to have some commonality
   across handoffs in order for correlation to occur.  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.











Calhoun et al.            expires October 2003                 [Page 10]


Internet-Draft                                                April 2003


           ACR, Session-Id = foo         ACR, Session-Id = bar
           Acct-Multi-Session-Id = a     Acct-Multi-Session-Id = a
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           ACA, Session-Id = foo       ACA, Session-Id = bar

            Figure 4: Accounting messages w/ Mobile IP Application


1.4  Allocation of Home Agent in Foreign Network

   The Diameter Mobile IP 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 equal
   to 255.255.255.255, then the foreign agent also 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 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 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 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.


   In the event that the mobile node with AAA NAI extension support
   [AAANAI] has been previously authorized by the AAAH and now needs 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, 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.            expires October 2003                 [Page 11]


Internet-Draft                                                April 2003


   In the event that the mobile node that does not support the AAA NAI
   extension has been previously authorized by the AAAH and now needs to
   be re-authenticated, and requests to keep the assigned home agent in
   the foreign network, the mobile node sends a registration request
   without the AAA NAI and the HA NAI. 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 has
   knowledge that the requested home 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
   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 a Home
   Agent in the foreign network or to keep the Home Agent in the foreign
   network. If so, and after checking authorization from the data in the
   AMR message, the AAAH sends the 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
   the HA has been previously allocated and authorized by the AAAH. If
   the HA has not been previously allocated by the foreign domain, the
   HAR sent by the AAAH does not contain the MIP-Home-Agent-Address.

   If the AAAH's local policy determines that the generated session keys
   must be encrypted to protect against untrusted intermediate Diameter
   agent(s) between the visited and the home realm, the AAAH will make
   use of the CMS application [CMS] to establish a security association.
   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. Otherwise, upon
   completion of the security association, 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 are copied into the HAR.

   If the AAAH's local policy determines that session keys can be
   encrypted using mechanisms defined in [DIAMBASE] as in Figure 5, the
   HAR is sent by the AAAH back to the foreign realm with the
   Destination-Host AVP set to the home agent's identity. This HAR may
   not necessarily be received by the same AAAF, which sent the AMR.



Calhoun et al.            expires October 2003                 [Page 12]


Internet-Draft                                                April 2003


   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 use the MIP-Originating-
   Foreign-AAA AVP for policy decisions, such as determining if the FA-
   HA Key should be encrypted or not.

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


















Calhoun et al.            expires October 2003                 [Page 13]


Internet-Draft                                                April 2003


   Mobile Node   Foreign Agent    Home Agent        AAAF         AAAH
   -----------   -------------  -------------   ----------    ----------

      <----Challenge----
    Reg-Req (Response)->
                         ------------AMR------------->
                                                     -----AMR---->
                                                     <----HAR-----
                                      <-----HAR------
                                      ------HAA------>

                                                     -----HAA---->
                                                     <----AMA-----
                       <-------------AMA------------
       <---Reg-Reply----
   Figure 6: Mobile IP/Diameter Message Exchange when 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 mobile node will
   have to be serviced by two AAAFs.

   Figure 7 shows the message flows for a mobile node requesting to keep
   the home agent assigned in foreign network 1 when it moves to foreign
   network 2. Upon reception of the AMR in foreign network 2, the AAAF
   follows the procedures described earlier and forwards AMR to the
   mobile node's home network, i.e. its AAAH. If the mobile node was
   successfully authenticated, the AAAH checks the identity of the
   foreign and home agent to determine whether the user is in a third
   realm. If this is the case, the AAAH must check whether the mobile is
   still permitted to use the previously assigned home agent.


















Calhoun et al.            expires October 2003                 [Page 14]


Internet-Draft                                                April 2003


                   +---------------+ +---------------+ +-------------+
                   |Foreign net 2  | |Foreign net 1  | |Home network |
                   |               | |               | |             |
      Mobile Node  |  FA      AAAF | |  HA     AAAF  | |    AAAH     |
      -----------  | ----     ---- | | ----   ------ | |   ------    |
                   +---------------+ +---------------+ +-------------+

      <----Challenge----
      Reg-Req (Response)->
                       ---AMR--->
                                ----------------AMR--------------->
                                                     <-----HAR-----
                                        <---HAR----
                                        ----HAA--->
                                                     ------HAA---->
                                <---------------AMA----------------
                       <--AMA----
       <----Reg-Reply-----
      Figure 7: Request to access Home Agent from new foreign network

   If the mobile node is allowed to keep the home agent the AAAH then
   sends a HAR, which contains the Mobile IP Registration Request
   message data encapsulated in the MIP-Reg-Request AVP and the MIP-
   Home-Agent-Address AVP with home agent address, as well as any
   optional KDC session keys, to the AAAF in foreign network 1.
   Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA
   AVP from AMR and include it in the HAR when a third foreign domain is
   involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP
   for policy decisions, such as determining if the FA-HA Key keys can
   be encrypted using mechanisms defined in [DIAMBASE] or not, see
   further details in section 5.5. Upon reception the AAAF in foreign
   network 1 will forward the HAR to the Home Agent if its local policy
   allows such service. If the AAAF does not permit such service, it
   MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

   If the AAAH's local policy determines that the MN-HA keys must be
   encrypted to protect against untrusted intermediate Diameter agent(s)
   between the foreign network 1 realm and the home realm, the AAAH will
   make use of the CMS application [CMS]. If no security association is
   known to the home agent, the AAAH MUST send the HAR to the AAAF in
   foreign network 1, which originally assigned the HA in foreign
   network 1, by including its identity in the Destination-Host AVP.

   When the AAAF receives a HAA, the AAAF will forward the HAA back to
   the AAAH.  If successful, the HAA MUST include the MIP-Home-Agent-
   Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send
   back an AMA to the AAAF in foreign network 2.




Calhoun et al.            expires October 2003                 [Page 15]


Internet-Draft                                                April 2003


   If the old foreign network does not permit the use of its Home Agent
   when the mobile node moves to a new foreign network, the AAAH or AAAF
   MUST return an AMA with the Result-Code AVP set to
   DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
   foreign agent MUST issue a Mobile IP Registration Reply to the mobile
   node with an appropriate error. The mobile node MAY attempt to
   request that a new Home Agent and Address be allocated. When the AAAH
   transmits such an error, it MUST issue a Diameter Abort-Session-
   Request message to the Home Agent to enable it to release any
   resources.

1.5  Co-located Mobile Node

   In the event that a mobile node registers with the Home Agent as a
   co-located mobile node, there is no foreign agent 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 in the AMR sent to the
   AAAH, as the AAAH may find this a useful piece of session-state or
   log entry information.

                                          Home
                                         Realm
                                       +--------+
                                       |  AAAH  |
                                       |        |
                                       | server |
                                       +--------+
                                         ^  |
                                         |  |
                                     AMR |  | AMA
                                         |  v
             +--------+               +---------+
             | Mobile | Registration  |  Home   |
             | Node   |-------------->|  Agent  |
             +--------+    Request    +---------+
                     Figure 8: 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.


1.6  Key Distribution Center (KDC)

   In order to allow the scaling of wireless data access across
   administrative domains, it is necessary to minimize the specific



Calhoun et al.            expires October 2003                 [Page 16]


Internet-Draft                                                April 2003


   security associations required. This means that each Foreign Agent
   should not be required have a pre-configured shared security
   association with each Home Agent on the Internet, nor should the
   mobile node be required to have a pre-configured shared security
   association with any specific home agent or any specific foreign
   agent, as defined in [MOBILEIP].

   Diameter Mobile IP application solves this by including a key
   distribution center (KDC), which means that after a Mobile Node is
   authenticated, the authorization phase includes the generation of
   sessions keys.  Specifically, three keys are generated and are
   required by [MOBILEIP]:

  - K1 - the MN-HA Key, which will work as security association between
          the Mobile Node and the Home Agent.
  - K2 - the MN-FA Key, which will work as the security association
          between the Mobile Node and the Foreign Agent
  - K3 - the FA-HA Key, which will work as the security association
          between the Foreign Agent and the Home Agent

   Figure 9 depicts the new security associations used for Mobile-IP
   message integrity using the keys derived by the DIAMETER server.

                   +--------+                      +--------+
                   |Foreign |          K3          | Home   |
                   |Agent   |<-------------------->| Agent  |
                   |        |                      |        |
                   +--------+                      +--------+
                           ^                        ^
                           | K2                  K1 |
                           |       +--------+       |
                           |       | Mobile |       |
                           +------>| Node   |<------+
                                   |        |
                                   +--------+
          Figure 9 - Security Association after Key Distribution

   If the home agent is assigned in the home network, each key is
   generated and encrypted by the home Diameter server. If instead the
   home agent is assigned in the foreign network the K3 key is generated
   and encrypted by the foreign network's local Diameter server, while
   the K1 and K2 is still generated and encrypted by the home Diameter
   server.

   The keys destined for the foreign and home agent are propagated to
   the mobility nodes via the Diameter protocol, and the keys must be
   encrypted either by IPSec or TLS when deployed in an environment
   without Diameter agents.  When deployed in an environment with



Calhoun et al.            expires October 2003                 [Page 17]


Internet-Draft                                                April 2003


   Diameter agents, the keys must be encrypted by means described in
   [CMS].

   The keys destined for the mobile node must also be propagated via the
   Mobile IP protocol and must therefore instead follow the mechanisms
   described in [MIPKEYS]]. This means that the keys distributed to the
   mobile node are instead sent as a nonce (or key material as it is
   called in [MIPKEYS]), and the mobile node and the home Diameter will
   use the nonce and the long term shared secret to create the keys (see
   section 5.2).

   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 to acquire
   new session keys.


1.7  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. In order for the
   Diameter Server to release any resources allocated to a specific
   mobile node, the mobility agents MUST send a Session-Termination-
   Request (STR) to the Diameter server that authorized the service. The
   Session-Termination-Request (STR) MUST be issued by the mobility
   agents if the Authorization Lifetime has expired and no subsequent
   MIP registration request have been received.

   The home Diameter server 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 (hand-off) does not
   cause the Home Diameter Server to free all resources for the mobile
   node.

   When deallocating all of the mobile node's resources the home
   Diameter server (and the foreign Diameter server in case of 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.            expires October 2003                 [Page 18]


Internet-Draft                                                April 2003


1.8  Advertising application support

   Diameter nodes conforming to this specification MAY advertise support
   by including the value of four (4) in the Auth-Application-Id or the
   Acct-Application-Id AVP of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer command [DIAMBASE].


1.9  Fast Handoff support

   This application requires that foreign agents issue an AMR upon
   receipt of the first registration message from a mobile node,
   regardless of the fact that the mobile node MAY have been previously
   authorized to another foreign agent.

   The Mobile IP Working Group is currently investigating fast handoff
   proposals, and the Seamoby WG is looking at creating a protocol that
   would allow AAA state information to be exchange between foreign
   agents during a handoff. These proposals MAY allow future
   enhancements to the Diameter protocol, in order to reduce the amount
   of Diameter exchanges required during a handoff.






























Calhoun et al.            expires October 2003                 [Page 19]


Internet-Draft                                                April 2003


1.10  IP filter rule support

   This application has support for pushing filter rules to either of
   the mobility agents to enable appropriate restrictions for the mobile
   node, such as limiting the mobile nodes access due to roaming
   agreements or network protection. The filter 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. The filer rules does only apply to the mobile node in
   the HAR and/or AMA message, thus the mobility agents will process the
   filter rules individually for each mobile node.



   If MIP-Filter-Rule AVPs are included in the HAR and the home agent
   does not have support to handle filter rules, the home agent MUST
   return a HAA with Result-Code AVP equal to
   DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED.

   If the MIP-Filter-Rule AVPs are included in the AMA and the foreign
   agent does not have support to handle filter rules, the foreign agent
   SHOULD log the event and MUST issue a Session-Termination-Request
   (STR) back to its local Diameter server.

2.0  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-Answer        AMA         260          2.2
      AA-Mobile-Node-Request       AMR         260          2.1
      Home-Agent-MIP-Answer        HAA         262          2.4
      Home-Agent-MIP-Request       HAR         262          2.3


2.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, acting as a Diameter client, to a server 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 that are to be included as part of the AMR:



Calhoun et al.            expires October 2003                 [Page 20]


Internet-Draft                                                April 2003


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

   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.

   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.

























Calhoun et al.            expires October 2003                 [Page 21]


Internet-Draft                                                April 2003


   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 ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]
                                 * [ AVP ]


2.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 present in the AMR. The
   Result-Code AVP MAY contain one of the values defined in section 3.0,
   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-Key, MIP-FA-to-MN-Key if they were requested in the AMR,
   and they were present in the HAR. The MIP-MN-to-HA-Key and MIP-HA-to-
   MN-Key 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-



Calhoun et al.            expires October 2003                 [Page 22]


Internet-Draft                                                April 2003


   Vector AVP.

   An AMA message with the Result-Code AVP set to
   DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP
   if a dynamically assigned home

   agent was requested by the mobile node. Upon receipt of this result
   code, the foreign agent MUST issue the Registration Request to the
   Home Agent in the manner described in [MOBILEIP].

   An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH
   MAY include mobile node session key AVPs (see Section 6.1) such as
   the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP
   is present in the AMA message, the foreign agent MUST include the
   corresponding Mobile IP key distribution extension in the
   Registration Reply it sends to the mobile node. This is to support
   multi-roundtrip authentication mechanisms.


































Calhoun et al.            expires October 2003                 [Page 23]


Internet-Draft                                                April 2003


   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-Key ]
                                  [ MIP-MN-to-HA-Key ]
                                  [ MIP-FA-to-MN-Key ]
                                  [ MIP-FA-to-HA-Key ]
                                  [ MIP-HA-to-MN-Key ]
                                  [ MIP-HA-to-FA-Key ]
                                  [ MIP-Key-Lifetime ]
                                  [ MIP-Home-Agent-Address ]
                                  [ MIP-Mobile-Node-Address ]
                                * [ MIP-Filter-Rule ]
                                  [ Origin-State-Id ]
                                * [ Proxy-Info ]
                                * [ AVP ]


2.3  Home-Agent-MIP-Request

   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, is sent by
   the AAA 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. If the HAR message does not include a MIP-Mobile-Node-Address
   AVP, and 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 an MIP-Mobile-Node-
   Address AVP.

   When session keys are requested for use by the mobile node (see
   section 5.0), the AAAH MUST create them and include them in the HAR



Calhoun et al.            expires October 2003                 [Page 24]


Internet-Draft                                                April 2003


   message.  When a Foreign-Home session key is requested, it will be
   created and distributed by the AAA server in the same realm as the
   home agent.

   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-Key ]
                                   [ MIP-MN-to-FA-Key ]
                                   [ MIP-HA-to-MN-Key ]
                                   [ MIP-HA-to-FA-Key ]
                                   [ MIP-Key-Lifetime ]
                                   [ MIP-Originating-Foreign-AAA ]
                                   [ MIP-Mobile-Node-Address ]
                                   [ MIP-Home-Agent-Address ]
                                 * [ MIP-Filter-Rule ]
                                   [ Origin-State-Id ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]
                                 * [ AVP ]


2.4  Home-Agent-MIP-Answer

   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, is
   sent by the Home Agent to its local AAA server in response to a Home-
   Agent-MIP-Request. The User-Name MAY be included in the HAA if
   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 3.0 instead of the values defined in [DIAMBASE].








Calhoun et al.            expires October 2003                 [Page 25]


Internet-Draft                                                April 2003


   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 ]


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


3.1  Transient Failures

   Errors that fall within the transient failures category are used to
   inform a peer that the request could not be satisfied at the time it
   was received, but 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 IP
         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



Calhoun et al.            expires October 2003                 [Page 26]


Internet-Draft                                                April 2003


         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.

3.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 that the
         requested Mobile IP session keys could not be encrypted with
         the CMS strong security application and therefore failed.


4.0  Mandatory AVPs

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

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

















Calhoun et al.            expires October 2003                 [Page 27]


Internet-Draft                                                April 2003


                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+

                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Filter-Rule  342  4.8     IPFiltrRule| M  |  P  |    |  V  | Y  |
   MIP-Auth-Input-  338  4.6.2   Unsigned32 | M  |  P  |    |  V  | Y  |
     Data-Length                            |    |     |    |     |    |
   MIP-             339  4.6.3   Unsigned32 | M  |  P  |    |  V  | Y  |
     Authenticator-Length                   |    |     |    |     |    |
   MIP-             340  4.6.4   Unsigned32 | M  |  P  |    |  V  | Y  |
     Authenticator-Offset                   |    |     |    |     |    |
   MIP-Candidate-   336  4.9     DiamIdent  | M  |  P  |    |  V  | N  |
     Home-Agent-Host                        |    |     |    |     |    |
   MIP-Home-Agent-  348  4.11    DiamIdent  | M  |  P  |    |  V  | N  |
     Host                                   |    |     |    |     |    |
   MIP-FA-Challenge 344  4.7     OctetString| M  |  P  |    |  V  | Y  |
   MIP-Feature-     337  4.5     Unsigned32 | M  |  P  |    |  V  | Y  |
     Vector                                 |    |     |    |     |    |
   MIP-Home-Agent-  334  4.4     Address    | M  |  P  |    |  V  | Y  |
     Address                                |    |     |    |     |    |
   MIP-MN-AAA-Auth  322  4.6     Grouped    | M  |  P  |    |  V  | Y  |
   MIP-MN-AAA-SPI   341  4.6.1   Unsigned32 | M  |  P  |    |  V  | Y  |
   MIP-Mobile-Node- 333  4.3     Address    | M  |  P  |    |  V  | Y  |
     Address                                |    |     |    |     |    |
   MIP-Reg-Request  320  4.1     OctetString| M  |  P  |    |  V  | Y  |
   MIP-Reg-Reply    321  4.2     OctetString| M  |  P  |    |  V  | Y  |
   MIP-Originating- 347  4.10    Grouped    | M  |  P  |    |  V  | Y  |
   Foreign-AAA                              |    |     |    |     |    |

4.1  MIP-Reg-Request AVP

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


4.2  MIP-Reg-Reply AVP

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

4.3  MIP-Mobile-Node-Address AVP

   The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and



Calhoun et al.            expires October 2003                 [Page 28]


Internet-Draft                                                April 2003


   contains the mobile node's home IP address.


4.4  MIP-Home-Agent-Address AVP

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


4.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:
         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., not equal to
   0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign
   agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP-
   Feature-Vector AVP.

   If the mobile node sets the home address field equal to 0.0.0.0 in
   its Registration Request, the foreign agent sets the Mobile-Node-
   Home-Address-Requested flag to one.

   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.

   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.



Calhoun et al.            expires October 2003                 [Page 29]


Internet-Draft                                                April 2003


   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
   Request [MIPKEYS] extension, with the subtype set to AAA.

   If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS]
   extension with the AAA subtype 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 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 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.


4.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 IP 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 }



Calhoun et al.            expires October 2003                 [Page 30]


Internet-Draft                                                April 2003


                          { MIP-Auth-Input-Data-Length }
                          { MIP-Authenticator-Length }
                          { MIP-Authenticator-Offset }
                        * [ AVP ]

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


4.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 (indicated by the MN-AAA-SPI AVP) used
   to determine whether the Authenticator Data supplied by the mobile
   node is valid.


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


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


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








Calhoun et al.            expires October 2003                 [Page 31]


Internet-Draft                                                April 2003


4.8  MIP-Filter-Rule AVP


   The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and
   provides filter rules that need 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.

4.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 be dynamically assigned to the
   mobile node.


4.10 MIP-Originating-Foreign-AAA AVP

   The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if 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 present in the AMR, the AAAH MUST copy the MIP-
   Originating-Foreign-AAA AVP into the HAR.

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

4.11 MIP-Home-Agent-Host AVP

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

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









Calhoun et al.            expires October 2003                 [Page 32]


Internet-Draft                                                April 2003


5.0  Key Distribution Center

   The mobile node and mobility agents use session keys to compute
   authentication extensions applied to registration messages, as
   defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home.
   If session keys are requested the AAA server(s) MUST return the key
   material after the mobile node is successfully authenticated and
   authorized.

   The SPI values are used as key identifiers, meaning that each session
   key has its own SPI value; nodes that share a key also share an SPI.
   The mobile node proposes SPIs for use in computing the Mobile-Foreign
   and Mobile-Home authentication extensions, via the Mobile IP AAA Key
   Request extensions [MIPKEYS], while the home agent allocates the
   Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.

   Once the session keys have been distributed, subsequent Mobile IP
   registrations need not invoke the AAA infrastructure until the keys
   expire.  These registrations MUST include the Mobile-Home
   authentication extension.  In addition, subsequent registrations MUST
   also include Mobile-Foreign authentication extension if the Mobile-
   Foreign key was generated and distributed by AAA; similarly for
   subsequent use of the Foreign-Home authentication extensions.


5.1 Authorization Lifetime vs. MIP Key Lifetime

   The Diameter Mobile IP application makes use of two timers - the
   Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-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-Key-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 zero,
   the value of the MIP-Key-Lifetime AVP MUST be at least equal to the
   value in the Authorization Lifetime AVP.



5.2  Key Material vs. Session Key


   As described in section 1.6, session keys and nonces are generated by
   the AAAH and are transmitted to the home agent, foreign agent and



Calhoun et al.            expires October 2003                 [Page 33]


Internet-Draft                                                April 2003


   mobile node. Security associations destined for the home and foreign
   agents are established via transmission of session keys and SPIs,
   protected by transmission-level security as defined in [DIAMBASE].
   Where it is necessary to protect the nonces, session keys and SPIs
   from untrusted Diameter agents, end-to-end security mechanisms are
   required, such as the CMS application [CMS], a work in progress.

   The mobile node security associations are established via nonces
   transmitted to the mobile node via Mobile IP. 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
   procedure are found in [MIPKEYS]. Recommended hashing algorithms to
   be use are HMAC-MD5 and HMAC SHA1, where HMAC-MD5 MUST be supported
   [MIPKEYS]. Below follows an example, copied from [MIPKEYS], of the
   key creation procedure using the HMAC-MD5 hashing algorithm. The
   hashing algorithm is used to enable session keys to be derived from
   the long term shared secret and the nonce. The same procedure is used
   by the AAAH for creation of the session keys sent to the home and
   foreign agent.

      key = HMAC-MD5(AAA-key,{Key Material | node-address})

      Where:

         - AAA-Key is the pre-shared key between the mobile node and the
           AAAH.
         - Key material (nonce) is a random [RANDOM] value of at least
           128 bits.
         - node-address is the mobile node's identity. This is the
           contents of the MIP-Mobile-Node-Address AVP, unless the value
           of the AVP is all zero or ones, in which case of value of the
           User-Name AVP is used instead.


   It is important that the hashing algorithm used by the mobile node to
   construct the session key is the same as the one used by the AAAH in
   the session key generation procedure. The AAAH therefore indicates
   the algorithm used along with the key material.

   The Foreign-Home session key is shared between two mobility agents:
   the FA and HA. Since this key is not destined for the mobile node,
   there is no need to follow the session key generation procedures
   detailed above. Instead, the AAAH generates a random [RANDOM] value
   of at least 128 bits for use as the Foreign-Home session key.




Calhoun et al.            expires October 2003                 [Page 34]


Internet-Draft                                                April 2003


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


5.3  Distributing the Mobile-Home Session Key

   If the mobile node does not have a Mobile-Home session key, then the
   AAAH is likely to be the only entity trusted that is available to the
   mobile node.  Thus, the AAAH has to generate the Mobile-Home session
   key, and encode it for eventual consumption by the mobile node and
   home agent.

   If the home agent is in the home realm, then the AAAH can directly
   encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and
   include that AVP in the HAR message for delivery to the home agent.

   If, on the other hand, the home agent is to be allocated in the
   visited realm, the AAAH transmits the HAR to the foreign home agent,
   where, prior to delivery to the home agent, it is perused by the AAAF
   hosting the home agent. If the session key needs to be encrypted the
   AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP
   with help of CMS security application [CMS] using the security
   association with the AAAF associated with the home agent. If no
   security association exists between the AAAH and the AAAF associated
   with the home agent, the AAAH will check if a security association
   can be established. If no security association exists and cannot be
   created, the AAAH MUST return a Result-Code AVP with
   DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.

   The AAAH also has to arrange for the key to be delivered to the
   mobile node. Unfortunately, the AAA server only knows about Diameter
   messages and AVPs, and the mobile node only knows about Mobile IP
   messages and extensions [MOBILEIP].  For this purpose, AAAH encodes
   the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP,
   using its security association with the mobile node, which is added
   to the HAR message, and delivered either to a local home agent, or to
   the AAAF in the case where the home agent is in the visited network.
   The AAAH has to rely on the home agent (that also understands
   Diameter) to transfer the keying information into a Mobile IP
   Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration
   Reply message, using the SPI proposed by the Mobile Node in the MN-HA
   Key Request From AAA Subtype 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.

   After the HAA message is parsed by the AAAH, and transformed into an
   AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually



Calhoun et al.            expires October 2003                 [Page 35]


Internet-Draft                                                April 2003


   be received by the the foreign agent. The foreign agent can then use
   that AVP to recreate a Registration Reply message, containing the
   Generalized MN-HA Key Reply extension, for delivery to the mobile
   node.

   In summary, the AAAH generates the Mobile-Home key material, which is
   added to the MIP-MN-to-HA-Key AVP. The key material is then used to
   compute the home agent's session key as specified in [MIPKEYS], which
   is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered
   to a home agent by including them in a HAR message sent from either
   AAAH or AAAF. The home agent decodes the key for its own use. The
   home agent also copies the encoded key material from the MIP-MN-to-
   HA-Key AVP into a Generalized MN-HA Key Reply extension appended to
   the Mobile IP Registration Reply message. This Registration Reply
   message MUST also include the Mobile-Home authentication extension,
   created using the newly allocated Mobile-Home session key. The home
   agent then encodes the Registration Reply message and extensions into
   a MIP-Reg-Reply AVP included as part of the HAA message to be sent
   back to the AAA server.


5.4  Distributing the Mobile-Foreign Session Key

   The Mobile-Foreign session key material is also generated by AAAH
   (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is
   added to the HAR, and copied by the home agent into a Generalized MN-
   FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply
   message, using the SPI proposed by the mobile node in the MN-FA Key
   Request From AAA Subtype extension. Further, the home agent includes
   the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the
   session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains
   the session key used by the foreign agent in the computation of the
   Mobile-Foreign authentication extension.

   If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent
   MUST include the Mobile-Foreign authentication extension in the
   Registration Reply, using the newly distributed key.


5.5  Distributing the Foreign-Home Session Key

   If the home agent is in the home realm, then the AAAH has to generate
   the Foreign-Home session key. Otherwise, it is generated by the AAAF.


5.5.1 Home Agent in the home network

   In the cases when the AAAH generates the Foreign-Home session key,



Calhoun et al.            expires October 2003                 [Page 36]


Internet-Draft                                                April 2003


   the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and
   includes the AVP as part of the HAR message sent to the home agent.
   The corresponding session key and algorithm that is to be sent to the
   foreign agent is cached in the AAAH until the HAA is received.

   Upon receipt of the HAR, the home agent recovers the Foreign-Home
   session key, allocates an SPI to be used with the key. The allocated
   SPI is included in the HAA's MIP-FA-to-HA SPI AVP.

   Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP,
   using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the
   AMA.


5.5.2 Home Agent in foreign network

   In the cases when the AAAF generates the Foreign-Home session key
   (home agent in foreign domain), the AAAF will, upon receipt of the
   HAR message, generate the Foreign-Home session key and include the
   session key in the MIP-HA-to-FA-Key AVP as part of the HAR message
   forwarded to the home agent. The corresponding session key and
   algorithm that is to be sent to the foreign agent is cached in the
   AAAF until the HAA is received.

   Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP,
   using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the
   Foreign-Home session key destined for the foreign agent needs to be
   encrypted.

   If the AAAF's local policy determines that the session key needs to
   be encrypted by means other then through IPSec or TLS, as defined in
   [DIAMBASE], due to involvement of more then one local Diameter server
   or any intermediate Diameter agents, the AAAF will check if a
   security association can be established, using the CMS security
   application [CMS] with the originating host found in the MIP-
   Originating-Foreign-AAA AVP. If the security association
   establishment is successful, the AAAF will encrypt the MIP-FA-to-HA
   Key AVP with help of the CMS security application [CMS] with the AAAF
   as originator and the recipient copied from the MIP-Originating-
   Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in
   the HAA destined for the AAAH. Otherwise, if the security association
   cannot be created, the AAAF MUST return a Result-Code AVP with
   DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.

   If the session key does not need to be encrypted, the AAAF will add
   MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward
   the HAA to the AAAH.




Calhoun et al.            expires October 2003                 [Page 37]


Internet-Draft                                                April 2003


   In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the
   HAA returned to the AAAH.

   Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA
   Key AVP if present or the CMS-Encrypted-data AVP if present and not
   destined for the AAAH into the AMA.

   If a Foreign-Home session key was present in the AMA, the foreign
   agent MUST include the Mobile-Foreign authentication extension in the
   Registration Reply, using the newly distributed key.


5.6  Key Distribution Example

   Figure 9 provides an example of subsequent Mobile IP message
   exchange, assuming that AAAH distributed session keys for all three
   MN-FA, FA-HA and HA-MN authentication extensions.

   Mobile Node                Foreign Agent                 Home Agent
   -----------                -------------                 ----------

   Reg-Req(MN-HA-Auth, MN-FA-Auth)-------->
                              Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->

                              <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)

   <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)

                   Figure 9: Mobile IP Message Exchange






















Calhoun et al.            expires October 2003                 [Page 38]


Internet-Draft                                                April 2003


6.0  Key Distribution Center (KDC) AVPs


   The Mobile-IP protocol defines a set of security associations shared
   between the mobile node, foreign agent and home agents. These three
   security associations (Mobile-Home, Mobile-Foreign, and Foreign-Home)
   can be dynamically created by the AAAH, known as session key and key
   material, and has previously been described in section 1.6 and 5.2.
   AAA servers supporting the Diameter Mobile IP Application MUST
   implement the KDC AVPs defined in this document.

   The names of the KDC AVPs indicate the two entities sharing the
   security association defined by the key or the key material; the
   intended receiver of the AVP is the first named entity. So, for
   instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key
   material, which the mobile node will use to derive the Mobile-Home
   Key, and the MIP-HA-to-MN-Key AVP contains the Mobile-Home key for
   the home agent.

   If strong authentication and confidentiality of the session keys is
   required, due to involvement of intermediate Diameter agents, it is
   recommended that the CMS security application [CMS] be used.

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

                                             +---------------------+
                                             |    AVP Flag rules   |
                                             |----+-----+----+-----|----+
                    AVP  Section             |    |     |SHLD| MUST|MAY |
    Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
    -----------------------------------------|----+-----+----+-----|----|
    MIP-Algorithm-   345  6.8     Enumerated | M  |  P  |    |  V  | Y  |
      Type                                   |    |     |    |     |    |
    MIP-FA-to-HA-Key 328  6.2     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-FA-to-HA-SPI 318  6.11    Unsigned32 | M  |  P  |    |  V  | Y  |
    MIP-FA-to-MN-Key 326  6.1     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-FA-to-MN-SPI 319  6.10    Unsigned32 | M  |  P  |    |  V  | Y  |
    MIP-HA-to-FA-Key 329  6.3     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-HA-to-MN-Key 332  6.4     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-Key-Lifetime 367  6.13    Unsigned32 | M  |  P  |    |  V  | Y  |
    MIP-Key-Material 335  6.12    OctetString| M  |  P  |    |  V  | Y  |
    MIP-MN-to-FA-Key 325  6.5     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-MN-to-HA-Key 331  6.6     Grouped    | M  |  P  |    |  V  | Y  |
    MIP-Replay-Mode  346  6.9     Enumerated | M  |  P  |    |  V  | Y  |
    MIP-Session-Key  343  6.7     OctetString| M  |  P  |    |  V  | Y  |




Calhoun et al.            expires October 2003                 [Page 39]


Internet-Draft                                                April 2003


6.1  MIP-FA-to-MN-Key AVP

   The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and
   contains the foreign agent's session key, which it shares with the
   mobile node. Its Data field has the following ABNF grammar:

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



   The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and
   contains the foreign agent's session key, which it shares with the
   home agent. Its Data field has the following ABNF grammar:

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


6.3  MIP-HA-to-FA-Key AVP

   The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and
   contains the Home Agent's session key, which it shares with the
   foreign agent. Its Data field has the following ABNF grammar:
      MIP-HA-to-FA-Key ::= < AVP Header: 329 >
                           { MIP-Algorithm-Type }
                           { MIP-Session-Key }
                         * [ AVP ]


6.4  MIP-HA-to-MN-Key AVP

   The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and
   contains the Home Agent's session key, which it shares with the
   mobile node. Its Data field has the following ABNF grammar:

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




Calhoun et al.            expires October 2003                 [Page 40]


Internet-Draft                                                April 2003


6.5  MIP-MN-to-FA-Key AVP

   The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and
   contains the mobile node's key material, which it uses to derive the
   session key it shares with the foreign agent. The home agent uses
   this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key
   from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA
   SPI field is allocated by the home agent, but it SHOULD take into
   consideration the SPI requested by the mobile node in the "MN-FA Key
   Request From AAA Subtype" extension.

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

6.6  MIP-MN-to-HA-Key AVP

   The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and
   contains the mobile node's  key material, which it uses to derive the
   session key it shares with the Home Agent. The Home Agent uses this
   AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from
   AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI
   field is allocated by the Home Agent, but it SHOULD take into
   consideration the SPI requested by the mobile node in the "MN-HA Key
   Request From AAA Subtype" extension.

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


6.7  MIP-Session-Key AVP

   The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
   contains the Session Key to be used between two Mobile IP entities.











Calhoun et al.            expires October 2003                 [Page 41]


Internet-Draft                                                April 2003


6.8  MIP-Algorithm-Type AVP

   The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and
   contains the Algorithm identifier used to generate the associated
   Mobile IP authentication extension. The following values are
   currently defined:

      1   HMAC-MD5 [HMAC]
      2   HMAC-SHA-1 [HMAC]

6.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 should use when
   authenticating the mobile node.

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

      1   None
      2   Timestamps
      3   Nonces


6.10  MIP-FA-to-MN-SPI AVP

   The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and
   contains the Security Parameter Index the foreign agent is to use to
   refer to the session key it shares with the mobile node. The SPI
   created MUST NOT be a value between zero (0) and 255, which is the
   reserved namespace defined in [MOBILEIP]. This AVP MAY be added in
   the HAA message by the home agent for the AAAH's use in MIP-FA-to-MN-
   SPI AVP of the MIP-FA-to-MN-Key AVP.


6.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 foreign agent is to use to
   refer to the session key it shares with the home agent. The SPI
   created MUST NOT be a value between zero (0) and 255, which is the
   reserved namespace defined in [MOBILEIP]. If FA-HA keys are being
   generated, this AVP MUST be added in the HAA message by the Home
   Agent for the AAAH's (or AAAF's) use in providing the value of the
   MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP.


6.12  MIP-Key-Material AVP



Calhoun et al.            expires October 2003                 [Page 42]


Internet-Draft                                                April 2003


   The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and
   contains the key material sent to the mobile node. The mobile node
   follows the procedures in [MIPKEYS] to generate the session key used
   to authenticate Mobile IP registration messages.


6.13  MIP-Key-Lifetime AVP

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


7.0  Accounting AVPs

   This section will define the Accounting AVPs that are specific to
   Mobile IP.


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


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


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





Calhoun et al.            expires October 2003                 [Page 43]


Internet-Draft                                                April 2003


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


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


7.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 that
   this event occurred on the mobility agent, in seconds since January
   1, 1970 00:00 UTC.


8.0  AVP Occurrence Tables

   The following tables presents the AVPs defined in this document, and
   specifies in which Diameter messages they MAY, or MAY NOT be present.
   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.


8.1  Mobile IP Command AVP Table

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







Calhoun et al.            expires October 2003                 [Page 44]


Internet-Draft                                                April 2003


                                 +-----------------------+
                                 |      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-HA-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-FA-to-HA-SPI              | 0   | 0   | 0   | 0-1 |
   MIP-FA-to-MN-Key              | 0   | 0-1 | 0   | 0   |
   MIP-FA-to-MN-SPI              | 0   | 0   | 0   | 0-1 |
   MIP-Feature-Vector            | 0-1 | 0-1 | 1   | 0   |
   MIP-Filter-Rule               | 0   | 0+  | 0+  | 0   |
   MIP-HA-to-FA-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-HA-to-MN-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-Home-Agent-Address        | 0-1 | 0-1 | 0-1 | 0-1 |
   MIP-Key-Lifetime              | 0   | 0-1 | 0-1 | 0   |
   MIP-MN-AAA-Auth               | 1   | 0   | 0   | 0   |
   MIP-MN-to-FA-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-MN-to-HA-Key              | 0   | 0-1 | 0-1 | 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.            expires October 2003                 [Page 45]


Internet-Draft                                                April 2003


8.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, 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  |
   -------------------------------------|------+------+





























Calhoun et al.            expires October 2003                 [Page 46]


Internet-Draft                                                April 2003


9.0  IANA Considerations


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


9.1  Command Codes

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


9.2  AVP Codes

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


9.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 3.0 for the assignment of the namespace in
   this specification.


9.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 4.5. The remaining bits should only be assigned via
   Standards Action [IANA].


9.5  MIP-Algorithm-Type AVP Values

   As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345)
   defines the values 1-3. All remaining values are available for
   assignment via Designated Expert [IANA].








Calhoun et al.            expires October 2003                 [Page 47]


Internet-Draft                                                April 2003


9.6  MIP-Replay-Mode AVP Values

   As defined in Section 6.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].


9.7  Application Identifier

   This specification assigns the value four (4) to the Application
   Identifier namespace defined in [DIAMBASE]. See section 1.8 for more
   information.


10.0  Security Considerations


   This specification describes a Mobile IP Diameter Application for
   authenticating and authorizing a Mobile IP mobile node. The
   authentication algorithm used is dependent upon the transforms used
   within the Mobile IP protocol, and [MIPCHAL]. This specification 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 IP registration messages [MOBILEIP]. The
   key distribution is asymmetric since communication with the mobile
   node occurs via the Mobile IP protocol [AAAKEY, MOBILEIP], while
   communication to the Home Agent and Foreign Agent occurs via the
   Diameter protocol. As required by [DIAMBASE], transmission-level
   security (IPsec or TLS) MUST be used between Diameter nodes. Where
   untrusted Diameter agents are present, end-to-end security MUST be
   used, via mechanisms such as the CMS application [CMS], a work in
   progress.

   Nonces are sent to the mobile node, which are used to generate the
   session keys via the HMAC-MD5 one-way function. If the nonces are
   compromised, then the pre-shared key between the mobile node and the
   home Diameter server would be vulnerable to an offline dictionary
   attack. 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.

   Since 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 random [RANDOM] value of at
   least 128 bits. The long-term secret between the MN and HA MUST be
   periodically refreshed, to guard against recovery of the long-term
   secret due to nonce reuse or other factors. This is accomplished



Calhoun et al.            expires October 2003                 [Page 48]


Internet-Draft                                                April 2003


   using out-of-band mechanisms, which are not specified in this
   document.

   It should also be noted that it is not recommended to set the MIP-
   Session-Key AVP value equal to zero, since keeping session keys for a
   long time (no refresh) increases the level of vulnerability.


11.0 References

11.1 Normative

[DIAMBASE]     P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
               "Diameter Base Protocol", draft-ietf-aaa-diameter-17.txt,
               IETF work in progress, December 2002.

[IANA]         Narten, Alvestrand,"Guidelines for Writing an IANA Con-
               siderations Section in RFCs", BCP 26, RFC 2434, October
               1998

[MOBILEIP]     C. Perkins, Editor. IP Mobility Support. RFC 3344, August
               2002.

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

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

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

[MIPKEYS]      C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile
               IP", draft-ietf-mobileip-aaa-key-11.txt, IETF work in
               progress, March 2003.

[AAANAI]       F. Johansson, T.Johansson, "AAA NAI for Mobile IP Exten-
               sion", draft-mobileip-aaa-nai-05.txt, IETF work in
               progress, March 2003.


11.2 Informative

[MIPREQ]       S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica-
               tion, Authorization, and Accounting Requirements". RFC
               2977. October 2000.




Calhoun et al.            expires October 2003                 [Page 49]


Internet-Draft                                                April 2003


[CDMA2000]     T. Hiller and al, "CDMA2000 Wireless Data Requirements
               for AAA", RFC 3141, June 2001.

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

[EVALROAM]     B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro-
               tocols", RFC 2477, January 1999.

[MIPNAI]       P. Calhoun, C. Perkins, "Mobile IP Network Address Iden-
               tifier Extension", RFC 2794, March 2000.

[CMS]          P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security
               Application", draft-ietf-aaa-diameter-cms-sec-05.txt,
               IETF work in progress, April 2002.

[RANDOM]       D. Eastlake, 3rd, S. Crocker, and J. Schiller.  Random-
               ness Recommendations for Security.  Request for Comments
               (Informational) 1750, Internet Engineering Task Force,
               December 1994.


12.0  Acknowledgements

   The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and
   Pankaj Patel for their participation in the pre-IETF Document Reading
   Party, to 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-
   P working group for their valuable feedback and also the following
   people for their contribution in the development of the protocol:

   Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael
   Chen, Henry Haverinen, Johan Johansson

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


13.0  Authors' Addresses

   Questions about this memo can be directed to:






Calhoun et al.            expires October 2003                 [Page 50]


Internet-Draft                                                April 2003


      Pat Calhoun
      Airespace
      110 Nortech Parkway
      San Jose, CA 95154
      USA

      Phone: +1 408-635-2023
      Email: pcalhoun@airespace.com

      Tony Johansson
      Bytemobile, Inc
      2029 Stierlin Court
      Mountain View, California 94043
      USA

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

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

      Phone:  +1 650-625-2986
        Fax:  +1 650-625-2502
      E-Mail: charliep@iprg.nokia.com


14.0  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked



Calhoun et al.            expires October 2003                 [Page 51]


Internet-Draft                                                April 2003


   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS 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.


15.0  Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to  per-
   tain 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; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards
   related documentation can be found in BCP-11.  Copies of claims of
   rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.





















Calhoun et al.            expires October 2003                 [Page 52]