Diameter 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 April 25, 2007.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

In a Mobile IPv6 deployment 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 a new Diameter application, called Mobile IPv6 Authorization Application, used in conjunction with the Diameter EAP Application is used to perform the necessary AAA functions before executing Mobile IPv6 services. This document also specifies the role of the Home Agent as part of the AAA infrastructure supporting the Diameter Mobile IPv6 Authorization Application.

Table of Contents

1.  Introduction
2.  Terminology
3.  Diameter MIP6 HA-to-AAAH Overview
4.  Diameter Mobile IPv6 HA-to-AAAH Support
    4.1.  Authentication
        4.1.1.  HA with EAP Support
        4.1.2.  HA without EAP Support
    4.2.  Authorization
    4.3.  Accounting
    4.4.  Mobile IPv6 Session Management
        4.4.1.  Session-Termination-Request Command
        4.4.2.  Session-Termination-Answer Command
        4.4.3.  Abort-Session-Request Command
        4.4.4.  Abort-Session-Answer Command
5.  Command-Code Values
    5.1.  MIP6-Authorization-Request
    5.2.  MIP6-Authorization-Answer
6.  Result-Code AVPs
7.  Mandatory AVPs
8.  Accounting AVPs
9.  AVP Occurence Tables
10.  Open Issues
    10.1.  Authentication Token
    10.2.  HA as a Single Physical Device
    10.3.  Triggering the MIP6 Authorization Application
    10.4.  RFC4285 Support
11.  IANA Considerations
12.  Security Considerations
13.  Acknowledgements
14.  References
    14.1.  Normative References
    14.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

With the Mobile IPv6 protocol [1] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), a Mobile Node (MN) is assigned a Home Agent which is in charge of relaying IPv6 packets destined to MN's Home Address to the MN's current address. Moreover, the Mobile Node and its Home Agent (HA) must share IPsec Security Associations to protect Mobile IPv6 signalling. Note that it is possible to use another method than IPsec to secure signalling messages, but in this document, only IPsec is considered. One of the problem is to dynamically set-up these Security Associations and to assign the Home Agent Address and the Home Address to the Mobile Node. This problem is known as the Mobile IPv6 bootstrapping problem and is detailed in [2] (Patel, A. and G. Giaretta, “Problem Statement for bootstrapping Mobile IPv6 (MIPv6),” September 2006.). Two possible bootstrapping scenarios have been identified, namely the Integrated and the Split Scenario. With the Integrated Scenario (see [3] (Chowdhury, K. and A. Yegin, “MIP6-bootstrapping via DHCPv6 for the Integrated Scenario,” June 2006.)), the Home Agent Address is delivered during the process of network access authentication, while in the Split scenario (see [4] (Giaretta, G., “Mobile IPv6 bootstrapping in split scenario,” March 2006.)), 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] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.).

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 is to specify a new Diameter application, called Diameter Mobile IPv6 Authorization Application specifying the authorization and accounting procedures associated for 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 choice of authentication in conjunction with Mobile IPv6 services. For instance, the HA can use the Diameter EAP Application [6] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) 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 [7] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The MIPv6 bootstrapping terminology is taken from [2] (Patel, A. and G. Giaretta, “Problem Statement for bootstrapping Mobile IPv6 (MIPv6),” September 2006.).

3.  Diameter MIP6 HA-to-AAAH Overview

The Home Agent offers the Mobile IPv6 service to the Mobile Node. As a Diameter client, the delivered Home Agent performs the following operations:

Authentication:

The Home Agent must verify the identity of the user provided in the IKEv2 exchange.

Authorization:

The Home Agent must verify that the user is authorized to use the Mobile IPv6 service.

Accounting:

For billing purposes and capacity planning, the Home Agent provides accounting report to the AAA infrastructure.

Figure 1 (Architecture Overview) shows the architecture of the solution described in this document.

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

For the authentication part, it is likely that operators will use EAP within IKEv2 to authenticate the user since it is the easiest way for operator to leverage their AAA infrastructure for IKEv2 initiator authentication. The Diameter EAP Application [6] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) is the application that permits carrying EAP packets between an access device and a AAA server. However, this application is primarly defined 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, the Diameter EAP application will be used only for Authentication purpose. This implies that the Home Agent will use the Diameter EAP Application 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 is called AAAH-EAP. This server belongs 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 this new application, sends a MIP6-Authorization-Request message containing identity of the user to the Mobility service authorizer (e.g., HAAA for MIP6 service) to verify that this user is authorized to use Mobile IPv6 service. This message is sent towards 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. 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, the Home-Agent 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 and are sent to the AAAH-MIP6.

4.  Diameter Mobile IPv6 HA-to-AAAH Support

Although the main goal of this document is to specify the authorization and accounting for Mobile IPv6 application, the intent is also to 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 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] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) and Diameter Mobile IPv6 (specified by this document).

If EAP is used within IKEv2, the HA uses the procedures of Diameter EAP application (DER/DEA) with the Auth-Request-Type set to AUTHENTICATE_ONLY.

4.1.  Authentication

As mentioned before, prior to performing authorization process, the HA must authenticate the user. The use of IKEv2 between the MN and the HA allows the HA to authenticate the Mobile Node. Traditional IKE authentication procedures require existence of pre-shared secrets or certificates between MN and HA. However, given the possible lack of prior knowledge between MN and HA, the more desired approach is to use EAP and the AAA infrastructure to authenticate the user during IKEv2.

4.1.1.  HA with EAP Support

Figure 2 (IKEv2 Diameter EAP Message Flow) shows the message flow involved during the authentication phase when EAP is used.

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

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 mutually authenticate the Mobile Node (acting as an IKEv2 Initiator) and the Home Agent (acting as an IKEv2 Responder). The identity of the User/Mobile Node is provided in the field IDi. The Mobile Node indicates its willingness to be authenticated by EAP by omitting the field AUTH in message 3 (cf. [5] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.)). The Mobile Node authenticates the Home Agent by requesting a certificate. This is done by including the 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] (Giaretta, G., “Mobile IPv6 bootstrapping in split scenario,” March 2006.). This is done by using a CFG_REQUEST payload in the message 3.

The Home Agent extracts the IDi field from the message 3 and sends a Diameter-EAP-Request message towards the authenticating Diameter server AAAH-EAP. The User-Name AVP of the DER message MUST be set to the IDi field and the Auth-Request-Type MUST be set to AUTHENTICATE_ONLY. This message is routed through the AAA infrastructure to the home AAA server (AAAH-EAP) of this Mobile Node. The AAAH-EAP chooses an authentication method and replies with the DEA Message.

At the end of the EAP authentication phase, the AAAH-EAP indicates the result of the authentication in the Result-Code AVP and provides the corresponding EAP packet (EAP Success or EAP Failure). The last IKEv2 message sent by the Home Agent contains the Home Address or the Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is necessary 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, the Home Agent must ensure that the Mobile Node is authorized to use the Mobile IPv6 service. For this purpose, the Home Agent sends a MIP6-Authorization-Request (MAR) message containing identity of the user towards the AAAH-MIP6. The Application-ID of this message is set to [TO BE ASSIGNED]. The identity is extracted from the IDi field provided 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 to be applied at the Home Agent.

As part of the authorization request for 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] (Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, “Diameter Mobile IPv4 Application,” August 2005.) defines the following AVPs:

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

These AVPs may be re-used for the Mobile IPv6 service. However, due to routing optimization techniques introduced with Mobile IPv6 the HA does not see the entire traffic exchanged between the 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.]

4.4.  Mobile IPv6 Session Management

Concerning Mobile IPv6 session, the AAAH (AAAH-MIP6) server may maintain state or may be stateless. This is indicated in the Auth-Session-State AVP (or its abscence) in the MAA message. The Home Agent MUST support the Authorization Session State Machine defined in [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). Moreover the following 4 commands may be exchanged between the Home Agent and the home AAA server.

4.4.1.  Session-Termination-Request Command

The Session-Termination-Request (STR) message [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) is sent by the Home Agent to inform the Diameter server that an authorized session is being terminated.

4.4.2.  Session-Termination-Answer Command

The Session-Termination-Answer (STA) message [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) is sent by the Diameter server to acknowledge the notification that the session has been terminated.

4.4.3.  Abort-Session-Request Command

The Abort-Session-Request (ASR) message [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) is sent by the Diameter server to terminates the session. This fulfills one of the requirement described in [11] (Giaretta, G., “AAA Goals for Mobile IPv6,” September 2006.).

4.4.4.  Abort-Session-Answer Command

The Abort-Session-Answer (ASA) message [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) is sent by the Home Agent in response to an ASR message.

5.  Command-Code Values

This section defines Command-Code [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) value that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification:

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

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 authorize the Mobile IPv6 service.

5.2.  MIP6-Authorization-Answer

The MIP6-Authorization-Answer (MAA), indicated by the Command-Code field set to TBD and the 'R' bit cleared in the Command Flags field is sent by the AAAH (AAAH-MIP6) in response to MIP6-Authorization-Request.

6.  Result-Code AVPs

This section defines new Result-Code [9] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) 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.  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 the MN is correctly authenticated by AAAH-EAP

10.2.  HA as a Single Physical Device

The HA acts as a IKEv2 responder with the MN. As such, it can be colocated with a VPN concentrator.

The issue is how the HA know that the MN want MIP6 service.

10.3.  Triggering the MIP6 Authorization Application

If EAP is used to authenticate the MN, the HA uses two applications to perform AAA operations: Diameter EAP and the MIP6 Authorization Application.

The issue is to know when the MIP6 Authorization Application must be used by the HA.

This issue is tied with the "HA as a single box" one. If the only way for the HA to know that it was for mip6 is to wait for a BU from the MN, then the Application can be used only after the reception of the BU. However, if we want to do HoA-Allocation authorization by the AAAH-MIP6, this implies that the application must be used before the end of the IKEv2 exchange and thus before the BU reception

10.4.  RFC4285 Support

This document deals with the HA-to-AAAH support in case IKEv2 is used to setup IPsec SAs between MN and HA 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.  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 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

14.1. Normative References

14.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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

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