Diameter Maintenance and                              J. Bournelle (Ed.)
Extensions (DIME)                                                GET/INT
Internet-Draft                                               G. Giaretta
Expires: December 21, 2006
Intended status: Standards Track                          Telecom Italia
Expires: April 25, 2007                                    H. Tschofenig
                                           Siemens
                                                           June 19, Networks GmbH & Co KG
                                                             M. Nakhjiri
                                                                  Huawei
                                                        October 22, 2006

     Mobile IPv6 Bootstrapping using

                Diameter in the Split Scenario
                     draft-ietf-dime-mip6-split-00 Mobile IPv6: HA-to-AAAH support
                     draft-ietf-dime-mip6-split-01

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 December 21, 2006. April 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In a Mobile IPv6 deployment a the need for an interaction between the
   Home Agent, the AAA infrastructure of the Mobile Service Provider
   (MSP) and the Mobility Service Authorizer (MSA) has been identified.

   This document describes how a new Diameter can be application, called Mobile
   IPv6 Authorization Application, used in conjunction with the Diameter
   EAP Application is used to perform AAA
   functionalities for the necessary AAA functions before
   executing Mobile IPv6 service in the "split" scenario.

   For this, it describes two possible approaches.  It services.  This document also explains how
   Diameter meet specifies the goals outlined in
   role of the Home Agent as part of the MIPv6 AAA goals document. infrastructure supporting
   the Diameter Mobile IPv6 Authorization Application.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Bootstrapping Mobile IPv6 in the Split Scenario  Diameter MIP6 HA-to-AAAH Overview  . . . . . . .  3 . . . . . . .  4
   4.  Use of  Diameter EAP for the Mobile IPv6 Split Scenario HA-to-AAAH Support  . . . . . . . . . . .  5
     4.1.  NAS-Port-Type AVP  Authentication . . . . . . . . . . . . . . . . . . . .  6
     4.2.  A new Application ID . .  6
       4.1.1.  HA with EAP Support  . . . . . . . . . . . . . . . . .  6
     4.3.  Accounting for the Mobile IPv6 Service
       4.1.2.  HA without EAP Support . . . . . . . . . .  6
   5.  Goals . . . . . .  8
     4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  General goals  8
     4.3.  Accounting . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  G1.1 - G1.4 Security . .  9
     4.4.  Mobile IPv6 Session Management . . . . . . . . . . . . . .  9
       4.4.1.  Session-Termination-Request Command  .  7
       5.1.2.  Dead peer detection - the HA-AAA interface SHOULD
               support inactive peer detection. . . . . . . . .  9
       4.4.2.  Session-Termination-Answer Command . . .  7
     5.2.  Service Authorization . . . . . . .  9
       4.4.3.  Abort-Session-Request Command  . . . . . . . . . . .  8
       5.2.1.  G2.1. The HA-AAA interface SHOULD allow the use of
               Network Access Identifier (NAI) to identify the
               mobile node. .  9
       4.4.4.  Abort-Session-Answer Command . . . . . . . . . . . . . 10
   5.  Command-Code Values  . . . . . . .  8
       5.2.2.  G2.2. The HA SHOULD be able to query the AAAH
               server to verify Mobile IPv6 service authorization
               for the mobile node. . . . . . . . . . . . . . . 10
     5.1.  MIP6-Authorization-Request . . .  8
       5.2.3.  G2.3. The AAAH server SHOULD be able to enforce
               explicit operational limitations and authorization
               restrictions on the HA.( e.g. packet filters, QoS
               parameters). . . . . . . . . . . . . . 10
     5.2.  MIP6-Authorization-Answer  . . . . . . . .  8
       5.2.4.  G2.4 - G2.6. Issues addressing the maintenance of
               a Mobile IPv6 session by the AAAH server, e.g.
               authorization lifetime, extension of the
               authorization lifetime and explicit  session
               termination by the AAAH server side. . . . . . . . . 10
   6.  Result-Code AVPs .  8
     5.3.  Accounting - G3.1. The HA-AAA interface MUST support
           the transfer of accounting records needed for service
           control and charging . . . . . . . . . . . . . . . . . . .  9
     5.4.  Mobile Node Authentication (G4.1.) . . . 10
   7.  Mandatory AVPs . . . . . . . . .  9
   6.  Security Considerations . . . . . . . . . . . . . . . 10
   8.  Accounting AVPs  . . . .  9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . 11
   9.  AVP Occurence Tables . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . 11
   10. Open Issues  . . . . 10
   9. . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Authentication Token . . . . . . . . . . . . . . . . . . . 11
     10.2. HA as a Single Physical Device . . . . . . . . . . . . . . 11
     10.3. Triggering the MIP6 Authorization Application  . . . . . . 11
     10.4. RFC4285 Support  . . . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1. 12
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2. 12
     14.2. Informative References . . . . . . . . . . . . . . . . . . 10 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 13 15

1.  Introduction

   In

   With the Mobile IPv6 deployment, authentication, authorization and
   accounting issues in the protocol operations are approached by using
   the AAA infrastructure. [9] presents [1], a Mobile Node (MN) is assigned a number
   Home Agent which is in charge of bootstrapping
   scenarios using relaying IPv6 packets destined to
   MN's Home Address to the HA-AAA interface MN's current address.  Moreover, the Mobile
   Node and defines a list of
   requirements its Home Agent (HA) must share IPsec Security Associations
   to protect Mobile IPv6 signalling.  Note that have it is possible to be fulfilled.  This document deals with the
   functional capabilities use
   another method than IPsec to secure signalling messages, but in this
   document, only IPsec is considered.  One of the Diameter protocol as a AAA protocol
   applicable for problem is to
   dynamically set-up these Security Associations and to assign the split scenario. Home
   Agent Address and the Home Address to the Mobile Node.  This document focuses only on problem
   is known as the split scenario.  A separate 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 the
   process of network access authentication, while 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 the Home Agent using IKEv2 [5].

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

   The goal of this document [10] describes is to specify a new Diameter application application,
   called Diameter Mobile IPv6 Authorization Application specifying the
   authorization and accounting procedures associated for bootstrapping
   MIPv6 Mobile IPv6
   service.  Furthermore, the document specifies the role of Home Agent
   as a Diameter client to support this application.  This modular
   approach provides flexibility for the integrated scenario. choice of authentication in
   conjunction with Mobile IPv6 services.  For instance, the HA can use
   the Diameter EAP Application [6] or other procedures 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", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1]. [7].

   The MIPv6 bootstrapping terminology is taken from [2].

3.  Bootstrapping Mobile IPv6 in the Split Scenario

   In  Diameter MIP6 HA-to-AAAH Overview

   The Home Agent offers the split scenario for bootstrapping Mobile IPv6 [3], service to the Mobile
   Node (MN) discovers Node.  As
   a Diameter client, the delivered Home Agent (belonging to performs the Mobility Service
   Provider (MSP)) through DNS.  Then, following
   operations:

   Authentication:  The Home Agent must verify the Mobile Node uses IKEv2 [4] to
   setup IPsec SAs.  Use identity of IKEv2 also provides a way to authenticate the MN by the Mobility Service Authorizer (MSA).  Note that user
      provided in the
   same time, the Mobile Node can authenticate the Home Agent. IKEv2
   supports the Extensible Authentication Protocol (EAP) to run an EAP
   method between the MN and the EAP server exchange.

   Authorization:  The Home Agent must verify that is often separated from
   the IKEv2 responder, i.e., the HA in our scenario.  As such, the MN
   can reuse its credentials (obtained from the MSA) user is
      authorized to be authenticated
   for use the Mobile IPv6 mobility service.  As outlined in [4] a HA-AAA interface
   is needed.  Since, EAP is used to authenticate the MN, the interface
   between

   Accounting:  For billing purposes and capacity planning, the Home
      Agent and provides accounting report to the AAA server will be based on the
   Diameter EAP application [5]. infrastructure.

   Figure 1 represents shows the architecture of the split scenario.

   +-------+ solution described in this
   document.

                 MSP                                MSA
              +--------+                      +-------------+
    +--+  IKEv2    +----------------+ +--+   |    Diameter EAP      +----+      | Mobile| +--------+  |
    |MN|<------>|HA|<-------------------------->|AAAH-EAP|  |
    +--+      | +--+   |(AUTHENTICATE_ONLY)   | +--------+  |
              |   ^    |                      |             |
              |   |    |  Home Agent/                      |             |
              |   |  Node |<----------->|   Diameter Client|<-------------------->|AAAH|
   +-------+             +----------------+                      +----+ MIP6 Authz/Acc | +---------+ |
              |   +---------------------------->|AAAH-MIP6| |
              |        |                      | +---------+ |
              +--------+                      +-------------+

                      Figure 1: Diameter Architecture Overview

   For the authentication part, it is likely that operators will use EAP for HA-AAA in
   within IKEv2 to authenticate the Split Scenario
   The Mobile Node acts as user since it is the EAP client and easiest way for
   operator to leverage their AAA infrastructure for IKEv2 Initiator. initiator
   authentication.  The Home
   agent Diameter EAP Application [6] is the IKEv2 Responder application
   that permits carrying EAP packets between an access device and acts a Diameter client from a AAA
   perspective.  The AAAH
   server.  However, this application is the home AAA server of the MN (i.e. primarly defined to perform AAA
   server of the MSA)
   operations for network access service and relies on a EAP server to authenticate the not for Mobile Node.  If MSP IPv6
   service.  For this reason, it is different from the MSA, recommended that, when EAP is used
   for authentication, the Home Agent may
   directly contact the AAAH or a local AAA server which Diameter EAP application will act as a
   AAA proxy (cf. [5]).

   Figure 2 shows be used only
   for Authentication purpose.  This implies that the message flow.

   Mobile Node              HA/Diameter Client Home AAA/EAP Server
   ----------                -----------------       -------------------
            IKE_SA_INIT     (1,2)
   <------------------------------>

    HDR, SK{IDi,[CERTREQ,] [IDr,]
            SAi2, TSi, TSr}  (3)
   ------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
                                       DEA (EAP-Request)
                                    <------------------------
    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, SAr2, TSi, TSr }
   <-------------------------------
   Figure 2: IKEv2 Agent will
   use the Diameter EAP Message Flow

   The interaction between the MN and Application in "AUTHENTICATE_ONLY" mode.  This
   is realized by setting the HA starts with an IKE_SA_INIT Auth-Request-Type AVP to setup
   AUTHENTICATE_ONLY.  In this document, the IKE SA.  The MN indicates its desire AAA server contacted for
   Authentication is called AAAH-EAP.  This server belongs to use EAP by not
   including the AUTH payload in MSA.

   To explicitely authorize the third message. Mobile IPv6 service, in this document,
   we define a new Diameter application, called Mobile IPv6
   Authorization Application.  The MN indicates
   its identity (e.g Network Access Identitifer) using the IDi field.
   If the Home Agent, application requires two new
   messages, namely: MIP6-Authorization-Request (MAR) and MIP6-
   Authorization-Answer (MAA).  The HA, acting as an IKEv2 Responder, supports EAP for
   authentication and relies on a remote AAA server, the Diameter client
   part of the Home Agent for
   this new application, sends a Diameter-EAP-Request (DER) MIP6-Authorization-Request message
   containing the identity in the EAP-Payload AVP and in the User-Name
   AVP.  The AAAH chooses an authentication method and sends the first
   EAP-Request in the Diameter-EAP-Answer message.  During the EAP
   authentication phase, the HA relays EAP packets between the MN (EAP
   client) and the AAAH (Home EAP server).  If of the authentication
   succeeds and if user to the MN Mobility service authorizer
   (e.g., HAAA for MIP6 service) to verify that this user is authorized
   to use Mobile IPv6 service, the
   AAAH sends a DEA service.  This message containing the EAP-success and the AAA-Key
   derived from the Master Session Key (MSK) exported by is sent towards Diameter
   server called AAAH-MIP6 in this document.  This server belongs to the EAP method.
   Some specific configuration elements
   MSA.

   This message may also be sent contain some specific authorization AVPs
   concerning Home-Address Allocation and Home-Address DNS registration.
   The response is contained in AVPs.  Note
   that EAP methods that do not derive keys are not recommended since
   they cannot bind the EAP method authentication MIP6-Authorization-Answer.  As this
   application needs a new Application-Id [[[To Be assigned by IANA]]],
   it has to be noted that the IKEv2
   authentication.  In Mobile IPv6 authorization requests may be
   routed to a different AAA server (AAAH-MIP6) than the latter message, AAA server used
   for Authentication request (AAAH-EAP).

   When the MN and verification of user authorization to receive Mobile IPv6
   service is complete, the HA finalize Home-Agent start performing Accounting
   operation by sending accounting message (ACR) with the IPsec SAs setup AVP Acct-
   Application-ID set to protect [[[To Be Assigned by IANA]]].  These messages
   contain specific Mobile IPv6 signalling. AVPs and are sent to the AAAH-MIP6.

4.  Use of  Diameter EAP for the Mobile IPv6 Split Scenario

   In the split scenario, the Home Agent uses HA-to-AAAH Support

   Although the AAA infrastructure in
   order main goal of this document is to perform authentication, specify the
   authorization and accounting for the Mobile IPv6 service.  This document proposes application, the intent
   is also to reuse provide guidance on the AAA operations expected from HA.
   Hence, this document provides guidance on the procedures required
   from the HA as part of the authentication process.  As EAP is
   considered as a strong choice in performing authentication, this
   document explains the use of Diameter EAP application [5] since in cases where
   the prior authentication between MN and HA is done through use of
   EAP.  Therefore, the HA performs AAA operations for Mobile IPv6 by
   using two Diameter Applications, namely: Diameter EAP[6] and Diameter
   Mobile IPv6 (specified by this document).

   If EAP is used by within IKEv2, the HA to authenticate the
   MN inside IKEv2.

   However, uses the procedures of Diameter
   EAP application has been designed to perform
   AAA for (DER/DEA) with the network access service. Auth-Request-Type set to
   AUTHENTICATE_ONLY.

4.1.  Authentication

   As mentioned before, prior to performing authorization process, the Mobile IPv6 service is
   different from the network access service, it appears that a Diameter
   server needs a way to make this distinction.  Indeed, even if
   HA must authenticate the
   authentication is provided by user.  The use of IKEv2 between the EAP method, authorization and
   accounting for network access MN and IPv6 mobility might be different.
   The AAA server needs to explicitly authorize
   the Mobile IPv6 service.
   It may also need HA allows the HA to configure specific parameters for authenticate the Mobile IPv6
   service such as the type Node.  Traditional
   IKE authentication procedures require existence of Home Address to provide to pre-shared secrets
   or certificates between MN and HA.  However, given the MN.
   Accounting may also require other parameters than those defined for
   network access.

   [Editor's Note: It is not clear at this point possible lack
   of time which prior knowledge between MN and HA, the more desired approach is the best to handle this.  For this reason, this document explains
   two possible approaches.]

4.1.  NAS-Port-Type AVP

   As explained below,
   use EAP and the AAA server needs a way infrastructure to identify that it is
   performing AAA operations for authenticate the user during
   IKEv2.

4.1.1.  HA with EAP Support

   Figure 2 shows the message flow involved during the authentication
   phase when EAP is used.

Mobile IPv6 service.  One way to do 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 the HA start the interaction with an IKE_SA_INIT exchange.
   In this phase cryptographic algorithms are negotiated, nonces and a
   Diffie-Hellman parameters are exchanged.  Message (3) starts the
   IKE_AUTH phase.  This second phase authenticates the previous
   messages, exchanges identities and certificates and establishes the
   first CHILD_SA.  It is used to require that mutually authenticate the Mobile Node
   (acting as an IKEv2 Initiator) and the Home Agent puts (acting as an IKEv2
   Responder).  The identity of the NAS-Port-Type AVP
   indicating that it User/Mobile Node is a Mobile IPv6 Home Agent provided in the first DER
   message.  This would
   field IDi.  The Mobile Node indicates its willingness to be formulated as: "The
   authenticated by EAP by omitting the field AUTH in message 3 (cf.
   [5]).  The Mobile Node authenticates the Home Agent MUST include by requesting a
   certificate.  This is done by including the NAS-Port-Type AVP". field [CERTREQ] in
   message 3.

   As part of the authentication process, the Mobile Node MAY request a
   Home-Address, a Home Prefix or suggests one [4].  This requires is done by
   using a change CFG_REQUEST payload in the current ABNF
   definition of this message. message 3.

   The AAA server would have to check Home Agent extracts the
   presence of this IDi field from the message 3 and sends a
   Diameter-EAP-Request message towards the authenticating Diameter
   server AAAH-EAP.  The User-Name AVP in of the first received DER message and would have MUST be set to recognize
   the new type defined for IDi field and the Home Agent.

   [Editor's Note: It Auth-Request-Type MUST be set to
   AUTHENTICATE_ONLY.  This message is not clear at this point of time if this change
   in routed through the ABNF definition would require a new Application-Id.]

   Moreover, AAA
   infrastructure to the NAS-Port-Type AVP is defined as: "The NAS-Port-Type AVP
   (AVP Code 61) is home AAA server (AAAH-EAP) of type Enumerated this Mobile Node.
   The AAAH-EAP chooses an authentication method and contains replies with the
   DEA Message.

   At the type end of the port
   on which EAP authentication phase, the NAS is authenticating AAAH-EAP indicates
   the user.  This result of the authentication in the Result-Code AVP SHOULD be
   present if and provides
   the NAS uses corresponding EAP packet (EAP Success or EAP Failure).  The last
   IKEv2 message sent by the same NAS-Port number ranges for different
   service types concurrently" (see [6]).  Hence, if Home Agent contains the DIME WG decides
   to use this approach, it Home Address or the
   Home Prefix.  In the latter case, a CREATE_CHILD_SA exchange is
   necessary to define a new type for Home-
   Agent.

   If an operator wants to use one AAA server for network access and
   another one setup IPsec SAs for Mobile IPv6 mobility service then the some messages may signalling.

4.1.2.  HA without EAP Support

   To be
   routed to completed.

4.2.  Authorization

   Following the wrong AAA server since routing is also based on successful authentication, the
   Application-ID.

4.2.  A new Application ID

   The second approach Home Agent must ensure
   that the Mobile Node is authorized to require a new application ID for use the Mobile IPv6 service.  In
   For this case, all messages will be correctly routed to
   the right Diameter Application.  This specific application will
   specifically handle all AAA Operations for purpose, the Mobile IPv6 service as
   it is done for Mobile IPv4 (cf. [7]).  However, Home Agent sends a MIP6-Authorization-Request
   (MAR) message containing identity of the protocol
   description requires that user towards the new application needs AAAH-MIP6.
   The Application-ID of this message is set to copy the
   Diameter messages [TO BE ASSIGNED].  The
   identity is extracted from the Diameter EAP application. IDi field provided in the message 3 of
   the IKEv2 exchange.  The problem home AAA server (AAAH-MIP6) replies with defining a new Application ID is that every proxies
   on
   MIP6-Authorization-Answer which contains the path would need a new code result of the
   authorization process.  This latter message MAY contain configuration
   policies to understand this application.

4.3.  Accounting be applied at the Home Agent.

   As part of the authorization request for the Mobile IPv6 Service 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, accounting, the Diameter Mobile IPv4 Application [7] [8]
   defines the following AVPs: Accounting-Input-Octets (Number

   o  Accounting-Input-Octets: Number of octets in IP packets received
      from the user), Accounting-Output-Octets
   (Number user
   o  Accounting-Output-Octets: Number of octets in IP packets sent by
      the user, Accounting-Input-
   Packets (Number user
   o  Accounting-Input-Packets: Number of IP packets received from the user), Accounting-
   Output-Packets (Number
      user
   o  Accounting-Output-Packets: Number of IP packets sent by the user). user.

   These AVPs may be re-used for the Mobile IPv6 service.  However, due
   to some optimizations for routing optimization techniques introduced with Mobile IPv6, IPv6 the HA may
   does not see all the IP entire traffic resulting from exchanged between the activation of this service. MN and the CN.

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

5.  Goals

   In this section, we present how the goals for a HA-AAA interface
   presented in [9] are met by this proposal.  Note that

4.4.  Mobile IPv6 Session Management

   Concerning Mobile IPv6 session, the two
   approaches presented above does not affect what AAAH (AAAH-MIP6) server may
   maintain state or may be stateless.  This is described here.

   [Editor's Note: the goals presented here are those described indicated in [9].
   Future revision of the mentionned document will affect this section.]

5.1.  General goals

5.1.1.  G1.1 - G1.4 Security

   As design goals for an AAA interface, G1.1 - G1.4 goals specify
   standard requirements for a AAA protocol - mutual authentication of the peers, integrity, replay protection and confidentiality.  The
   Diameter Base Protocol requires IPsec or TLS to provide hop-by-hop
   security.

5.1.2.  Dead peer detection - Auth-
   Session-State AVP (or its abscence) in the HA-AAA interface SHOULD support
        inactive peer detection.

   Two possible approaches might be considered here:

   o MAA message.  The AAAH server and the Home
   Agent establish a transport
      connection between each other.  It is the case if MUST support the Diameter
      Client of Authorization Session State Machine defined in
   [9].  Moreover the HA has a direct route to its AAA server.  In this
      case Diameter heartbeat messages called Device-Watchdog-Request/
      Answer [8], which are exchanged over this connection to test for
      its aliveness, can following 4 commands may be used to detect inactivity exchanged between the two
      Diameter peers.

   o  The AAAH server and the
   Home Agent do not have transport
      connection.  In this case inactive peer detection functionality
      should be provided into the Diameter session - service stateless
      Diameter sessions might be established between the AAAH server and the range of MSP's Home Agents for detecting HAs availability.

5.2.  Service Authorization

5.2.1.  G2.1. home AAA server.

4.4.1.  Session-Termination-Request Command

   The HA-AAA interface SHOULD allow the use of Network
        Access Identifier (NAI) to identify the mobile node.

   Identification Session-Termination-Request (STR) message [9] is sent by the User-Name AVP [8], which has a format
   consistent with Home
   Agent to inform the NAI specifications, is common for Diameter
   applications.  Diameter provides functionality for routing of
   Diameter requests based on the information included in the User-Name
   AVP. server that an authorized session is
   being terminated.

4.4.2.  Session-Termination-Answer Command

   The Mobile Node provides its NAI using Session-Termination-Answer (STA) message [9] is sent by the IDi field during
   Diameter server to acknowledge the IKEv2
   exchange with notification that the HA.

5.2.2.  G2.2. session has
   been terminated.

4.4.3.  Abort-Session-Request Command

   The HA SHOULD be able to query Abort-Session-Request (ASR) message [9] is sent by the AAAH Diameter
   server to verify
        Mobile IPv6 service authorization for terminates the mobile node.

   The goal session.  This fulfills one of this document the
   requirement described in [11].

4.4.4.  Abort-Session-Answer Command

   The Abort-Session-Answer (ASA) message [9] is sent by the Home Agent
   in response to explain how an ASR message.

5.  Command-Code Values

   This section defines Command-Code [9] value that MUST be supported by
   all Diameter implementations conforming to use this specification.  The
   following Command Codes are defined 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 the 'R' bit set in the Command Flags field is
   sent by the Home Agent acting as a Diameter Client.  This message is
   used by the Home-Agent to
   perform AAA operations for authorize the Mobile IPv6 service.

5.2.  MIP6-Authorization-Answer

   The
   Authentication is done through MIP6-Authorization-Answer (MAA), indicated by the use of EAP.  The Mobile IPv6
   service Authorization is an explicit goal of this document.

   [Editor's note: As explained above, how Command-Code
   field set to TBD and the AAA server know that it 'R' bit cleared in the Command Flags field
   is for Mobile IPv6 service has not yet been decided sent by the DIME WG.]

5.2.3.  G2.3. The AAAH server SHOULD be able (AAAH-MIP6) in response to enforce explicit
        operational limitations and authorization restrictions on the
        HA.( e.g. packet filters, QoS parameters).

   Several present Diameter applications, standardized or under work-in-
   progress address an operation and authorization control for specific
   services and have defined appropriate AVPs.  The NAS-Filter-Rule AVP,
   defined MIP6-Authorization-
   Request.

6.  Result-Code AVPs

   This section defines new Result-Code [9] values that MUST be
   supported by all Diameter NASREQ application [6], provides IP packet filter
   description.  QoS-Filter-Rule implementations that conform to this
   specification.

   To be completed.

7.  Mandatory AVPs

   To be completed.

8.  Accounting AVPs

   To be completed.

9.  AVP defined by Diameter NASREQ
   application 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 Diameter QoS application [11] provide QoS
   parameter description.  The Credit Control application [12] provides
   support for prepaid services, tariff switching, cost control over
   requested services.  The available funcationalities might be re-used
   in this document.

5.2.4.  G2.4 - G2.6. Issues addressing AAAH-MIP6 does not know if the maintenance of MN has been correctly
   authenticated before authorizing the service.

   The issue is to know wether we need to provide a Mobile IPv6
        session by proof to the AAAH server, e.g. authorization lifetime,
        extension of AAAH-
   MIP6 that the authorization lifetime and explicit  session
        termination MN is correctly authenticated by the AAAH server side.

   Diameter base protocol provides AAAH-EAP

10.2.  HA as a powerful set of commands and AVPs
   for management of Single Physical Device

   The HA acts as a IKEv2 responder with the authorization and accounting sessions.  A
   number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout-
   AVP) handle the duration (in time) of an authorization session [8].
   Additional AVPs for measuring MN.  As such, it can be
   colocated with a VPN concentrator.

   The issue is how the authorization duration in units
   different HA know that time are specified too [12].  Exchanging of
   application specific authorization request/answer messages provides
   extension of the authorization session.  Initiation of MN want MIP6 service.

10.3.  Triggering the re-
   authorization by both sides could be supported.  Both sides could
   initiate session termination, by using Diameter Session Termination
   and Abort Session messages.

   All these are applied MIP6 Authorization Application

   If EAP is used to authenticate the MN, the HA uses two applications
   to perform AAA operations: Diameter session used for authorization
   of a Mobile IPv6 session EAP and need the MIP6 Authorization
   Application.

   The issue is to know when the MIP6 Authorization Application must be applied appropriately to this
   Mobile IPv6 session too.

5.3.  Accounting - G3.1. The HA-AAA interface MUST support
   used by the transfer
      of accounting records needed for service control and charging

   Diameter accounting protocol provides HA.

   This issue is tied with the "HA as a variety of options - real-
   time accounting, event/session-type accounting records, fault
   resilience, correlation of accounting records.  Requirements for single box" one.  If the
   accounting services over AAAH-HA interface are standard.  Definition
   or re-used of AVPs only
   way for the specific accounting records combined with HA to know that it was for mip6 is to wait for a BU from
   the functionality of MN, then the Diameter accounting protocol should provide
   desired accounting services.

5.4.  Mobile Node Authentication (G4.1.)

   These issues require Application can be used only after the functionality reception of AAAH server working as a
   back-end authentication server and HA working as NAS and EAP
   authenticator in pass-through mode for providing a mobile node
   authentication.  This functionality is provided
   the BU.  However, if we want to do HoA-Allocation authorization by
   the Diameter
   NASREQ [6] and AAAH-MIP6, this implies that the Diameter EAP applications [5] application, application must be used before
   the end of the IKEv2 exchange and
   will be re-used in this document.

6.  Security Considerations

   [Editor's Note: Since thus before the BU reception

10.4.  RFC4285 Support

   This document is not complete it is necessary to
   state that deals with the security consideration section is incomplete as well.
   Hence, it HA-to-AAAH support in case IKEv2 is only possible used
   to refer setup IPsec SAs between MN and HA to the security issues raised in
   the secure Mobile IPv6 and Diameter protocol related documents mentioned
   here, such as [9] and [8].]

7.  IANA Considerations

   [Editor's note: Since the document
   signalling.

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

11.  IANA
   considerations is incomplete as well.]

8. Considerations

   To be completed.

12.  Security Considerations

   To be completed.

13.  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 and Morand.  The authors would
   particularly like to thank Yoshihiro Ohba for their
   inputs to suggesting the "Application-ID idea of
   creating a specific authorization application for the Mobile IPv6 split scenario ?"
   discussion.

9. and to
   use Diameter EAP for the authentication part.

   The authors 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
   this work.

14.  References

9.1.

14.1.  Normative References

   [1]  Bradner, S., "Key words for use   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in RFCs to Indicate Requirement
        Levels", BCP 14,
         IPv6", RFC 2119, March 1997. 3775, June 2004.

   [2]  Giaretta, G. and A.   Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
         Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 IPv6 (MIPv6)", RFC 4640, September 2006.

   [3]   Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
         the Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
         progress), May June 2006.

   [3]

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

   [4]

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

   [5]

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

   [6]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
        Network Access Server Application", RFC 4005, August 2005.

   [7]   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., and P.
         McCann, "Diameter Mobile IPv4 Application", RFC 4004,
         August 2005.

   [8]

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

9.2.  Informative References

   [9]   Giaretta, G., "Goals for AAA-HA interface",
         draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
         January 2006.

   [10]  Tschofenig, H.,  Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter MIPv6 Application
         Network Access Server Application", RFC 4005, August 2005.

14.2.  Informative References

   [11]  Giaretta, G., "AAA Goals for the Integrated
         Scenario", draft-tschofenig-dime-mip6-integrated-00 Mobile IPv6",
         draft-ietf-mip6-aaa-ha-goals-03 (work in progress), March
         September 2006.

   [11]

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

   [12]

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

   [13]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
         the Integrated Scenario",
         draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
         progress), June 2006.

Authors' Addresses

   Julien Bournelle
   GET/INT
   9 rue Charles Fourier
   Evry  91011
   France

   Email: julien.bournelle@int-evry.fr

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

   Email: gerardo.giaretta@telecomitalia.it

   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.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 Internet Society (2006).

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

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

Intellectual Property Statement

   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.

Disclaimer of Validity

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

Copyright Statement

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

Acknowledgment

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