INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Laboratories, Inc.
Title: draft-calhoun-diameter-mobileip-03.txt         Charles E. Perkins
Date: October 1999                                 Nokia Research Center



                     DIAMETER Mobile IP Extensions



Status of this Memo

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@ipass.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:

      http://www.ietf.org/shadow.html.


Abstract

   DIAMETER is an Authentication, Authorization and Accounting (AAA)
   Policy Protocol that is used between two entities for various
   services. This document defines an extension that allow a DIAMETER
   Client to request authentication and receive autorization information
   for a Mobile IP Mobile Node.





Calhoun, Perkins           expires April 2000                   [Page 1]


INTERNET DRAFT                                              October 1999


Table of Contents

      1.0  Introduction
            1.1  Copyright Statement
            1.2  Requirements language
            1.3  Changes in version 02
            1.4  Changes in version 03
      2.0  Command Codes
            2.1  AA-Mobile-Node-Request (AMR)
            2.2  AA-Mobile-Node-Answer (AMA)
            2.3  Home-Agent-MIP-Request (HAR)
            2.4  Home-Agent-MIP-Answer (HAA)
            2.5  Mobile-Node-Terminate-Ind (MTI)
      3.0  DIAMETER AVPs
            3.1  MIP-Registration-Request
            3.2  MIP-Registration-Reply
            3.3  MN-FA-Challenge-Length
            3.4  MN-FA-Response
            3.5  MN-to-FA-Key
            3.6  FA-to-MN-Key
            3.7  FA-to-HA-Key
            3.8  HA-to-FA-Key
            3.9  MN-to-HA-Key
            3.10 HA-to-MN-Key
            3.11 Mobile-Node-Address
            3.12 Home-Agent-Address
            3.13 Previous-FA-NAI
            3.14 Foreign-Home-Agent-Available
            3.15 MN-AAA-SPI
      4.0  Protocol Definition
            4.1  Feature Advertisement/Discovery
            4.2  Inter-Domain Mobile IP
            4.3  Allocation of Home Agent in Foreign Network
            4.4  DIAMETER Session Termination
      5.0  Acknowledgements
      6.0  IANA Considerations
      7.0  References
      8.0  Authors' Addresses
      9.0  Full Copyright Statement


1.0  Introduction

   The Mobile IP [4] protocol defines a method that allows a Mobile Node
   to change its point of attachment to the Internet without service
   disruption.  The protocol requires that all Mobility Agents share a
   pre-existing security association, which leads to scaling and
   configuration problems. Mobile IP also does not mention how Mobility



Calhoun, Perkins           expires April 2000                   [Page 2]


INTERNET DRAFT                                              October 1999


   Agents account for services rendered, which does not make it an
   attractive protocol for use by service providers.

   This document specifies extensions to DIAMETER that allow cross-
   domain authentication and authorization, assignment of Mobile Node
   Home Addresses, assignment of Home Agent, as well as Key Distribution
   to allow the Mobile IP network to scale in a large network of service
   providers.

   The dynamic assignment of Mobile Node and Home Agent addresses are
   useful for Service Providers wishing to provide Mobile IP services
   for mobile nodes.

   The DIAMETER Accounting extension [12] will be used by the Foreign
   and Home agents to transfer usage information to the DIAMETER
   servers.

   Small modifications to the Mobile IP protocol [4], which already
   exists in the TEP protocol [8], to allow a Mobile Node to identify
   itself using an NAI [6] in addition to an IP address. The use of the
   Network Access Identifier (NAI) [6] is consistent with the current
   roaming model which makes use of DIAMETER proxying [7].

   The Extension number for this draft is four (4). This value is used
   in the Extension-Id Attribute value Pair (AVP) as defined in [1].


1.1  Copyright Statement

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


1.2  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 [11].


1.3  Changes in version 02

   The following are the changes done to version 03 of the draft:

      - Cleaned up the AVP Header flags

      - The Command Code sections now show an optional Proxy-State AVP
      as part of the message format.




Calhoun, Perkins           expires April 2000                   [Page 3]


INTERNET DRAFT                                              October 1999


      - The previous version required that the MIP-Registration-Reply be
      present in the AMA, but the AVP could not be present if the AAAH
      could not service the request. The AVP is now only mandatory if
      the AMA is successful.

      - Cleaned up the description of the various key and SPI AVPs.

      - Added text in section 4.2 that describes how the AAAH can cache
      the keys directed for the AAAF so they can be included in the
      message when the response is received by the HA. This was the
      point that cause interoperability at the bake-off due to the fact
      that it was quite unclear.

      - Section 4.2 now correctly states that the Home-Address AVP MUST
      be present and MAY have a value of 0.0.0.0.

      - Section 4.2 now also states that the Mobile-IP FA-HA and the
      MN-HA authentication extensions must be used.

      - Added a reference to ESP

      - Added IANA Considerations


1.4  Changes in version 03

   The version 3 of this document contains many changes as a result of
   the DIAMETER Document Reading Party, and other ommisions found after
   the party. Many editorial changes have been done in addition to the
   following items:

      - DIAMETER_ERROR_UNKNOWN_DOMAIN has been removed from section 2.2
      since this is already provided by the base protocol [1].

      - Section 3.4 contains new text on the purpose of the MN-FA-
      Response, and how it is computed.

      - The MN-FA, MN-HA and FA-HA SPI AVPs are no longer supported. The
      various key extensions contain the SPI embedded within the AVP.
      This reduces the number of AVPs, and is consistent with the key
      encoding mechanism described in [15].

      - Key lifetime AVP in section 4.2 was changed to Session-Timeout
      AVP.

      - The Mobile-Node-Terminate-Ind messages were added (section 2.5).

      - Oh, and one of the author's affiliation changed.



Calhoun, Perkins           expires April 2000                   [Page 4]


INTERNET DRAFT                                              October 1999


2.0  Command Codes

   This section will define the Commands [1] for DIAMETER
   implementations supporting the Mobile IP extension.

      Command Name               Command Code
      ---------------------------------------
      AA-Mobile-Node-Request         306
      AA-Mobile-Node-Answer          307
      Home-Agent-MIP-Request         308
      Home-Agent-MIP-Answer          309
      Mobile-Node-Terminate-Ind      ???


2.1  AA-Mobile-Node-Request (AMR)

   Description

      The AA-Mobile-Node-Request is sent by a Foreign Agent acting as a
      DIAMETER client to a server to request authentication and
      authorization of a Mobile Node.

      The AA-Mobile-Node-Request message MUST include the MIP-
      Registration-Request, User-Name, MN-FA-Challenge-Length, MN-FA-
      Response AVP as well as the Session-ID AVPs.

      The Mobile-Node-Address AVP contains the the Home Address found in
      the Mobile Node's Registration Request. The Home-Agent-Address AVP
      contains the Home Address found in the Registration Request. If
      the Home Address is zero, it indicates that the Mobile Node is
      requesting that an address be allocated to it.

      The User-Name AVP contains the NAI found in the Mobile IP
      Registration Request's Mobile-Node-NAI Extension.

      If the Previous-FA-NAI AVP is found in the request, the DIAMETER
      Client is requesting that the Server return the Session Key that
      was assigned to the previous Foreign Agent for use with the Mobile
      Node. The Session Key is identified through the use of the
      Mobile-Node-Address AVP.

   Message Format









Calhoun, Perkins           expires April 2000                   [Page 5]


INTERNET DRAFT                                              October 1999


      <AA-Mobile-Node-Request>  ::= <DIAMETER Header>
                                    <AA-Mobile-Node-Request Command AVP>
                                    <Session-ID AVP>
                                    <User-Name AVP>
                                    <MIP-Registration-Request AVP>
                                    <MN-FA-Challenge-Length AVP>
                                    <MN-FA-Response AVP>
                                    <Mobile-Node-Address AVP>
                                    <Home-Agent-Address AVP>
                                    <MN-AAA SPI AVP>
                                    [<Previous-FA-NAI AVP>]
                                    [<Proxy-State AVP>]
                                    <Timestamp AVP>
                                    <Nonce AVP>
                                    {<Integrity-Check-Value AVP> ||
                                     <Digital-Signature AVP> }

   The length of the DIAMETER Command AVP must be 12 when the Command
   Code is set to 306 (AA-Mobile-Node-Request).


2.2  AA-Mobile-Node-Answer (AMA)

   Description

      The AA-Mobile-Node-Answer is sent by the DIAMETER Server to the
      client in response to the AA-Mobile-Node-Request message. The
      message MUST include the Session-Id, Result-Code as well as the
      various key AVPs (see section 3.0) and MAY include the Home-
      Agent-Address and Mobile-Node-Address AVPs. A successful response
      MUST include the MIP-Registration-Reply AVP.

      The Home-Agent-Address AVP contains the Home Agent assigned to the
      Mobile Node. If the AVP contains a zero address, it is a request
      to allocate a Home Agent locally.

      The Mobile-Node-Address AVP contains the IP Address assigned to
      the Mobile Node. If this AVP contains a zero address, it is a
      request to allocate a Home Address for the Mobile Node.

      The following error codes are defined for this message for use in
      the Error-Code AVP [1]:

         DIAMETER_ERROR_USER_UNKNOWN         1
            This error code is used to indicate to the initiator that
            the username request is not valid.

         DIAMETER_ERROR_BAD_PASSWORD         2



Calhoun, Perkins           expires April 2000                   [Page 6]


INTERNET DRAFT                                              October 1999


            This error code indicates that the password provided is
            invalid.

         DIAMETER_ERROR_CANNOT_AUTHORIZE     3
            This error code is used to indicate that the user cannot be
            authorized due to the fact that the user has expended local
            resources. This could be a result that the server believes
            that the user has already spent the number of credits in
            his/her account, etc.

   Message Format

      <AA-Mobile-Node-Answer>  ::= <DIAMETER Header>
                                   <AA-Mobile-Node-Answer Command AVP>
                                   <Session-Id AVP>
                                   <Result-Code AVP>
                                   [<Error-Code AVP>]
                                   [<MIP-Registration-Reply AVP>]
                                   <FA-to-MN-Key AVP>
                                   <FA-to-HA-Key AVP>
                                   <Home-Agent-Address AVP>
                                   <Mobile-Node-Address AVP>
                                   <Session-Timeout AVP>
                                    [<Proxy-State AVP>]
                                   <Timestamp AVP>
                                   <Nonce AVP>
                                   {<Integrity-Check-Value AVP> ||
                                    <Digital-Signature AVP> }

   The length of the DIAMETER Command AVP must be 12 when the Command
   Code is set to 307 (AA-Mobile-Node-Answer).


2.3  Home-Agent-MIP-Request (HAR)

   Description

      The Home-Agent-MIP-Request is sent by the home DIAMETER server to
      the Home Agent overseeing the Mobile Node to process the Mobile IP
      Registration Request.

      The Home-Agent-MIP-Request message MUST include the MIP-
      Registration-Request, User-Name, Session-ID as well as the key
      AVPs (see section 3.0) to be used by the Mobile Node and the Home
      Agent.

      If the Mobile-Node-Address AVP is set to a zero Address, it is a
      request to the Home Agent to allocate a Home Address to the Mobile



Calhoun, Perkins           expires April 2000                   [Page 7]


INTERNET DRAFT                                              October 1999


      Node.

   Message Format

      <Home-Agent-MIP-Request>  ::= <DIAMETER Header>
                                    <Home-Agent-MIP-Request Command AVP>
                                    <Session-Id AVP>
                                    <User-Name AVP>
                                    <MIP-Registration-Request AVP>
                                    <HA-to-MN-Key AVP>
                                    <MN-to-HA-Key AVP>
                                    <HA-to-FA-Key AVP>
                                    <MN-to-FA-Key AVP>
                                    <Home-Agent-Address AVP>
                                    <Mobile-Node-Address AVP>
                                    <Session-Timeout AVP>
                                    [<Proxy-State AVP>]
                                    <Timestamp AVP>
                                    <Nonce AVP>
                                    {<Integrity-Check-Value AVP> ||
                                     <Digital-Signature AVP> }

   The length of the DIAMETER Command AVP must be 12 when the Command
   Code is set to 308 (Home-Agent-MIP-Request).


2.4  Home-Agent-MIP-Answer (HAA)

   Description

      The Home-Agent-MIP-Answer is sent by the Home Agent to the home
      DIAMETER Server in response to the Home-Agent-MIP-Request. The
      message MUST include the Session-Id, Result-Code, MIP-
      Registration-Reply and the Mobile-Node-Address.

      The following error codes are defined for this message for use in
      the Error-Code AVP [1]:

         DIAMETER_ERROR_BAD_KEY             1
            This error code is used by the Home Agent to indicate to the
            local DIAMETER Server that the key generated is invalid.

         DIAMETER_ERROR_BAD_HOME_ADDRESS    2
            This error code is used by the Home Agent to indicate that
            the Home Address chosen by the Mobile Node or assigned by
            the local DIAMETER server is unavailable.

         DIAMETER_ERROR_TOO_BUSY            3



Calhoun, Perkins           expires April 2000                   [Page 8]


INTERNET DRAFT                                              October 1999


            This error code is used by the Home Agent to inform the
            DIAMETER Server that it cannot handle an extra Mobile Node.
            Upon receiving this error the DIAMETER Server can try to use
            an alternate Home Agent if one is available.

         DIAMETER_ERROR_MIP_REPLY_FAILURE   4
            This error code is used by the Home Agent to inform the
            DIAMETER Server that the Registration Request failed.

   Message Format

      <Home-Agent-MIP-Answer>  ::= <DIAMETER Header>
                                   <Home-Agent-MIP-Answer Command AVP>
                                   <Session-Id AVP>
                                   <Result-Code AVP>
                                   [<Error-Code AVP>]
                                   <MIP-Registration-Reply AVP>
                                   <Mobile-Node-Address AVP>
                                   <Home-Agent-Address AVP>
                                    [<Proxy-State AVP>]
                                   <Timestamp AVP>
                                   <Nonce AVP>
                                   {<Integrity-Check-Value AVP> ||
                                    <Digital-Signature AVP> }

   The length of the DIAMETER Command AVP must be 12 when the Command
   Code is set to 309 (Home-Agent-MIP-Answer).


2.5  Mobile-Node-Terminate-Ind (MTI)

   Description

      The Mobile-Node-Terminate-Ind is sent by a Foreign Agent or Home
      Agent as a DIAMETER client to a server to inform the server that
      an active session has been terminated. The MTS message can be sent
      by a DIAMETER Server to a client in order to request that an
      active session be terminated.

      The Mobile-Node-Terminate-Ind message MUST include the Session-Id,
      User-Name, Home-Agent-Address and Mobile-Node-Address AVPs.

   Message Format








Calhoun, Perkins           expires April 2000                   [Page 9]


INTERNET DRAFT                                              October 1999


      Mobile-Node-Terminate-Ind  ::= <DIAMETER Header>
                                     <MTI Command AVP>
                                     <Session-ID AVP>
                                     <User-Name AVP>
                                     <Mobile-Node-Address AVP>
                                     <Home-Agent-Address AVP>
                                     [<Proxy-State AVP>]
                                     <Timestamp AVP>
                                     <Nonce AVP>
                                     {<Integrity-Check-Value AVP> ||
                                      <Digital-Signature AVP> }

   The length of the DIAMETER Command AVP must be 12 when the Command
   Code is set to ??? (Mobile-Node-Terminate-Ind).


3.0  DIAMETER AVPs

   This section will define the mandatory AVPs which MUST be supported
   by all DIAMETER implementations supporting this extension. The
   following AVPs are defined in this document:

      Attribute Name       Attribute Code    Definition in Section
      ------------------------------------------------------------
      MIP-Registration-Request  320                  3.1
      MIP-Registration-Reply    321                  3.2
      MN-FA-Challenge-Length    322                  3.3
      MN-FA-Response            323                  3.4
      MN-to-FA-Key              325                  3.5
      FA-to-MN-Key              326                  3.6
      FA-to-HA-Key              328                  3.7
      HA-to-FA-Key              329                  3.8
      MN-to-HA-Key              331                  3.9
      HA-to-MN-Key              332                  3.10
      Mobile-Node-Address       333                  3.11
      Home-Agent-Address        334                  3.12
      Previous-FA-NAI           335                  3.13
      MN-AAA-SPI                336                  3.14


3.1  MIP-Registration-Request

   Description

      This AVP is used to carry the Mobile IP Registration Request [4]
      sent by the Mobile Node to the Foreign Agent within a DIAMETER
      message.




Calhoun, Perkins           expires April 2000                  [Page 10]


INTERNET DRAFT                                              October 1999


   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 320)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  The 'H' or 'E' may be set if
         the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT
         be set.

      Data
         The data field contains the Mobile IP Registration Request.


3.2  MIP-Registration-Reply

   Description

      This AVP is used to carry the Mobile IP Registration Reply [4]
      sent by the Home Agent to the Foreign Agent within a DIAMETER
      message.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 321)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  The 'H' or 'E' may be set if
         the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT
         be set.

      Data
         The data field contains the Mobile IP Registration Reply.





Calhoun, Perkins           expires April 2000                  [Page 11]


INTERNET DRAFT                                              October 1999


3.3  MN-FA-Challenge-Length

   Description

      The MN-FA-Challenge-Length AVP contains the number of octets in
      the MIP-Registration-Request AVP that are to be used by the
      DIAMETER server to compute the Response, as described in section
      3.4.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 322)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  The 'H' or 'E' may be set if
         the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT
         be set.

      Integer32
         The Integer32 field contains the number of octets in the MIP-
         Registration-Request AVP that are used to generate the
         Challenge Response, and authenticate the Mobile Node.


3.4  MN-FA-Response

   Description

      This AVP contains the Response generated by the Mobile Node as
      defined in the Mobile IP MN-AAA authentication extension [5]. The
      AVP contains the value of the authenticator field in the
      authentication extension. The authenticator is the value computed
      by the mobile node using the Registration Request and the security
      association it shares with its Home DIAMETER Server.

      The Mobile Node's Home DIAMETER Server uses the data in this AVP
      in order to authenticate the mobile node.

   AVP Format





Calhoun, Perkins           expires April 2000                  [Page 12]


INTERNET DRAFT                                              October 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 323)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  The 'H' or 'E' may be set if
         the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT
         be set.

      Data
         The data field contains the mobile node's challenge response
         and is used to authenticate the mobile node. Although any
         authentication algorithm can be used, all implementations MUST
         support MD5's prefix+suffix mode, as described in [5]. The
         formula used to generate the hash is as follow:

            MD5(Key | Challenge | Key)

         Where the Key field is the secret shared between the DIAMETER
         Server and the Mobile Node. The key is concatinated with the
         Challenge value, which is found in the MIP-Registration-Request
         AVP. Note that only a portion of the data in the registration
         request is used for the calculation of the response. The length
         of the challenge can be found in the MN-FA-Challenge-Length
         AVP.


3.5  MN-to-FA-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Mobile Node to compute the MN-FA
      Authentication Extension in the Registration Request [4]. This key
      is encrypted using the security association the Home AAA DIAMETER
      Server shared with the Mobile Node. This AVP SHOULD be present in
      the Home-Agent-MIP-Request.

   AVP Format







Calhoun, Perkins           expires April 2000                  [Page 13]


INTERNET DRAFT                                              October 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 325)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             FA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:

             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the mobile node
         must use to determine the algorithm to use for recovering the
         FA security information.

      FA SPI
         A 32-bit opaque value, which the mobile node MUST use to index
         all the necessary information recovered from the FA security
         information after it is decoded. The SPI value MUST be the same
         as the value in the MN SPI field in section 3.6.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the mobile node and the



Calhoun, Perkins           expires April 2000                  [Page 14]


INTERNET DRAFT                                              October 1999


         foreign agent.


3.6  FA-to-MN-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Foreign Agent to compute the MN-FA
      Authentication Extension in the Registration Request and Reply
      [4]. This key is encrypted using the security association the Home
      AAA DIAMETER Server shared with the Foreign Agent. If the Foreign
      Agent does not belong to the same administrative domain as the
      DIAMETER Server, the server uses the security assocation it shares
      with the DIAMETER server in the foreign agent's administrative
      domain.  This AVP SHOULD be present in the AA-Mobile-Node-Answer.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 326)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             MN SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:




Calhoun, Perkins           expires April 2000                  [Page 15]


INTERNET DRAFT                                              October 1999


             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the foreign
         agent must use to determine the algorithm to use for recovering
         the MN security information.

      MN SPI
         A 32-bit opaque value, which the foreign agent MUST use to
         index all the necessary information recovered from the MN
         security information after it is decoded. The SPI value MUST be
         the same as the value in the FA SPI field in section 3.5.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the mobile node and the
         foreign agent.


3.7  FA-to-HA-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Foreign Agent to compute the FA-HA
      Authentication Extension in the Registration Request and Reply
      [4]. This key is encrypted using the security association the Home
      AAA DIAMETER Server shared with the Foreign Agent. If the Foreign
      Agent does not belong to the same administrative domain as the
      DIAMETER Server, the server uses the security association it
      shares with the DIAMETER server in the foreign agent's
      administrative domain.  This AVP SHOULD be present in the AA-
      Mobile-Node-Answer.

   AVP Format













Calhoun, Perkins           expires April 2000                  [Page 16]


INTERNET DRAFT                                              October 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 328)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             HA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:

             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the foreign
         agent must use to determine the algorithm to use for recovering
         the HA security information.

      HA SPI
         A 32-bit opaque value, which the foreign agent MUST use to
         index all the necessary information recovered from the HA
         security information after it is decoded. The SPI value MUST be
         the same as the value in the FA SPI field in section 3.8.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the foreign and the home



Calhoun, Perkins           expires April 2000                  [Page 17]


INTERNET DRAFT                                              October 1999


         agent.


3.8  HA-to-FA-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Home Agent to compute the FA-HA
      Authentication Extension in the Registration Request and Reply
      [4]. This key is encrypted using the security association the Home
      AAA DIAMETER Server shared with the Home Agent. If the Home Agent
      does not belong to the same administrative domain as the DIAMETER
      Server, the server uses the security association it shares with
      the DIAMETER server in the home agent's administrative domain.
      This AVP SHOULD be present in the Home-Agent-MIP-Request.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 329)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             FA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:




Calhoun, Perkins           expires April 2000                  [Page 18]


INTERNET DRAFT                                              October 1999


             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the home agent
         must use to determine the algorithm to use for recovering the
         FA security information.

      HA SPI
         A 32-bit opaque value, which the home agent MUST use to index
         all the necessary information recovered from the FA security
         information after it is decoded. The SPI value MUST be the same
         as the value in the HA SPI field in section 3.7.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the foreign and the home
         agent.


3.9  MN-to-HA-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Mobile Node to compute the MN-HA
      Authentication Extension in the Registration Request [4]. This key
      is encrypted using the security association the Home AAA DIAMETER
      Server shared with the Mobile Node. This AVP SHOULD be present in
      the Home-Agent-MIP-Request.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 331)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             HA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+



Calhoun, Perkins           expires April 2000                  [Page 19]


INTERNET DRAFT                                              October 1999


      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:

             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the mobile node
         must use to determine the algorithm to use for recovering the
         HA security information.

      HA SPI
         A 32-bit opaque value, which the mobile node MUST use to index
         all the necessary information recovered from the HA security
         information after it is decoded. The SPI value MUST be the same
         as the value in the MN SPI field in section 3.10.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the mobile node and the
         home agent.


3.10  HA-to-MN-Key

   Description

      This AVP contains the Key generated by the home DIAMETER Server
      that must be used by the Home Agent to compute the MN-HA
      Authentication Extension in the Registration Request and Reply
      [4]. This key is encrypted using the security association the Home
      AAA DIAMETER Server shared with the Home Agent. If the Home Agent
      does not belong to the same administrative domain as the DIAMETER
      Server, the server uses the security association it shares with



Calhoun, Perkins           expires April 2000                  [Page 20]


INTERNET DRAFT                                              October 1999


      the DIAMETER server in the home agent's administrative domain.
      This AVP SHOULD be present in the Home-Agent-MIP-Request.

   AVP Format


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 332)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |      Security Algorithm       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            AAA SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             MN SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Length
         The length of this attribute MUST be at least 21.

      AVP Flags
         The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
         message integrity is required.  Either the 'H' or 'E' bit MUST
         be set as this AVP contains keying information. The 'V', 'H'
         and 'T' bits MUST NOT be set.

      Security Algorithm
         The security algorithm field specifies the algorithm that was
         used to encrypt the session keys. The values are consistent
         with those found in [15], which also contains the formula used
         for encryption. The following are currently defined:

             Algorithm Identifier   Name                Reference
             ---------------------  ------------------  -------------
             2                      MD5/prefix+suffix   RFC 2002 [14]
             3                      HMAC MD5            RFC 2104 [13]

      AAA SPI
         A 32-bit opaque value, indicating the SPI that the home agent
         must use to determine the algorithm to use for recovering the
         MN security information.

      HA SPI
         A 32-bit opaque value, which the home agent MUST use to index
         all the necessary information recovered from the MN security



Calhoun, Perkins           expires April 2000                  [Page 21]


INTERNET DRAFT                                              October 1999


         information after it is decoded. The SPI value MUST be the same
         as the value in the HA SPI field in section 3.9.

      Data
         The data field contains the encrypted key used to create a
         Mobility Security Association between the mobile node and the
         home agent.


3.11  Mobile-Node-Address

   Description

      The Mobile-Node-Address AVP contains the Mobile Node's Home
      Address.  When this AVP has a zero IP Address (0.0.0.0), it is a
      request that a Home Address be allocated to the Mobile Node.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 333)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Address
         The Address field contains the IP address assigned to the
         Mobile Node, or 0.0.0.0 if one is requested.


3.12  Home-Agent-Address

   Description

      The Home-Agent-Addess AVP contains the Mobile Node's Home Agent
      Address. When this AVP has a NULL address (0.0.0.0), it is a
      request that a Home Agent be allocated to the Mobile Node. If this
      AVP is set to the NULL address in the AMA message, it is an
      indication that a Home Agent MUST be allocated in the foreign
      network.




Calhoun, Perkins           expires April 2000                  [Page 22]


INTERNET DRAFT                                              October 1999


   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 334)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Address...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Address
         The Address field contains the Home Agent address assigned to
         the Mobile Node. If the address is set to 0.0.0.0, the Mobile
         Node is requesting that a Home Agent be allocated either in the
         foreign network or in its home network. If the address is set
         to 255.255.255.255 the Mobile Node is requesting that the Home
         Agent be allocated only within its home network.


3.13  Previous-FA-NAI

   Description

      The Previous-FA-NAI AVP contains the Network Access Identifier of
      the Mobile Node's old Foreign Agent. The Mobile Node will include
      this information in the Registration Request when it moves it
      point of attachment to a new foreign agent under the same
      administrative domain as the old FA (identified by the domain part
      of the NAI).

      When this AVP is present in the AA-Mobile-Node-Request, it
      indicates that the local DIAMETER Server overseeing the Foreign
      Agent should attempt to return the session key that was previously
      allocated to the old Foreign Agent for the Mobile Node. The
      session key is identified through the use of the Mobile-Node-
      Address AVP, which MUST be present if this extension is present.

      This allows the Mobile Node to move from one Foreign Agent to
      another within the same administrative domain without having to
      send the request back to the Mobile Node's Home DIAMETER Server.

   AVP Format




Calhoun, Perkins           expires April 2000                  [Page 23]


INTERNET DRAFT                                              October 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 335)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      String
         The String field contains the Mobile Node's old Foreign Agent's
         NAI.


3.14  Foreign-Home-Agent-Available

   Description

      The Foreign-Home-Agent-Available AVP is added by the AAAF owned by
      the same adminitrative domain as the Foreign Agent if it is
      willing and able to allocate a Home Agent within the Foreign
      network for the Mobile Node.

      If this extension is present in the AMR and the Home-Agent-Address
      AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a
      Home Agent for the Mobile Node. This is done by including the
      Home-Agent-Address AVP with a value of 0.0.0.0 in the AMR.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 335)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32



Calhoun, Perkins           expires April 2000                  [Page 24]


INTERNET DRAFT                                              October 1999


         The Integer32 field MUST be set to 1 to inform the AAAH that
         the AAAF is able and willing to allocate a Home Agent for the
         Mobile Node.


3.15  MN-AAA-SPI

   Description

      The MN-AAA-SPI is sent in the AA-Mobile-Node-Request by the
      Foreign Agent, and contains the SPI value found in the Mobile-IP
      MN-AAA Authentication Extension [5]. The SPI can be used by the
      AAAH to identify the authentication transform to use with the
      Mobile Node, in the event that the Mobile-Node's NAI is not
      sufficient.

   AVP Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        AVP Header (AVP Code = 336)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              SPI                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Flags
         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32
         The Integer32 field contains the SPI value associated with the
         Security Association shared between the Mobile Node and the
         AAAH.


4.0  Protocol Definition

   This section will outline how the DIAMETER Mobile IP Extension can be
   used.


4.1  Feature Advertisement/Discovery

   As defined in [1], the Reboot-Ind message can be used to inform a
   peer about locally supported DIAMETER Extensions. In order to
   advertise support of this extension, the Extension-Id AVP must be



Calhoun, Perkins           expires April 2000                  [Page 25]


INTERNET DRAFT                                              October 1999


   transmitted with a value of four (4).


4.2  Inter-Domain Mobile IP

   The following diagram is an example of an inter-domain Mobile IP
   network.

                            ISP                   Home Network
                        +--------+                 +--------+
                        |        |      AMR/A      |        |
                        |  AAAF  |<--------------->|  AAAH  |
                        | server |  server-server  | server |
                        +--------+  communication  +--------+
                         /    /|\                   /|\
                        /AMR/A | client-server       | HAR/A
                       /       | communication       |
                     |/_      \|/                   \|/
             +---------+       +---------+          +---------+
             | Foreign |       | Foreign |          |  Home   |
             |  Agent  |       |  Agent  |          |  Agent  |
             +---------+       +---------+          +---------+
                              /|\
                               | Mobile IP
                               |
                              \|/
                              +--------+
                              | Mobile |
                              | Node   |
                              +--------+

                      Figure 1: Inter-Domain Mobility

   The AA-Mobile-Node-Request (AMR) is generated by the Foreign Agent
   and includes the AVPs defined in section 2.1. The Mobile-Node-Address
   AVP's value is copied from the Registration Request's Home Address
   field. The Home-Agent-Address AVP's value is copied from the
   Registration Request's Home Agent field. The value of the User-Name
   AVP [1] is taken from the Mobile-Node-NAI extension as described in
   [8]. The request is then forwarded to the Foreign Agent's local
   DIAMETER server, known as the AAA-Foreign, or AAAF.

   When the AAAF receives the message, it uses the User-Name AVP [1] to
   determine whether authentication and authorization can be handled
   locally. The User-Name format is consistent with the NAI described in
   [6] and the user's domain is used to determine the Mobile Node's home
   DIAMETER Server (or AAAH). In the example below, the request cannot
   be processed by the AAAF, therefore the request is proxied [9] to the



Calhoun, Perkins           expires April 2000                  [Page 26]


INTERNET DRAFT                                              October 1999


   AAAH. Note that this exchange is only required when the Mobile Node
   attempts to gain service with a new Foreign Agent, or if the keys
   previously distributed expire. The AAAF MAY include the Proxy-State
   AVP in the request, as described in [1], in order to assist it in
   keeping Session State Information.

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

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

              Figure 2: Mobile IP/DIAMETER Message Exchange

   The AAAH uses the security association shared between the itself and
   the Mobile Node in order to validate the MN-FA-Response. If the
   response is invalid, the AAAH returns the AA-Mobile-Node-Answer (AMA,
   see section 2.2) with a Result-Code set to the appropriate value.

   If the Mobile Node was successfully authenticated, the AAAH checks
   whether the Home-Agent-Address AVP specified a Home Agent. If one was
   specified, the AAAH must validate the address to ensure that it is a
   known Home Agent. If no Home Agent was specified the AAAH SHOULD
   allocate one 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 of this
   specification, but the method proposed in [4] can be used.

   If the AMR's Mobile-Node-Address AVP did not specify an address, the
   AAAH has the option of assigning an address for the Mobile Node, or
   it can leave this up to the Home Agent. This is purely a local policy
   decision.

   The AAAH then proceeds to generate three short-lived session keys;
   one which is shared between the Mobile Node and the Home Agent, one
   between the Mobile Node and the Foreign Agent, and one between the
   Foreign Agent and the Home Agent.

   The keys destined for the Mobile Node are encrypted either using the
   Mobile Node's secret or its public key [1, 9]. The keys destined for



Calhoun, Perkins           expires April 2000                  [Page 27]


INTERNET DRAFT                                              October 1999


   the Foreign Agent are encrypted either using the secret shared
   between the AAAH and the AAAF, or using public key cryptography [1,
   9]. The keys destined for the Home Agent can be either encrypted
   using the secret it shares with the AAAH. The Session-Timeout AVP is
   included and contains the number of seconds before the session keys
   expire. A value of zero indicates that the session keys have no
   expiration.

   Note that this extension requires a departure from the existing SPI
   usage described in [4]. The AAAH generates SPI values for the
   Mobility Agents as opposed to a receiver choosing its own SPI value.
   The SPI values are used as Key Identifiers, meaning that each short-
   lived session key has its own SPI value and since two nodes share a
   session key they share an SPI as well.

   Suppose a Mobile Node and a Foreign Agent share a key that was
   created by the AAAH. The AAAH also generated a corresponding SPI
   value of 37,496. All Mobile-Foreign Authentication extensions must be
   computed by either entity using the shared session key would then
   include the SPI value of 37,496.

   The AAAH then sends a Home-Agent-MIP-Request (HAR) to the assigned or
   requested Home Agent. The HAR contains the MIP-Registration-Request
   as well as the keys destined for the Home Agent (HA-to-MN-Key, HA-
   to-FA-Key AVPs) and the Mobile Node (MN-to-FA-Key, MN-to-HA-Key AVP).
   The Mobile-Node-Address AVP contains an address if the Mobile Node
   specified a home address or if the AAAH assigned an address, but no
   address would be specified if the Home Agent were to assign one.

   Note that the keys generated for the Foreign Agent, the SPIs and the
   Session Timeout  will have to be propagated to the AAAF in a future
   message. The AAAH can use one of two suggested methods:

      1. Maintain Session State information within the AAAH, based on
      the Session Identifier. When the Response from the Home Agent is
      received, the AAAH looks up the FA keys, SPI and Session Timeout
      and includes them in the DIAMETER message bound for the AAAF.

      2. Add the FA keys within the Proxy-State AVP [1]. The Home Agent
      MUST include the same Proxy-State AVP in the response. The AAAH
      can then pull the information from the Proxy-State AVP and include
      them in the message targeted for the AAAF.

   Note that the method used will not create any interoperability issues
   given that the decision is purely local and the Home Agent does not
   attempt to decode the Proxy-State AVP.

   The Home Agent processes the DIAMETER Home-Agent-MIP-Request as well



Calhoun, Perkins           expires April 2000                  [Page 28]


INTERNET DRAFT                                              October 1999


   as the embedded Mobile IP Registration Request. If both are
   successfull, the Home Agent creates the Mobile IP Registration Reply,
   and furthermore includes the keying material to be used by the Mobile
   Node (MN-to-FA-Key, MN-to-HA-Key) in the MIP-Registration-Reply AVP.
   If the address in the Mobile-Node-Address AVP in the request was set
   to zeros (0.0.0.0),  the Home Agent must assign an address for the
   Mobile Node. The Result-Code AVP is included and the Home-Agent-MIP-
   Answer is sent to the AAAH.

   The AAAH then issues a AA-Mobile-Node-Answer to the AAAF which
   includes the MIP-Registration-Reply, Result-Code and the Mobile-
   Node-Address AVP. As mentioned earlier, the AAAH must be able to find
   the previously created information destined for the AAAF, and add
   them in the response. The AVPs are must be added are the FA-to-MN-
   Key, FA-to-HA-Key and the Session-Timeout AVPs.

   Upon receipt of the successful AA-Mobile-Node-Answer the AAAF
   decrypts the FA-to-MN-Key and the FA-to-HA-Key AVPs. These keys are
   then re-encrypted using the DIAMETER secret [1] or via end-to-end
   encryption [9], unless IPSEC's ESP [10] is used between the Foreign
   Agent and the AAAF. The message is transmitted to the Foreign Agent.

   The Foreign Agent, upon receipt of the AA-Mobile-Node-Answer,
   decrypts the appropriate KEY AVPs, and processes the Mobile IP
   Registration Reply which is then forwarded to the Mobile Node.

   From this point on, all Registration Request and Replies need rely on
   the DIAMETER proxy chain, the Foreign Agent can contact the Home
   Agent directly using the keys which were previously distributed. This
   can continue until the session keys expire, as indicated in the
   Session-Timeout AVP [1].

   The following is an example of subsequent Mobile IP message exchange.

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

   Reg-Req(MN-FA-Auth, MN-HA-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 3: Mobile IP Message Exchange

   Note that subsequent registrations MUST use the MN-FA, FA-HA and MN-



Calhoun, Perkins           expires April 2000                  [Page 29]


INTERNET DRAFT                                              October 1999


   FA Authentication extensions [4], using the keys generated by the
   AAAH.


4.3  Allocation of Home Agent in Foreign Network

   When the AAAF receives the AMR message, it can add the Foreign-Home-
   Agent-Available AVP to inform the AAAH that it is able and willing to
   assign a Home Agent for the Mobile Node. The AAAH will only allow
   this if the Home-Agent-Address in the AMR is set to zero (0). The
   AAAH does this by sending the AMA message to the AAAF with the Home-
   Agent-Address AVP set to zero (0). The AMA message still includes all
   of the keying information that was previously discussed, except that
   the keys for the Home Agent are encrypted using the security
   association the AAAH shares with the AAAF.

                            ISP                   Home Network
                        +--------+                 +--------+
                        |        |      AMR/A      |        |
                        |  AAAF  |<--------------->|  AAAH  |
                        | server |  server-server  | server |
                        +--------+  communication  +--------+
                         /    /|\
                 HAR/A  /AMR/A | client-server
                       /       | communication
                     |/_      \|/
             +---------+       +---------+
             |   Home  |       | Foreign |
             |  Agent  |       |  Agent  |
             +---------+       +---------+
                              /|\
                               | Mobile IP
                               |
                              \|/
                              +--------+
                              | Mobile |
                              | Node   |
                              +--------+
             Figure 4: Home Agent allocated in Foreign Domain

   Upon receipt of such a message, the AAAF issues the HAR message to
   the Home Agent. Upon receipt of the response from the Home Agent the
   AAAF issues the AMA message to the Foreign Agent in the same method
   described earlier.







Calhoun, Perkins           expires April 2000                  [Page 30]


INTERNET DRAFT                                              October 1999


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

             <-------Challenge
   Reg-Req(Response)->
                 AMR------------->
                                 AMR-------------------------->
                                            <------------------------AMA
                                 HAR------------->
                                            <----------HAA
                             <------------AMA
             <-------Reg-Reply
               Figure 5: Mobile IP/DIAMETER Message Exchange

   If the Mobile Node moves to another Foreign Network, which it detects
   from the Router Advertisement message, it can either request to keep
   the same Home Agent within the old foreign network, or it can request
   that a new one be assigned. If the Home-Agent-Address AVP is set to a
   value, it indicates that the same Home Agent should be used.

   In this case the new AAAF would issue the AMR message towards the
   Mobile Node's AAAH, which would create the keys as previously
   defined. In this case all of the keys destined for the Home Agent
   would be encrypted using the security association it shares with the
   old Foreign Network's AAAF, while the keys for the Foreign Agent
   would be encrypted using the security association shared with the new
   Foreign Network's AAAF.


4.4  DIAMETER Session Termination

   For DIAMETER Servers that maintain Mobile Node state information,
   each session has a specific lifetime, which is derived from the
   Session-Timeout AVP. Therefore a DIAMETER Server can release
   resources for a Mobile Node once the time has expired. However, it
   would be desirable for the DIAMETER Server to be notified when a
   session is terminated, which would allow it to release resources when
   they are no longer used.

   The Mobile-Node-Termination-Ind message is sent by a DIAMETER Client,
   be it a Foreign or Home Agent, to inform a DIAMETER Server that a
   session has been terminated. The MTI message MAY be sent by a
   DIAMETER Server to a client in order to request that the Mobile
   Node's session be terminated.


5.0  Acknowledgements




Calhoun, Perkins           expires April 2000                  [Page 31]


INTERNET DRAFT                                              October 1999


   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the Document Reading Party.
   The authors would also like to thank the participants of TIA's TR45.6
   working group for their valuable feedback.


6.0  IANA Considerations

   The numbers for the Command Code AVPs (section 2) is taken from the
   numbering space defined for Command Codes in [1]. The numbers for the
   various AVPs defined in section 3 were taken from the AVP numbering
   space defined in [1].  The numbering for the AVP and Command Codes
   MUST NOT conflict with values specified in [1] and other DIAMETER
   related Internet Drafts.


7.0  References

    [1]  Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft,
         draft-calhoun-diameter-10.txt, Work in Progress,
         October 1999.
    [2]  Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
         Draft, draft-calhoun-diameter-framework-04.txt,
         Work in Progress, October 1999.
    [3]  P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment
         Protocol", draft-ietf-mobileip-calhoun-tep-01.txt,
         Work in Progress, March 1998.
    [4]  C. Perkins, Editor. IP Mobility Support. RFC 2002, October
         1996.
    [5]  C. Perkins, P. Calhoun, "Mobile IP Challenge/Response
         Extensions", draft-ietf-mobileip-challenge-04.txt, Work in
         Progress, October 1999.
    [6]  Aboba, Beadles "The Network Access Identifier." RFC 2486.
         January 1999.
    [7]  Aboba, Zorn, "Criteria for Evaluating Roaming Protocols",
         RFC 2477, January 1999.
    [8]  P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier
         Extension", draft-ietf-mobileip-mn-nai-05.txt,
         Work in Progress, October 1999.
    [9]  P. Calhoun, W. Bulley, "DIAMETER Secure Proxy Extensions",
         draft-calhoun-diameter-proxy-03.txt, Work in Progress,
         October 1999.
    [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)",
         RFC 2406, November 1998.
    [11] S. Bradner, "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.
    [12] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting
         Extension", draft-calhoun-diameter-accounting-00.txt,



Calhoun, Perkins           expires April 2000                  [Page 32]


INTERNET DRAFT                                              October 1999


         IETF Work in Progress, September 1999.
    [13] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
         for Message Authentication.  RFC 2104, February 1997.
    [14] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
         1996.
    [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP",
         draft-ietf-mobileip-aaa-keys-00.txt, IETF Work in Progress,
         June 1999.


8.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com


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

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


9.0  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 implmentation 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



Calhoun, Perkins           expires April 2000                  [Page 33]


INTERNET DRAFT                                              October 1999


   way, such as  by  removing  the copyright notice or references to the
   Internet Society or other Inter- net organizations, except as needed
   for  the  purpose  of  developing 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 limited permis- sions granted
   above are perpetual and  will  not  be  revoked  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
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY  WAR- RANTY  THAT  THE  USE  OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS  FOR  A PARTICULAR PURPOSE."





































Calhoun, Perkins           expires April 2000                  [Page 34]