draft-ietf-dime-mip6-split-00.txt   draft-ietf-dime-mip6-split-01.txt 
Diameter Maintenance and J. Bournelle (Ed.) Diameter Maintenance and J. Bournelle (Ed.)
Extensions (DIME) GET/INT Extensions (DIME) GET/INT
Internet-Draft G. Giaretta Internet-Draft G. Giaretta
Expires: December 21, 2006 Telecom Italia Intended status: Standards Track Telecom Italia
H. Tschofenig Expires: April 25, 2007 H. Tschofenig
Siemens Siemens Networks GmbH & Co KG
June 19, 2006 M. Nakhjiri
Huawei
October 22, 2006
Mobile IPv6 Bootstrapping using Diameter in the Split Scenario Diameter Mobile IPv6: HA-to-AAAH support
draft-ietf-dime-mip6-split-00 draft-ietf-dime-mip6-split-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In Mobile IPv6 deployment a need for an interaction between the Home In a Mobile IPv6 deployment the need for an interaction between the
Agent, the AAA infrastructure of the Mobile Service Provider (MSP) Home Agent, the AAA infrastructure of the Mobile Service Provider
and the Mobility Service Authorizer (MSA) has been identified. This (MSP) and the Mobility Service Authorizer (MSA) has been identified.
document describes how Diameter can be used to perform AAA
functionalities for the Mobile IPv6 service in the "split" scenario.
For this, it describes two possible approaches. It also explains how This document describes a new Diameter application, called Mobile
Diameter meet the goals outlined in the MIPv6 AAA goals document. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping Mobile IPv6 in the Split Scenario . . . . . . . 3 3. Diameter MIP6 HA-to-AAAH Overview . . . . . . . . . . . . . . 4
4. Use of Diameter EAP for the Mobile IPv6 Split Scenario . . . . 5 4. Diameter Mobile IPv6 HA-to-AAAH Support . . . . . . . . . . . 5
4.1. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . . . 6 4.1. 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 . . . . . . . . . . 6 4.1.2. HA without EAP Support . . . . . . . . . . . . . . . . 8
5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 7 4.4. Mobile IPv6 Session Management . . . . . . . . . . . . . . 9
5.1.2. Dead peer detection - the HA-AAA interface SHOULD 4.4.1. Session-Termination-Request Command . . . . . . . . . 9
support inactive peer detection. . . . . . . . . . . . 7 4.4.2. Session-Termination-Answer Command . . . . . . . . . . 9
5.2. Service Authorization . . . . . . . . . . . . . . . . . . 8 4.4.3. Abort-Session-Request Command . . . . . . . . . . . . 9
5.2.1. G2.1. The HA-AAA interface SHOULD allow the use of 4.4.4. Abort-Session-Answer Command . . . . . . . . . . . . . 10
Network Access Identifier (NAI) to identify the 5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . 10
mobile node. . . . . . . . . . . . . . . . . . . . . . 8 5.1. MIP6-Authorization-Request . . . . . . . . . . . . . . . . 10
5.2.2. G2.2. The HA SHOULD be able to query the AAAH 5.2. MIP6-Authorization-Answer . . . . . . . . . . . . . . . . 10
server to verify Mobile IPv6 service authorization 6. Result-Code AVPs . . . . . . . . . . . . . . . . . . . . . . . 10
for the mobile node. . . . . . . . . . . . . . . . . . 8 7. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. G2.3. The AAAH server SHOULD be able to enforce 8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . 11
explicit operational limitations and authorization 9. AVP Occurence Tables . . . . . . . . . . . . . . . . . . . . . 11
restrictions on the HA.( e.g. packet filters, QoS 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
parameters). . . . . . . . . . . . . . . . . . . . . . 8 10.1. Authentication Token . . . . . . . . . . . . . . . . . . . 11
5.2.4. G2.4 - G2.6. Issues addressing the maintenance of 10.2. HA as a Single Physical Device . . . . . . . . . . . . . . 11
a Mobile IPv6 session by the AAAH server, e.g. 10.3. Triggering the MIP6 Authorization Application . . . . . . 11
authorization lifetime, extension of the 10.4. RFC4285 Support . . . . . . . . . . . . . . . . . . . . . 12
authorization lifetime and explicit session 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
termination by the AAAH server side. . . . . . . . . . 8 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.3. Accounting - G3.1. The HA-AAA interface MUST support 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
the transfer of accounting records needed for service 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
control and charging . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
5.4. Mobile Node Authentication (G4.1.) . . . . . . . . . . . . 9 14.2. Informative References . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
In Mobile IPv6 deployment, authentication, authorization and With the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned a
accounting issues in the protocol operations are approached by using Home Agent which is in charge of relaying IPv6 packets destined to
the AAA infrastructure. [9] presents a number of bootstrapping MN's Home Address to the MN's current address. Moreover, the Mobile
scenarios using the HA-AAA interface and defines a list of Node and its Home Agent (HA) must share IPsec Security Associations
requirements that have to be fulfilled. This document deals with the to protect Mobile IPv6 signalling. Note that it is possible to use
functional capabilities of the Diameter protocol as a AAA protocol another method than IPsec to secure signalling messages, but in this
applicable for the split scenario. 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]. 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].
This document focuses only on the split scenario. A separate From an operator perspective, it is important to verify that the user
document [10] describes a Diameter application for bootstrapping (MN) is authorized to utilize Mobile IPv6 service and that such
MIPv6 for the integrated scenario. 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] 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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [7].
The MIPv6 bootstrapping terminology is taken from [2]. The MIPv6 bootstrapping terminology is taken from [2].
3. Bootstrapping Mobile IPv6 in the Split Scenario 3. Diameter MIP6 HA-to-AAAH Overview
In the split scenario for bootstrapping Mobile IPv6 [3], the Mobile The Home Agent offers the Mobile IPv6 service to the Mobile Node. As
Node (MN) discovers a Home Agent (belonging to the Mobility Service a Diameter client, the delivered Home Agent performs the following
Provider (MSP)) through DNS. Then, the Mobile Node uses IKEv2 [4] to operations:
setup IPsec SAs. Use of IKEv2 also provides a way to authenticate
the MN by the Mobility Service Authorizer (MSA). Note that 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 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) to be authenticated
for the IPv6 mobility service. As outlined in [4] a HA-AAA interface
is needed. Since, EAP is used to authenticate the MN, the interface
between the Home Agent and the AAA server will be based on the
Diameter EAP application [5]. Figure 1 represents the architecture
of the split scenario.
+-------+ IKEv2 +----------------+ Diameter EAP +----+ Authentication: The Home Agent must verify the identity of the user
| Mobile| | Home Agent/ | | | provided in the IKEv2 exchange.
| Node |<----------->| Diameter Client|<-------------------->|AAAH|
+-------+ +----------------+ +----+
Figure 1: Diameter EAP for HA-AAA in the Split Scenario Authorization: The Home Agent must verify that the user is
The Mobile Node acts as the EAP client and IKEv2 Initiator. The Home authorized to use the Mobile IPv6 service.
agent is the IKEv2 Responder and acts a Diameter client from a AAA
perspective. The AAAH is the home AAA server of the MN (i.e. AAA
server of the MSA) and relies on a EAP server to authenticate the
Mobile Node. If MSP is different from the MSA, the Home Agent may
directly contact the AAAH or a local AAA server which will act as a
AAA proxy (cf. [5]).
Figure 2 shows the message flow. Accounting: For billing purposes and capacity planning, the Home
Agent provides accounting report to the AAA infrastructure.
Mobile Node HA/Diameter Client Home AAA/EAP Server Figure 1 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| |
| | | +---------+ |
+--------+ +-------------+
Figure 1: Architecture Overview
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] 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] 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 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) IKE_SA_INIT (1,2)
<------------------------------> <------------------------------>
HDR, SK{IDi,[CERTREQ,] [IDr,] HDR, SK{IDi,[CERTREQ,] [IDr,]
[CP(CFG_REQUEST),]
SAi2, TSi, TSr} (3) SAi2, TSi, TSr} (3)
-------------------------------> ------------------------------->
DER (EAP-Response) DER (EAP-Response)(AUTHENTICATE_ONLY)
------------------------> ------------------------>
DEA (EAP-Request) DEA (EAP-Request)
<------------------------ <------------------------
HDR, SK {IDr, [CERT,] AUTH, HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
<------------------------------- <-------------------------------
HDR, SK {EAP} HDR, SK {EAP}
--------------------------------> -------------------------------->
DER (EAP-Response) DER (EAP-Response)(AUTHENTICATE_ONLY)
------------------------> ------------------------>
DEA (EAP-Request) DEA (EAP-Request)
<------------------------ <------------------------
HDR, SK{EAP-Request} HDR, SK{EAP-Request}
<------------------------------- <-------------------------------
HDR, SK{EAP-Response} HDR, SK{EAP-Response}
--------------------------------> -------------------------------->
DER (EAP-Response) DER (EAP-Response)
------------------------> ------------------------>
... ... ... ...
DEA (EAP-Success) DEA (EAP-Success)
<------------------------ <------------------------
HDR, SK{EAP-Success} HDR, SK{EAP-Success}
<------------------------------- <-------------------------------
HDR, SK{AUTH} HDR, SK{AUTH}
-------------------------------> ------------------------------->
HDR, SK {AUTH, SAr2, TSi, TSr } HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr }
<------------------------------- <-------------------------------
Figure 2: IKEv2 Diameter EAP Message Flow
The interaction between the MN and the HA starts with an IKE_SA_INIT
to setup the IKE SA. The MN indicates its desire to use EAP by not
including the AUTH payload in the third message. The MN indicates
its identity (e.g Network Access Identitifer) using the IDi field.
If the Home Agent, acting as an IKEv2 Responder, supports EAP for
authentication and relies on a remote AAA server, the Diameter client
part of the Home Agent sends a Diameter-EAP-Request (DER) 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 the authentication
succeeds and if the MN is authorized to use Mobile IPv6 service, the
AAAH sends a DEA message containing the EAP-success and the AAA-Key
derived from the Master Session Key (MSK) exported by the EAP method.
Some specific configuration elements may also be sent in AVPs. Note
that EAP methods that do not derive keys are not recommended since
they cannot bind the EAP method authentication to the IKEv2
authentication. In the latter message, the MN and the HA finalize
the IPsec SAs setup to protect Mobile IPv6 signalling.
4. Use of Diameter EAP for the Mobile IPv6 Split Scenario
In the split scenario, the Home Agent uses the AAA infrastructure in Figure 2: IKEv2 Diameter EAP Message Flow
order to perform authentication, authorization and accounting for the
Mobile IPv6 service. This document proposes to reuse the Diameter
EAP application [5] since EAP is used by the HA to authenticate the
MN inside IKEv2.
However, the Diameter EAP application has been designed to perform The MN and the HA start the interaction with an IKE_SA_INIT exchange.
AAA for the network access service. As the Mobile IPv6 service is In this phase cryptographic algorithms are negotiated, nonces and a
different from the network access service, it appears that a Diameter Diffie-Hellman parameters are exchanged. Message (3) starts the
server needs a way to make this distinction. Indeed, even if the IKE_AUTH phase. This second phase authenticates the previous
authentication is provided by the EAP method, authorization and messages, exchanges identities and certificates and establishes the
accounting for network access and IPv6 mobility might be different. first CHILD_SA. It is used to mutually authenticate the Mobile Node
The AAA server needs to explicitly authorize the Mobile IPv6 service. (acting as an IKEv2 Initiator) and the Home Agent (acting as an IKEv2
It may also need to configure specific parameters for the Mobile IPv6 Responder). The identity of the User/Mobile Node is provided in the
service such as the type of Home Address to provide to the MN. field IDi. The Mobile Node indicates its willingness to be
Accounting may also require other parameters than those defined for authenticated by EAP by omitting the field AUTH in message 3 (cf.
network access. [5]). The Mobile Node authenticates the Home Agent by requesting a
certificate. This is done by including the field [CERTREQ] in
message 3.
[Editor's Note: It is not clear at this point of time which approach As part of the authentication process, the Mobile Node MAY request a
is the best to handle this. For this reason, this document explains Home-Address, a Home Prefix or suggests one [4]. This is done by
two possible approaches.] using a CFG_REQUEST payload in the message 3.
4.1. NAS-Port-Type AVP 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.
As explained below, the AAA server needs a way to identify that it is At the end of the EAP authentication phase, the AAAH-EAP indicates
performing AAA operations for the Mobile IPv6 service. One way to do the result of the authentication in the Result-Code AVP and provides
this is to require that the Home Agent puts the NAS-Port-Type AVP the corresponding EAP packet (EAP Success or EAP Failure). The last
indicating that it is a Mobile IPv6 Home Agent in the first DER IKEv2 message sent by the Home Agent contains the Home Address or the
message. This would be formulated as: "The Home Agent MUST include Home Prefix. In the latter case, a CREATE_CHILD_SA exchange is
the NAS-Port-Type AVP". This requires a change in the current ABNF necessary to setup IPsec SAs for Mobile IPv6 signalling.
definition of this message. The AAA server would have to check the
presence of this AVP in the first received DER message and would have
to recognize the new type defined for the Home Agent.
[Editor's Note: It is not clear at this point of time if this change 4.1.2. HA without EAP Support
in the ABNF definition would require a new Application-Id.]
Moreover, the NAS-Port-Type AVP is defined as: "The NAS-Port-Type AVP To be completed.
(AVP Code 61) is of type Enumerated and contains the type of the port
on which the NAS is authenticating the user. This AVP SHOULD be
present if the NAS uses the same NAS-Port number ranges for different
service types concurrently" (see [6]). Hence, if the DIME WG decides
to use this approach, it is necessary to define a new type for Home-
Agent.
If an operator wants to use one AAA server for network access and 4.2. Authorization
another one for IPv6 mobility service then the some messages may be
routed to the wrong AAA server since routing is also based on the
Application-ID.
4.2. A new Application ID 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.
The second approach is to require a new application ID for the Mobile As part of the authorization request for the Mobile IPv6 service.
IPv6 service. In this case, all messages will be correctly routed to The Home Agent may require specific authorization for this MN. As an
the right Diameter Application. This specific application will example, it may request if this user is allowed to auto-assign its
specifically handle all AAA Operations for the Mobile IPv6 service as Home-Address.
it is done for Mobile IPv4 (cf. [7]). However, the protocol
description requires that the new application needs to copy the
Diameter messages from the Diameter EAP application.
The problem with defining a new Application ID is that every proxies 4.3. Accounting
on the path would need a new code to understand this application.
4.3. Accounting for the Mobile IPv6 Service Concerning accounting, the Diameter Mobile IPv4 Application [8]
defines the following AVPs:
Concerning Accounting, the Diameter Mobile IPv4 Application [7] o Accounting-Input-Octets: Number of octets in IP packets received
defines the following AVPs: Accounting-Input-Octets (Number of octets from the user
in IP packets received from the user), Accounting-Output-Octets o Accounting-Output-Octets: Number of octets in IP packets sent by
(Number of octets in IP packets sent by the user, Accounting-Input- the user
Packets (Number of IP packets received from the user), Accounting- o Accounting-Input-Packets: Number of IP packets received from the
Output-Packets (Number of IP packets sent by the user). user
o Accounting-Output-Packets: Number of IP packets sent by the user.
These AVPs may be re-used for the Mobile IPv6 service. However, due These AVPs may be re-used for the Mobile IPv6 service. However, due
to some optimizations for Mobile IPv6, the HA may not see all the IP to routing optimization techniques introduced with Mobile IPv6 the HA
traffic resulting from the activation of this service. does not see the entire traffic exchanged between the MN and the CN.
[Editor's Note: As the document describing goals for this interface [Editor's Note: As the document describing goals for this interface
is not finalized, other parameters may be needed in the future.] is not finalized, other parameters may be needed in the future.]
5. Goals 4.4. Mobile IPv6 Session Management
In this section, we present how the goals for a HA-AAA interface Concerning Mobile IPv6 session, the AAAH (AAAH-MIP6) server may
presented in [9] are met by this proposal. Note that the two maintain state or may be stateless. This is indicated in the Auth-
approaches presented above does not affect what is described here. Session-State AVP (or its abscence) in the MAA message. The Home
Agent MUST support the Authorization Session State Machine defined in
[9]. Moreover the following 4 commands may be exchanged between the
Home Agent and the home AAA server.
[Editor's Note: the goals presented here are those described in [9]. 4.4.1. Session-Termination-Request Command
Future revision of the mentionned document will affect this section.]
5.1. General goals The Session-Termination-Request (STR) message [9] is sent by the Home
Agent to inform the Diameter server that an authorized session is
being terminated.
5.1.1. G1.1 - G1.4 Security 4.4.2. Session-Termination-Answer Command
As design goals for an AAA interface, G1.1 - G1.4 goals specify The Session-Termination-Answer (STA) message [9] is sent by the
standard requirements for a AAA protocol - mutual authentication of Diameter server to acknowledge the notification that the session has
the peers, integrity, replay protection and confidentiality. The been terminated.
Diameter Base Protocol requires IPsec or TLS to provide hop-by-hop
security.
5.1.2. Dead peer detection - the HA-AAA interface SHOULD support 4.4.3. Abort-Session-Request Command
inactive peer detection.
Two possible approaches might be considered here: The Abort-Session-Request (ASR) message [9] is sent by the Diameter
server to terminates the session. This fulfills one of the
requirement described in [11].
o The AAAH server and the Home Agent establish a transport 4.4.4. Abort-Session-Answer Command
connection between each other. It is the case if the Diameter
Client of 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 be used to detect inactivity between the two
Diameter peers.
o The AAAH server and the Home Agent do not have transport The Abort-Session-Answer (ASA) message [9] is sent by the Home Agent
connection. In this case inactive peer detection functionality in response to an ASR message.
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. Command-Code Values
5.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network This section defines Command-Code [9] value that MUST be supported by
Access Identifier (NAI) to identify the mobile node. all Diameter implementations conforming to this specification. The
following Command Codes are defined in this specification:
Identification by the User-Name AVP [8], which has a format Command-Name Abbreviation Code Section
consistent with the NAI specifications, is common for Diameter ---------------------------------------------------------
applications. Diameter provides functionality for routing of MIP6-Authorization-Request MAR TBD
Diameter requests based on the information included in the User-Name MIP6-Authorization-Answer MAA TBD
AVP.
The Mobile Node provides its NAI using the IDi field during the IKEv2 Figure 3
exchange with the HA.
5.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify 5.1. MIP6-Authorization-Request
Mobile IPv6 service authorization for the mobile node.
The goal of this document is to explain how to use Diameter to The MIP6-Authorization-Request (MAR), indicated by the Command-Code
perform AAA operations for the Mobile IPv6 service. The field set to TBD and the 'R' bit set in the Command Flags field is
Authentication is done through the use of EAP. The Mobile IPv6 sent by the Home Agent acting as a Diameter Client. This message is
service Authorization is an explicit goal of this document. used by the Home-Agent to authorize the Mobile IPv6 service.
[Editor's note: As explained above, how the AAA server know that it 5.2. MIP6-Authorization-Answer
is for Mobile IPv6 service has not yet been decided by the DIME WG.]
5.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit The MIP6-Authorization-Answer (MAA), indicated by the Command-Code
operational limitations and authorization restrictions on the field set to TBD and the 'R' bit cleared in the Command Flags field
HA.( e.g. packet filters, QoS parameters). is sent by the AAAH (AAAH-MIP6) in response to MIP6-Authorization-
Request.
Several present Diameter applications, standardized or under work-in- 6. Result-Code AVPs
progress address an operation and authorization control for specific
services and have defined appropriate AVPs. The NAS-Filter-Rule AVP,
defined by Diameter NASREQ application [6], provides IP packet filter
description. QoS-Filter-Rule AVP defined by Diameter NASREQ
application and by 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 the maintenance of a Mobile IPv6 This section defines new Result-Code [9] values that MUST be
session by the AAAH server, e.g. authorization lifetime, supported by all Diameter implementations that conform to this
extension of the authorization lifetime and explicit session specification.
termination by the AAAH server side.
Diameter base protocol provides a powerful set of commands and AVPs To be completed.
for management of 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 the authorization duration in units
different that time are specified too [12]. Exchanging of
application specific authorization request/answer messages provides
extension of the authorization session. Initiation of 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 to the Diameter session used for authorization 7. Mandatory AVPs
of a Mobile IPv6 session and need to be applied appropriately to this
Mobile IPv6 session too.
5.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer To be completed.
of accounting records needed for service control and charging
Diameter accounting protocol provides a variety of options - real- 8. Accounting AVPs
time accounting, event/session-type accounting records, fault
resilience, correlation of accounting records. Requirements for the
accounting services over AAAH-HA interface are standard. Definition
or re-used of AVPs for the specific accounting records combined with
the functionality of the Diameter accounting protocol should provide
desired accounting services.
5.4. Mobile Node Authentication (G4.1.) To be completed.
These issues require the functionality of AAAH server working as a 9. AVP Occurence Tables
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 by the Diameter
NASREQ [6] and the Diameter EAP applications [5] application, and
will be re-used in this document.
6. Security Considerations To be completed.
[Editor's Note: Since the document is not complete it is necessary to 10. Open Issues
state that the security consideration section is incomplete as well.
Hence, it is only possible to refer to the security issues raised in
the Mobile IPv6 and Diameter protocol related documents mentioned
here, such as [9] and [8].]
7. IANA Considerations 10.1. Authentication Token
[Editor's note: Since the document is not complete, the IANA Authentication and Authorization/Accounting process may be handled by
considerations is incomplete as well.] 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.
8. Acknowledgements 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 The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi
Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen, Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen,
Avi Lior, John Loughney, Lionel Morand and Yoshihiro Ohba for their Avi Lior, John Loughney, Lionel Morand. The authors would
inputs to the "Application-ID for the Mobile IPv6 split scenario ?" particularly like to thank Yoshihiro Ohba for suggesting the idea of
discussion. creating a specific authorization application for Mobile IPv6 and to
use Diameter EAP for the authentication part.
9. References 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.
9.1. Normative References Julien Bournelle would like to thank Orange-FT which partly funded
this work.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 14. References
Levels", BCP 14, RFC 2119, March 1997.
[2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 14.1. Normative References
Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
progress), May 2006.
[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile 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), June 2006.
[4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-02 (work in progress), draft-ietf-mip6-bootstrapping-split-02 (work in progress),
March 2006. March 2006.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
December 2005. RFC 4306, December 2005.
[5] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [6] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Network Access Server Application", RFC 4005, August 2005. Levels", BCP 14, RFC 2119, March 1997.
[7] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. [8] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P.
McCann, "Diameter Mobile IPv4 Application", RFC 4004, McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005. August 2005.
[8] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003. "Diameter Base Protocol", RFC 3588, September 2003.
9.2. Informative References [10] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[9] Giaretta, G., "Goals for AAA-HA interface", 14.2. Informative References
draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
January 2006.
[10] Tschofenig, H., "Diameter MIPv6 Application for the Integrated [11] Giaretta, G., "AAA Goals for Mobile IPv6",
Scenario", draft-tschofenig-dime-mip6-integrated-00 (work in draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
progress), March 2006. September 2006.
[11] Alfano, F., "Diameter Quality of Service Application", [12] Alfano, F., "Diameter Quality of Service Application",
draft-tschofenig-dime-diameter-qos-00 (work in progress), draft-tschofenig-dime-diameter-qos-01 (work in progress),
March 2006. October 2006.
[12] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. [13] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006, Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005. 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 Authors' Addresses
Julien Bournelle Julien Bournelle
GET/INT GET/INT
9 rue Charles Fourier 9 rue Charles Fourier
Evry 91011 Evry 91011
France France
Email: julien.bournelle@int-evry.fr Email: julien.bournelle@int-evry.fr
Gerardo Giaretta Gerardo Giaretta
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
TORINO, 10148 TORINO, 10148
Italy Italy
Email: gerardo.giaretta@telecomitalia.it Email: gerardo.giaretta@telecomitalia.it
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Intellectual Property Statement 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
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 29 skipping to change at page 15, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 86 change blocks. 
336 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/