Diameter Maintenance and                                    J. Bournelle, Ed. Bournelle
Extensions (DIME)                                                GET/INT                                     France Telecom R&D
Internet-Draft                                               G. Giaretta
Intended status: Standards Track                          Telecom Italia                                Qualcomm
Expires: November 4, December 31, 2007                                 H. Tschofenig
                                                  Nokia Siemens Networks
                                                             M. Nakhjiri
                                                                  Huawei
                                                             May 3,
                                                           June 29, 2007

    Diameter Mobile IPv6: HA <-> HAAA Support
                     draft-ietf-dime-mip6-split-02 for Home Agent to Diameter Server
                              Interaction
                   draft-ietf-dime-mip6-split-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on November 4, December 31, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   In a

   Mobile IPv6 deployment the need for deployments may want to bootstrap their operations
   dynamically based on an interaction between the Home Agent, Agent and the AAA infrastructure
   Diameter server of the Mobile Service Provider
   (MSP) and the Mobility Service Authorizer (MSA) has been identified. (MSP).  This document describes
   that specifies the interaction between the Home Agent and the
   Diameter server.  Two different mechanisms for authentication of a new MN
   to the HA are supported.  The first method consists of performing the
   Internet Key Exchange v2 (IKEv2) protocol along with the Extensible
   Authentication Protocol (EAP) with the Diameter application, called server, while the
   second method utilizes the Mobile IPv6 Authorization Application, used Authentication option, as
   defined in conjunction RFC 4285.  For Internet Key Exchange v2 with EAP-based
   authentication, the Diameter
   EAP Application is used to perform the necessary AAA functions before
   executing Mobile IPv6 services.  This document also specifies the
   role of application, defined in this
   document, reuses the Home Agent as part of commands defined in the AAA infrastructure Diameter EAP
   application, while for supporting the RFC 4285-style MIPv6
   Authentication Options, a new Diameter application is defined that
   reuses the Diameter Mobile IPv6 Authorization Application. IPv4 application.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Diameter MIP6 HA-to-AAAH Overview  .  Advertising Application Support  . . . . . . . . . . . . .  4
   4.  Diameter Mobile IPv6 HA-to-AAAH Support . .  3
   4.  Overview . . . . . . . . .  5
     4.1.  Authentication . . . . . . . . . . . . . . . . . .  4
   5.  Protocol Description . . . .  6
       4.1.1.  HA with EAP Support . . . . . . . . . . . . . . . . .  6
       4.1.2.  HA without EAP  5
     5.1.  Support for Mobile IPv6 with IKEv2 and IPsec . . . . . . .  5
     5.2.  Support for the Mobile IPv6 Authentication Protocol  . . .  7
     5.3.  Mobile IPv6 Session Management . . . . . .  8
     4.2.  Authorization . . . . . . . .  8
       5.3.1.  Session-Termination-Request Command  . . . . . . . . .  8
       5.3.2.  Session-Termination-Answer Command . . . . .  8
     4.3.  Accounting . . . . .  8
       5.3.3.  Abort-Session-Request Command  . . . . . . . . . . . .  8
       5.3.4.  Abort-Session-Answer Command . . . . . . .  9
     4.4.  Mobile IPv6 Session Management . . . . . .  9
   6.  Command-Code and AVP Values  . . . . . . . .  9
       4.4.1.  Session-Termination-Request Command . . . . . . . . .  9
       4.4.2.  Session-Termination-Answer
     6.1.  Command Code for EAP-based Authentication  . . . . . . . .  9
       6.1.1.  Diameter-EAP-Request (DER) . .  9
       4.4.3.  Abort-Session-Request Command . . . . . . . . . . . .  9
       4.4.4.  Abort-Session-Answer Command
       6.1.2.  Diameter-EAP-Answer (DEA)  . . . . . . . . . . . . . . 10
   5.  Command-Code Values
     6.2.  Command Codes for RFC 4285 Support . . . . . . . . . . . . 10
       6.2.1.  MIP6-Request-Message . . . . . . . . . 10
     5.1.  MIP6-Authorization-Request . . . . . . . . . . . . . . . 11
       6.2.2.  MIP6-Answer-Message  . 10
     5.2.  MIP6-Authorization-Answer . . . . . . . . . . . . . . . . 10
   6.  Result-Code 11
       6.2.3.  Diameter AVPs  . . . . . . . . . . . . . . . . . . . . . . . 10 12
   7.  Mandatory AVPs . . . .  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 10
   8.  Accounting AVPs . 14
     7.1.  Command Codes  . . . . . . . . . . . . . . . . . . . . . . 11
   9. 14
     7.2.  Result-Code AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 11
   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Authentication Token . . . . . . . . . . . . . . . Values . . . . 11
     10.2. HA as a Single Physical Device . . . . . . . . . . . . . . 11
     10.3. Triggering the MIP6 Authorization 15
     7.3.  Application  . . . . . . 11
     10.4. RFC4285 Support  . . . Identifier . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   14. 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     14.1. 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     14.2. 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 15 18

1.  Introduction

   With

   Performing the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned requires assignment of a
   Home Agent which is in charge of relaying IPv6 packets destined to
   MN's Home Address (HA) to the MN's current address.  Moreover, the a Mobile Node and its Home Agent (HA) must share IPsec Security Associations (MN).  The MN needs to protect register its
   Mobile IPv6 signalling.  Note that session with the HA in order facilitate its reachability
   and mobility, when away from home.

   From an operator (mobility service provider, MSP) perspective, it is possible to use
   another method than IPsec
   important to secure signalling messages, but in this
   document, only IPsec is considered.  One of verify that the problem MN is to
   dynamically set-up these Security Associations authenticated and authorized to assign the Home
   Agent Address
   utilize Mobile IPv6 service and the Home Address that such services are accounted for.
   Thus, prior to the Mobile Node.  This problem
   is known as processing the Mobile IPv6 bootstrapping problem and is detailed in
   [2].  Two possible bootstrapping scenarios have been identified,
   namely the Integrated and the Split Scenario.  With the Integrated
   Scenario (see [3]), the Home Agent Address is delivered during service requests, the
   process of network access authentication, while HA,
   participates in the Split scenario
   (see [4]), the Home Agent information is discovered using the DNS
   infrastructure.  In both cases, the Mobile Node has the Home Agent
   information and it interacts with authentication of the Home Agent using IKEv2 [5].

   From an operator perspective, it is important MN to verify that the user
   (MN) is authorized to utilize Mobile IPv6 service and that such
   services are accounted for. MN's
   identity.  The Home Agent, while verifying the
   user's identity, HA also participates in the Mobile IPv6 authorization
   process and involving the Diameter infrastrucure.  The HA due to its role
   in traffic forwarding forwarding, also performs accounting for this service.  For this reason, it is important for the Home
   Agent Mobile IPv6
   service provided to act as part of the service provider's AAA infrastructure. MN.

   Mobile IPv6 specifications allow two different methods for MN
   authentication, one based on IKEv2 and EAP [2], and another based on
   the Mobile IPv6 Authentication Option [3].  The goal of this document
   is to specify a new Diameter application,
   called Diameter Mobile IPv6 Authorization Application specifying the
   authorization and accounting Diameter procedures associated for with the Mobile IPv6
   service.  Furthermore,
   bootstrapping between the document specifies HA and the role of Home Agent
   as a Diameter client to support this application.  This modular
   approach provides flexibility server for the choice of authentication in
   conjunction with these two
   Mobile IPv6 services. IP authentication approaches.

   For instance, that reason the HA can use Diameter Mobile IPv6 application provides two
   different sets of commands.  The first set of commands reuse the
   command already define in Diameter EAP Application [6] or other procedures application (though using the
   Diameter Mobile IPv6 Application-Id).  While the second set of
   commands are new for performing
   authentications through a Diameter server.  Note that this
   application can be used both in Integrated and Split scenarios.

2.  Terminology

   The key words "MUST", "MUST NOT", provide support the Mobile IPv6
   Authentication Option, defined in RFC 4285.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [7]. [4].

   The MIPv6 bootstrapping terminology is taken from [2]. [5].

3.  Advertising Application Support

   Diameter MIP6 HA-to-AAAH nodes conforming to this specification MUST advertise
   support by including the Diameter Mobile IPv6 Application ID value of
   [TO BE ASSIGNED BY IANA] in the Auth-Application-Id AVP of the
   Capabilities-Exchange-Request and Capabilities-Exchange-Answer
   command [6]

4.  Overview

   The Home Agent offers

   One task of the Mobile IPv6 service bootstrapping procedure is to assign an
   appropriate HA to the MN.  Furthermore, authorization and successful
   delivery of Mobile Node. IPv6 to a MN through a HA, requires the HA to act
   as a client to the Diameter infrastructure interconnecting it to the
   MSP.  As a Diameter client, the delivered Home Agent performs HA needs to perform the following
   operations:

   Authentication:  The Home Agent must verify  Asserting or helping in assertion of the identity correctness
      of the user
      provided in MN identity.  As a Diameter client supporting the IKEv2 exchange. new
      Diameter Mobile IPv6 application, the HA may need to support two
      different types of authentication by supporting the different
      command sets that are required for each authentication method.

   Authorization:  The Home Agent HA must verify that the user is authorized to use
      the Mobile IPv6 service. service using the assistance of the MSP Diameter
      servers.  This is accomplised through use of new Diameter commands
      specifically designed for performing Mobile IPv6 authorization
      decisions.  This document defines these commands and requires the
      HA to support use of these authorization commands and to
      participate in this authorization signaling.

   Accounting:  For billing purposes and capacity planning, it is
      required of the Home
      Agent provides HA to provide accounting report to the AAA infrastructure. Diameter
      infrastructure and thus to support the related Diameter accounting
      procedures.

   Figure 1 shows the architecture of depicts the solution described in this
   document. architecture.

        +---------------------------+  +-----------------+
        |Visited MSP                                MSA                |  | Home MSP/MSA    |
        |                           |  |                 |
        |                           |  |                 |
        | +--------+                      +-------------+
    +--+  IKEv2 +--+                |    Diameter EAP  |    +--------+   |
    |MN|<------>|HA|<-------------------------->|AAAH-EAP|
        |
    +--+ |Local   |      Diameter  |  |    |Home    |   |
        | |Diameter|<---------------------->|Diameter|   |
        | |Proxy   |                |  |    |Server  |   |
        | +--------+                | +--+   |(AUTHENTICATE_ONLY)  |    +--------+   |
        |     ^                     |  |        ^        |
        |     |                     |  |        |        |
        |     | Diameter MIP6 Authz/Acc            | +---------+  |Diameter|        |
        |   +---------------------------->|AAAH-MIP6|     v                     |  |        v        |
        | +---------+ +-------+                 |
              +--------+                      +-------------+

                      Figure 1: Architecture Overview

   For the authentication part, it is likely that operators will use EAP
   within  |     +-------+   |
        | |Home   |                 |  |     |Home   |   |
        | |Agent  |                 |  |     |Agent  |   |
        | +-------+                 |  |     +-------+   |
        |     ^                     |  |        ^        |
        +-----|---------------------+  +--------|--------+
              |                                 |
              |                                 |
              |          +---------+            |
              |          | Mobile  |            |
              +--------->| Node    |<-----------+
       IKEv2 to authenticate or RFC 4285 +---------+ IKEv2 or RFC 4285

                      Figure 1: Architecture Overview

   [Editor's Note: A description of the user since it is relationship with the easiest way for
   operator to leverage their AAA infrastructure front-end
   protocols is needed.]

5.  Protocol Description

5.1.  Support for Mobile IPv6 with IKEv2 initiator
   authentication. and IPsec

   The Diameter EAP Application [6] is the application
   that permits carrying EAP packets use of IKEv2 between an access device the MN and a AAA
   server.  However, this application is primarly defined the HA allows the HA to perform AAA
   operations for network access service and not for Mobile IPv6
   service.  For this reason, it is recommended that, when EAP is used
   for authentication,
   authenticate the Diameter MN.  When EAP application will be is used only
   for Authentication purpose.  This implies that the Home Agent will
   use with IKEv2, the Diameter EAP Application
   application, as defined in "AUTHENTICATE_ONLY" mode.  This
   is realized by setting the Auth-Request-Type AVP to
   AUTHENTICATE_ONLY.  In this document, the AAA server contacted for
   Authentication [7], is called AAAH-EAP.  This server belongs re-used.  AVPs specific to the MSA.

   To explicitely authorize the Mobile IPv6 service, in this document,
   we define a new Diameter application, called Mobile
   IPv6
   Authorization Application.  The application requires two new
   messages, namely: MIP6-Authorization-Request (MAR) and MIP6-
   Authorization-Answer (MAA).  The HA, acting as a Diameter client for bootstrapping are added to this new application, sends a MIP6-Authorization-Request message
   containing identity of command.

   Figure 2 shows the user to message flow involved during the Mobility service authorizer
   (e.g., HAAA for MIP6 service) to verify that this user authentication
   phase when EAP is authorized
   to use used.

     Mobile IPv6 service.  This message is sent towards                  Home                    Diameter
   server called AAAH-MIP6 in this document.  This server belongs to the
   MSA.

   This message may also contain some specific authorization AVPs
   concerning Home-Address Allocation and Home-Address DNS registration.
     Node                    Agent                   Server
     ------                  -----                   --------
            IKE_SA_INIT     (1,2)
   <------------------------------>

   HDR, SK{IDi,[CERTREQ,] [IDr,]
           [CP(CFG_REQUEST),]
            SAi2, TSi, TSr}  (3)
   ------------------------------->
                                    DER (EAP-Response) (4)
                                    ------------------------>
                                       DEA (EAP-Request) (5)
                                    <------------------------
    HDR, SK {IDr, [CERT,] AUTH,
             EAP }
   <-------------------------------
    HDR, SK {EAP}
   -------------------------------->
                                    DER (EAP-Response)
                                    ------------------------>
                                       DEA (EAP-Request)
                                    <------------------------
    HDR, SK{EAP-Request}
   <-------------------------------
    HDR, SK{EAP-Response}
   -------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
             ...                           ...

                                       DEA (EAP-Success)
                                    <------------------------
    HDR, SK{EAP-Success}
   <-------------------------------
    HDR, SK{AUTH}
   ------------------------------->
    HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr }
   <-------------------------------

                 Figure 2: IKEv2 Diameter EAP Message Flow

   The response is contained in the MIP6-Authorization-Answer.  As this
   application needs a new Application-Id [[[To Be assigned by IANA]]],
   it has to be noted that the Mobile IPv6 authorization requests may be
   routed to a different AAA server (AAAH-MIP6) than the AAA server used
   for Authentication request (AAAH-EAP).

   When the verification of user authorization to receive Mobile IPv6
   service is complete, MN and the Home-Agent HA start performing Accounting
   operation by sending accounting message (ACR) with the AVP Acct-
   Application-ID set to [[[To Be Assigned by IANA]]].  These messages
   contain specific Mobile IPv6 AVPs interaction with an IKE_SA_INIT exchange.
   In this phase cryptographic algorithms are negotiated, nonces and
   Diffie-Hellman parameters are sent to the AAAH-MIP6.

4.  Diameter Mobile IPv6 HA-to-AAAH Support

   Although exchanged.  Message (3) starts the main goal of this document is to specify
   IKE_AUTH phase.  This second phase authenticates the
   authorization previous
   messages, exchanges identities and accounting for Mobile IPv6 application, certificates and establishes the intent
   first CHILD_SA.  It is also used to provide guidance on the AAA operations expected from HA.
   Hence, this document provides guidance on mutually authenticate the procedures required
   from MN (acting
   as an IKEv2 Initiator) and the HA (acting as part an IKEv2 Responder).
   The identity of the authentication process.  As EAP user/MN is
   considered as a strong choice provided in performing authentication, this
   document explains the use of Diameter IDi field.  The MN
   indicates its willingness to be authenticated via EAP application by omitting the
   AUTH field in cases where message 3 (see [8]).

   As part of the prior authentication between process, the MN and HA is done through use of
   EAP.  Therefore, MAY request a Home-
   Address, a Home Prefix or suggests one, see [9], using a CFG_REQUEST
   payload in the message 3.

   The HA performs AAA operations for Mobile IPv6 by
   using two Diameter Applications, namely: Diameter EAP[6] extracts the IDi field from the message 3 and sends a
   Diameter-EAP-Request (DER) message towards the authenticating
   Diameter
   Mobile IPv6 (specified by this document).

   If EAP server.

   This message is used within IKEv2, the HA uses routed to the procedures of MNs Diameter server/EAP server.  The
   Diameter server selects the EAP application (DER/DEA) method and replies with the Auth-Request-Type set to
   AUTHENTICATE_ONLY.

4.1.  Authentication

   As mentioned before, prior to performing authorization process, the
   HA must authenticate DEA
   Message.  Depending on the user.  The use type of IKEv2 EAP method chosen, a number of DER
   and DEA messages carry the method specific exchanges between the MN
   and the HA allows Diameter server/EAP server.

   At the HA to authenticate end of the Mobile Node.  Traditional
   IKE EAP authentication procedures require existence of pre-shared secrets
   or certificates between MN and HA.  However, given phase, the possible lack Diameter server
   indicates the result of prior knowledge between MN and HA, the more desired approach is to
   use EAP authentication in the Result-Code AVP and
   provides the AAA infrastructure to authenticate corresponding EAP packet (EAP Success or EAP Failure).
   The last IKEv2 message sent by the user during
   IKEv2.

4.1.1. HA with EAP Support

   Figure 2 shows contains the message flow involved during Home Address or
   the authentication
   phase when EAP Home Prefix.  In the latter case, a CREATE_CHILD_SA exchange is used.
   necessary to setup IPsec SAs for Mobile Node          HA/Diameter Client    Home AAA/EAP Server(AAAH-EAP)
----------            -----------------       -------------------
         IKE_SA_INIT     (1,2)
<------------------------------>

HDR, SK{IDi,[CERTREQ,] [IDr,]
        [CP(CFG_REQUEST),]
         SAi2, TSi, TSr}  (3)
------------------------------->
                                 DER (EAP-Response)(AUTHENTICATE_ONLY)
                                 ------------------------>
                                    DEA (EAP-Request)
                                 <------------------------
 HDR, SK {IDr, [CERT,] AUTH,
          EAP }
<-------------------------------
 HDR, SK {EAP}
-------------------------------->
                                 DER (EAP-Response)(AUTHENTICATE_ONLY)
                                 ------------------------>
                                    DEA (EAP-Request)
                                 <------------------------
 HDR, SK{EAP-Request}
<-------------------------------
 HDR, SK{EAP-Response}
-------------------------------->
                                    DER (EAP-Response)
                                 ------------------------>
          ...                           ...

                                    DEA (EAP-Success)
                                 <------------------------
 HDR, SK{EAP-Success}
<-------------------------------
 HDR, SK{AUTH}
------------------------------->
 HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr }
<-------------------------------

                 Figure 2: IKEv2 Diameter EAP Message Flow

   The MN and IPv6 signalling.

   In some deployment scenario, the HA start may also acts as a IKEv2
   Responder for IPsec VPN access.  A problem in this case is that the interaction with an IKE_SA_INIT exchange.
   In
   IKEv2 responder may not know if IK Ev2 is used for MIP6 service or
   for IPsec VPN access.  A network operator needs to be aware of this phase cryptographic algorithms are negotiated, nonces and a
   Diffie-Hellman parameters are exchanged.  Message (3) starts
   limitation.

5.2.  Support for the
   IKE_AUTH phase.  This second phase authenticates Mobile IPv6 Authentication Protocol

   Figure 3 describes the previous
   messages, exchanges identities sequence of messages sent and certificates received between
   the MN, the HA and establishes the
   first CHILD_SA.  It Diameter server during the registration when
   RFC 4285 is used.  Binding Update (BU) and Binding Acknowledgement
   (BA) messages are used in the registration process.  This exchange
   triggers the Diameter interaction.

   According to mutually authenticate [3] the MN uses the Mobile Node
   (acting Identifier Option,
   specifically the MN-NAI mobility option as an IKEv2 Initiator) and defined in [11] to
   identify itself while authenticating with the Home Agent (acting as an IKEv2
   Responder). HA.

   The identity of the User/Mobile Node is provided in MN may use the
   field IDi. Message Identifier option for additional replay
   protection.  The Mobile Node indicates its willingness to authentication option may be
   authenticated by EAP used by omitting the field AUTH in message 3 (cf.
   [5]).  The Mobile Node authenticates MN to
   transfer authentication data when the Home Agent by requesting a
   certificate.  This is done by including MN and the field [CERTREQ] in
   message 3.

   As part of HA are utilizing a
   mobility SPI.

   The BU initiates a MIP6-Request-Message to the authentication process, Diameter server and
   the Mobile Node MAY request a
   Home-Address, corresponding response is carried in a MIP6-Answer-Message.

     Mobile                                Home Prefix                   AAA
     Node                                  Agent                 Server
       |                                     |                     |
       |                                     |                     |
       |       Binding Update                |MIP6-Request-Message |
    (a)|------------------------------------>|-------------------->|
       | (including MN-ID option,            |                     |
       |  Message ID option [optional],      |                     |
       |  authentication option)             |                     |
       |                                     |                     |
       |                                     |                     |
       |       Binding Acknowledgement       |MIP6-Answer-Message  |
    (b)|<------------------------------------|<--------------------|
       | (including MN-ID option,            |  (MN-HA key)        |
       |  Message ID option [optional],      |                     |
       |  authentication option)             |                     |

               Figure 3: MIPv6 Bootstrapping using RFC 4285

5.3.  Mobile IPv6 Session Management

   The Diameter server may maintain state or suggests one [4]. may be stateless.  This is done by
   using a CFG_REQUEST payload
   indicated in the message 3. Auth-Session-State AVP (or its absence).  The Home Agent extracts the IDi field from the message 3 and sends a
   Diameter-EAP-Request message towards HA
   MUST support the authenticating Diameter
   server AAAH-EAP.  The User-Name AVP of Authorization Session State Machine defined in [6].
   Moreover the DER message MUST following 4 commands may be set to exchanged between the IDi field HA and
   the Auth-Request-Type MUST be set to
   AUTHENTICATE_ONLY.  This Diameter server.

5.3.1.  Session-Termination-Request Command

   The Session-Termination-Request (STR) message [6] is routed through sent by the AAA
   infrastructure HA
   to inform the home AAA Diameter server (AAAH-EAP) of this Mobile Node.
   The AAAH-EAP chooses that an authentication method and replies with authorized session is being
   terminated.

5.3.2.  Session-Termination-Answer Command

   The Session-Termination-Answer (STA) message [6] is sent by the
   DEA Message.

   At
   Diameter server to acknowledge the end of notification that the EAP authentication phase, session has
   been terminated.

5.3.3.  Abort-Session-Request Command

   The Abort-Session-Request (ASR) message [6] is sent by the AAAH-EAP indicates Diameter
   server to terminates the result session.  This fulfills one of the authentication
   requirement described in [12].

5.3.4.  Abort-Session-Answer Command

   The Abort-Session-Answer (ASA) message [6] is sent by the Result-Code Home Agent
   in response to an ASR message.

6.  Command-Code and AVP Values

   This section defines the command codes and provides AVP values used by the corresponding
   Diameter Mobile IPv6 application:

  Command-Name                 Abbrev.   Code     Reference  Application
  ----------------------------------------------------------------------
  Diameter-EAP-Request         DER       268      RFC 4072   EAP packet (EAP Success or
  Diameter-EAP-Answer          DEA       268      RFC 4072   EAP Failure).
  MIP6-Request-Message         MRM       XXX      TBD        MIP6
  MIP6-Answer-Message          MAM       XXX      TBD        MIP6

                          Figure 4: Command Codes

6.1.  Command Code for EAP-based Authentication

   This document re-uses the Diameter EAP application commands.  The
   following commands are used to carry MIPv6 related bootstrapping
   AVPs:

   Command-Name             Abbrev.   Code     Reference  Application
   ------------------------------------------------------------------
   Diameter-EAP-Request      DER       268      RFC 4072   EAP
   Diameter-EAP-Answer       DEA       268      RFC 4072   EAP

   Figure 5: Diameter EAP command codes used for MIPv6 Bootstrapping HA
                             to HAAA Interface

   [Editor's Note: The last
   IKEv2 subsections below do not yet show the MIPv6
   specific AVPs.]

6.1.1.  Diameter-EAP-Request (DER)

   The Diameter-EAP-Request (DER) message sent [7], indicated by the Home Agent contains the Home Address or the
   Home Prefix.  In the latter case, a CREATE_CHILD_SA exchange is
   necessary Command-
   Code field set to setup IPsec SAs for Mobile IPv6 signalling.

4.1.2.  HA without EAP Support

   To be completed.

4.2.  Authorization

   Following the successful authentication, 268 and the Home Agent must ensure
   that 'R' bit set in the Mobile Node Command Flags field,
   is authorized sent by the HA to use the Diameter server to initiate a Mobile IPv6 service.
   For this purpose, the Home Agent sends a MIP6-Authorization-Request
   (MAR)
   service authentication and authorization procedure.  The DER message containing identity of the user towards
   format is the AAAH-MIP6. same as defined in [7].  The Application-ID field of this message is
   the Diameter Header MUST be set to the Diameter Mobile IPv6
   Application ID [TO BE ASSIGNED]. ASSIGNED TO IANA].

     <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Origin-Host }
                                { Origin-Realm }
                                { Destination-Realm }
                                { Auth-Request-Type }

                                [ Destination-Host ]
                                ...
                              * [ AVP ]

6.1.2.  Diameter-EAP-Answer (DEA)

   The
   identity is extracted from Diameter-EAP-Answer (DEA) message defined in [7], indicated by
   the IDi Command-Code field provided set to 268 and 'R' bit cleared in the message 3 of
   the IKEv2 exchange.  The home AAA server (AAAH-MIP6) replies with a
   MIP6-Authorization-Answer which contains the result of the
   authorization process.  This latter message MAY contain configuration
   policies Command
   Flags field, is sent in response to be applied at the Home Agent.

   As part of the authorization request for Diameter-EAP-Request message
   (DER).  If the Mobile IPv6 service.
   The Home Agent may require specific authorization for this MN.  As an
   example, it may request if this user is allowed to auto-assign its
   Home-Address.

4.3.  Accounting

   Concerning accounting, the Diameter Mobile IPv4 Application [8]
   defines the following AVPs:

   o  Accounting-Input-Octets: Number of octets in IP packets received
      from the user
   o  Accounting-Output-Octets: Number of octets in IP packets sent by authentication procedure was successful
   then the user
   o  Accounting-Input-Packets: Number response MAY include any set of IP packets received from bootstrapping AVPs.

   The DEA message format is the
      user
   o  Accounting-Output-Packets: Number of IP packets sent by same as defined in [7].  The
   Application-Id field in the user.

   These AVPs may Diameter header MUST be re-used for set to the
   Diameter Mobile IPv6 service.  However, due Application-Id [TO BE ASSIGNED BY IANA].

     <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                               < Session-Id >
                               { Auth-Application-Id }
                               { Auth-Request-Type }
                               { Result-Code }
                               { Origin-Host }
                               { Origin-Realm }

                               [ User-Name ]
                               ...
                             * [ AVP ]

6.2.  Command Codes for RFC 4285 Support

   This section defines Command-Code [6] values that MUST be supported
   by all Diameter implementations conforming to routing optimization techniques introduced with Mobile IPv6 the HA
   does not see the entire traffic exchanged between this specification.
   The following Command Codes are defined in this specification.

      Command-Name             Abbreviation    Code           Section
      ------------------------------------------------------------------
      MIP6-Request-Message         MRM         TBD         Section 6.2.1
      MIP6-Answer-Message          MAM         TBD         Section 6.2.2

6.2.1.  MIP6-Request-Message

   The MIP6-Request-Message (MRM), indicated by the MN Command-Code field
   set to TBD and the CN.

   [Editor's Note: As the document describing goals for this interface
   is not finalized, other parameters may be needed 'R' bit set in the future.]

4.4.  Mobile IPv6 Session Management

   Concerning Mobile IPv6 session, the AAAH (AAAH-MIP6) server may
   maintain state or may be stateless.  This Command Flags field, is indicated in sent by
   the Auth-
   Session-State AVP (or its abscence) HA, acting as a Diameter client, in order to request the MAA message.
   authentication and authorization of a MN.  The Home
   Agent MUST support the Authorization Session State Machine defined HA uses information
   found in
   [9].  Moreover the Binding Update to construct the following 4 commands may AVPs, to be exchanged between
   included as part of the MRM:

   o  Home Agent and Address (MIP6-Home-Address AVP)
   o  Mobile Node NAI (User-Name AVP [6])
   o  MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)

   If the MN's home AAA server.

4.4.1.  Session-Termination-Request Command

   The Session-Termination-Request (STR) message [9] address is sent by zero, the Home
   Agent to inform HA MUST NOT include a MIP6-
   Home-Address AVP.

   If the Diameter server that an authorized session MN's home address is
   being terminated.

4.4.2.  Session-Termination-Answer Command all ones, the HA MUST include a MIP6-
   Home-Address AVP, set to all ones.

   The Session-Termination-Answer (STA) message [9] format is sent shown below:

           <MIP6-Request-Message> ::= < Diameter Header: 260, REQ, PXY >
             < Session-ID >
             { Auth-Application-Id }
             { User-Name }
             { Destination-Realm }
             { Origin-Host }
             { Origin-Realm }
             [ Acct-Multi-Session-Id ]
             [ Destination-Host ]
             [ Origin-State-Id ]

             { MIP-MN-AAA-Auth }
             [ MIP6-Home-Address ]

             [ Authorization-Lifetime ]
             [ Auth-Session-State ]
             * [ Proxy-Info ]
             * [ Route-Record ]
             * [ AVP ]

6.2.2.  MIP6-Answer-Message

   The MIP6-Answer-Message (MAM) message, indicated by the
   Diameter server Command-Code
   field set to acknowledge TBD and the notification that 'R' bit cleared in the session has
   been terminated.

4.4.3.  Abort-Session-Request Command

   The Abort-Session-Request (ASR) message [9] Flags field,
   is sent by the Diameter server in response to terminates the session.  This fulfills MIP6-Request-
   Message message.  The User-Name MAY be included in the MAM if it is
   present in the MRM.  The Result-Code AVP MAY contain one of the
   requirement described
   values defined in [11].

4.4.4.  Abort-Session-Answer Command

   The Abort-Session-Answer (ASA) message [9] is sent by Section 6.2.3.2, in addition to the Home Agent values defined
   in response RFC 3588 [6].

   An MAM message with the Result-Code AVP set to an ASR message.

5.  Command-Code Values

   This section defines Command-Code [9] value that DIAMETER_SUCCESS MUST be supported by
   all Diameter implementations conforming
   include the MIP-Mobile-Node-Address AVP.  The MIP-Home-Agent-Address
   AVP contains the HA assigned to this specification. the MN, while the MIP-Mobile-Node-
   Address AVP contains the home address that was assigned.

   The message format is shown below:

      <MIP6-Answer-Message> ::= < 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-MN-to-HA-MSA ]
               [ MIP-HA-to-MN-MSA ]
               [ MIP-MSA-Lifetime ]
               [ MIP6-Home-Address ]

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

6.2.3.  Diameter AVPs

   The Diameter client uses AVPs dependent on the usage of RFC 4285 [3]
   or RFC 4877 [2].

   To provide support for RFC 4285 [3] the following Command Codes are AVPs defined in
   [10] are reused in this specification:

           Command-Name               Abbreviation  Code   Section
           ---------------------------------------------------------
           MIP6-Authorization-Request      MAR      TBD
           MIP6-Authorization-Answer       MAA      TBD

                                 Figure 3

5.1.  MIP6-Authorization-Request

   The MIP6-Authorization-Request (MAR), indicated by the Command-Code
   field set to TBD and application:
   o  MIP-HA-to-MN-MSA AVP
   o  MIP-MN-to-HA-MSA AVP
   o  MIP-Session-Key AVP
   o  MIP-Algorithm-Type AVP
   o  MIP-Replay-Mode AVP
   o  MIP-MN-AAA-Auth AVP
   o  MIP-MN-AAA-SPI AVP
   o  MIP-Auth-Input-Data-Length AVP
   o  MIP-Authenticator-Length AVP
   o  MIP-Authenticator-Offset AVP
   o  MIP-MSA-Lifetime AVP
   o  MIP-Mobile-Node-Address (with an IPv6 address)

   For usage with the 'R' bit set in RFC 4877 [2] only the Command Flags field MIP-Mobile-Node-Address AVP
   (with IPv6 address) is
   sent needed since all other keying related
   parameters are provided by the Home Agent acting as a Diameter Client. EAP application.

6.2.3.1.  Accounting AVPs

   This message is
   used by document reuses the Home-Agent to authorize accounting AVPs defined in Diameter Mobile
   IPv4 application [10], namely:

   Accounting-Input-Octets:

      Number of octets in IP packets received from the Mobile IPv6 service.

5.2.  MIP6-Authorization-Answer

   The MIP6-Authorization-Answer (MAA), indicated user
   Accounting-Output-Octets:

      Number of octets in IP packets sent by the Command-Code
   field set to TBD and the 'R' bit cleared in user
   Accounting-Input-Packets:

      Number of IP packets received from the Command Flags field
   is user
   Accounting-Output-Packets:

      Number of IP packets sent by the AAAH (AAAH-MIP6) in response to MIP6-Authorization-
   Request.

6. user.

6.2.3.2.  Result-Code AVPs

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

   To be completed.

7.  Mandatory AVPs

   To be completed.

8.  Accounting AVPs

   To be completed.

9.

   [Editor's Note: This section needs to list the result codes that are
   used by this application.]

6.2.3.3.  AVP Occurence Tables

   To be completed.

10.  Open Issues

10.1.  Authentication Token

   Authentication and Authorization/Accounting process may be handled by
   two different AAA servers, namely AAAH-EAP and AAAH-MIP6.  As such,
   the AAAH-MIP6 does not know if the MN has been correctly
   authenticated before authorizing the service.

   The issue is to know wether we need to provide a proof to the AAAH-
   MIP6 that following table describes the MN is correctly authenticated Diameter AVPs defined by AAAH-EAP

10.2.  HA as a Single Physical Device

   The HA acts as a IKEv2 responder with this
   document; their AVP Code values, types, and possible flag values; and
   whether the MN.  As such, it can AVP MAY be
   colocated encrypted.

6.2.3.3.1.  Support for Mobile IPv6 with a VPN concentrator.

   The issue is how IKEv2 and IPsec

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            +----+-----+----+-----+----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
  +-----------------------------------------+----+-----+----+-----+----+
  |MIP-Mobile-                              |    |     |    |     |    |
  |Node-Address      TBD TBD Host-IP-Address| M  |  P  |    |  V  | Y  |
  +-----------------------------------------+----+-----+----+-----+----+

6.2.3.3.2.  Support for the Mobile IPv6 Authentication Protocol

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            +----+-----+----+-----+----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
  +-----------------------------------------+----+-----+----+-----+----+
  |MIP-MN-AAA-Auth  322 RFC4004  Grouped    | M  |  P  |    |  V  | Y  |
  |MIP-Auth-Input-  338 RFC4004  Unsigned32 | M  |  P  |    |  V  | Y  |
  |  Data-Length                            |    |     |    |     |    |
  |MIP-             339 RFC4004  Unsigned32 | M  |  P  |    |  V  | Y  |
  |  Authenticator-Length                   |    |     |    |     |    |
  |MIP-             340 RFC4004  Unsigned32 | M  |  P  |    |  V  | Y  |
  |  Authenticator-Offset                   |    |     |    |     |    |
  |MIP-MN-AAA-SPI   341 RFC4004  Unsigned32 | M  |  P  |    |  V  | Y  |
  |MIP-Mobile-                              |    |     |    |     |    |
  |Node-Address      TBD TBD Host-IP-Address| M  |  P  |    |  V  | Y  |
  +-----------------------------------------+----+-----+----+-----+----+

7.  IANA Considerations

   This section contains the HA know namespaces that the MN want MIP6 service.

10.3.  Triggering the MIP6 Authorization Application

   If EAP is used have either been created in
   this specification or had their values assigned to authenticate the MN, existing
   namespaces managed by IANA.

7.1.  Command Codes

   This specification reuses the HA uses two applications
   to perform AAA operations: Diameter EAP values 260 and 262 from the MIP6 Authorization
   Application.

   The issue is to know when Command
   Code namespace defined in [6].  See Section 6 for the MIP6 Authorization Application must be
   used by assignment of
   the HA. namespace in this specification.

7.2.  Result-Code AVP Values

   This issue is tied with the "HA as a single box" one.  If specification assigns the only
   way for values TBD - TBD from the HA to know that it was for mip6 is to wait Result-Code
   AVP (AVP Code 268) value namespace defined in [6].  See
   Section 6.2.3.2 for a BU from the MN, then assignment of the namespace in this
   specification.

7.3.  Application can be used only after the reception of Identifier

   This specification uses the BU.  However, if we want value TBD to do HoA-Allocation authorization by
   the AAAH-MIP6, this implies that the application must be used before Application Identifier
   namespace defined in [6].

8.  Security Considerations

   The security considerations for the end of Diameter interaction required to
   accomplish the IKEv2 exchange and thus before split scenario are described in in [9].  Additionally,
   the BU reception

10.4.  RFC4285 Support

   This document deals with security considerations of the HA-to-AAAH support in case IKEv2 is used
   to setup IPsec SAs between MN and HA Diameter Base protocol [6],
   Diameter EAP application [7] are applicable to secure Mobile IPv6
   signalling.

   The issue is wether support for RFC 4285 mechanism should also be
   handled by this document.

11.  IANA Considerations

   To be completed.

12.  Security Considerations

   To be completed.

13.  This
   document does not introduce new security vulnerabilities.

9.  Acknowledgements

   The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi
   Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen,
   Avi Lior, John Loughney, Lionel Morand.  The authors would
   particularly like to thank Yoshihiro Ohba for suggesting the idea of
   creating a specific authorization application for Mobile IPv6 Ahmad Muhanna and to
   use Diameter EAP Lionel Morand and
   Yoshihiro Ohba for all the authentication part.

   The authors useful discussions.  Jouni Korhonen
   provided a detailed draft review in June 2007.

   Hannes Tschofenig would like to thank the European Commission support
   in the co-funding of the ENABLE project, where this work is partly
   being developed.

   Julien Bournelle would like to thank Orange-FT which partly funded GET/INT since he began this work.

14. work
   while he was under their employ.

10.  References

14.1.

10.1.  Normative References

   [1]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [2]   Patel, A.   Devarapalli, V. and G. Giaretta, "Problem Statement for bootstrapping
         Mobile F. Dupont, "Mobile IPv6 (MIPv6)", RFC 4640, September 2006.

   [3]   Chowdhury, K. Operation with
         IKEv2 and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-03 (work in
         progress), Revised IPsec Architecture", RFC 4877,
         April 2007.

   [4]   Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-04 (work in progress),
         December 2006.

   [5]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [6]   Eronen, P., Hiller, T.,

   [3]   Patel, A., Leung, K., Khalil, M., Akhtar, H., and G. Zorn, "Diameter Extensible
         Authentication K. Chowdhury,
         "Authentication Protocol (EAP) Application", for Mobile IPv6", RFC 4072,
         August 2005.

   [7] 4285,
         January 2006.

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

   [8]   Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,

   [5]   Patel, A. and P.
         McCann, "Diameter G. Giaretta, "Problem Statement for bootstrapping
         Mobile IPv4 Application", IPv6 (MIPv6)", RFC 4004,
         August 2005.

   [9] 4640, September 2006.

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

   [10]  Calhoun,

   [7]   Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
         Authentication Protocol (EAP) Application", RFC 4072,
         August 2005.

   [8]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [9]   Giaretta, G., Spence, D., "Mobile IPv6 bootstrapping in split scenario",
         draft-ietf-mip6-bootstrapping-split-05 (work in progress),
         May 2007.

   [10]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and D. Mitton, P.
         McCann, "Diameter
         Network Access Server Mobile IPv4 Application", RFC 4005, 4004,
         August 2005.

14.2.

10.2.  Informative References

   [11]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
         "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
         RFC 4283, November 2005.

   [12]  Giaretta, G., "AAA Goals for Mobile IPv6",
         draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
         September 2006.

   [12]  Alfano, F., "Diameter Quality of Service Application",
         draft-tschofenig-dime-diameter-qos-01 (work in progress),
         October 2006.

   [13]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
         Loughney, "Diameter Credit-Control Application", RFC 4006,
         August 2005.

   [14]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in
         progress), June 2007.

Authors' Addresses

   Julien Bournelle (editor)
   GET/INT
   9
   France Telecom R&D
   38-4O rue Charles Fourier
   Evry  91011 du general Leclerc
   Issy-Les-Moulineaux  92794
   France

   Email: julien.bournelle@int-evry.fr julien.bournelle@orange-ftgroup.com

   Gerardo Giaretta
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   TORINO,   10148
   Italy
   Qualcomm

   Email: gerardo.giaretta@telecomitalia.it gerardo.giaretta@gmail.com

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com

   Madjid Nakhjiri
   Huawei USA
   12040, 98th AVE NE, suite 200B
   Kirkland, WA  98033
   USA

   Email: mnakhjiri@huawei.com
   URI:

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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

Intellectual Property

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

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

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).