Diameter Maintanence and H. Tschofenig
Extensions (DIME) Siemens
Internet-Draft T. Tsenov
Expires: August 31, 2006
G. Giaretta
TILab
J. Bournelle
GET/INT
February 27, 2006
Mobile IPv6 Bootstrapping using Diameter in the Split Scenario
draft-tschofenig-dime-mip6-split-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In Mobile IPv6 deployment a 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
Tschofenig, et al. Expires August 31, 2006 [Page 1]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
document provides a description of the functionality that allows to
meet the goals outlined in the MIPv6 AAA Goals document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General goals . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 5
3.1.2. Dead peer detection - the HA-AAA interface SHOULD
support inactive peer detection. . . . . . . . . . . . 5
3.2. Service Authorization . . . . . . . . . . . . . . . . . . 5
3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of
Network Access Identifier (NAI) to identify the
mobile node. . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. G2.2. The HA SHOULD be able to query the AAAH
server to verify Mobile IPv6 service authorization
for the mobile node. . . . . . . . . . . . . . . . . . 6
3.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). . . . . . . . . . . . . . . . . . . . . . 6
3.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. . . . . . . . . . 6
3.2.5. G2.7. The AAAH server SHOULD be able to retrieve
the Mobile IPv6 state associated to a specific MN
from the correspondent HA. This MAY be useful to
periodically verify the Mobile IPv6 service status. . 7
3.3. Accounting - G3.1. The HA-AAA interface MUST support
the transfer of accounting records needed for service
control and charging . . . . . . . . . . . . . . . . . . . 7
3.4. Mobile Node Authentication (G4.1. and G4.2.) . . . . . . . 7
3.5. Provisioning of configuration parameters . . . . . . . . . 8
4. Bootstrapping Mobile IPv6 in the split scenario . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Tschofenig, et al. Expires August 31, 2006 [Page 2]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
1. Introduction
In Mobile IPv6 deployment, authentication, authorization and
accounting issues in the protocol operations are approached by using
the AAA infrastructure. The [8] document presents a number of
bootstrapping scenarios using the HA-AAA interface and defines a list
of requirements that this interface should cover. This document
deals with the functional capabilities of the Diameter protocol as a
AAA protocol applicable for the split scenario.
Currently, two Mobile IPv6 bootstrapping solutions exist. In the
split scenario, only a HA-AAA interface is considered whereas in the
integrated scenario both NAS-AAA and HA-AAA interface need to be
addressed.
This document focuses only on the split scenario. A separate
document describes a Diameter application for bootstrapping MIPv6 for
the integrated scenario.
Tschofenig, et al. Expires August 31, 2006 [Page 3]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
2. Motivation
Designed to cover network access requirements for AAA protocols [1],
Diameter protocol provides a framework for applications offering AAA
services. This design approach gives to the protocol extensibility,
interoperability and flexibility in offering AAA solutions in
comparison to other AAA protocols. Support of definition of new
application Ids, commands and AVPs provides extensibility.
Recommended re-use of commands and AVPs and careful consideration of
the level of AVP's support provides interoperability. Usage of IPsec
and TLS for transport hop-by-hop security, possible support for AVP
integrity and confidentiality and usage of peer-to-peer model (any
Diameter node can initiate a request message) provide flexibility of
the Diameter AAA applications to fit to specific requirements.
In the following sections we try to specify by which means a possible
Diameter application would cover the requirements for the HA-AAA
interface specified in [8].
Tschofenig, et al. Expires August 31, 2006 [Page 4]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
3. Goals
In presentation of the analysis of goals and possible design
solutions by Diameter we follow the classification, labels and naming
assigned in the document [8], where these goals are identified.
Since several of the issues MIGHT be addressed in similar way or by
similar Diameter functionality, we have grouped these issues and have
given a general description of the groups.
3.1. General goals
3.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. IPsec
or TLS provide the hop-by-hop security. Combined, they SHOULD be
able to provide the range of security services required for the HA-
AAA interface.
3.1.2. Dead peer detection - the HA-AAA interface SHOULD support
inactive peer detection.
Two possible approaches MIGHT be considered here:
o AAAH server and Home Agent establish a transport connection
between each other. In this case Diameter heartbeat messages
called Watch-Dog-Request/Answer, which are exchanged over this
connection to test for its aliveness, MAY be used to detect
inactivity in any of the two Diameter peers.
o AAAH server and 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.
3.2. Service Authorization
3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network
Access Identifier (NAI) to identify the mobile node.
Identification by User-Name AVP [1], which has a format consistent
with 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.
Tschofenig, et al. Expires August 31, 2006 [Page 5]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
3.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify
Mobile IPv6 service authorization for the mobile node.
Based on the peer-to-peer model, Diameter design gives the
functionality that any Diameter node can initiate a request message.
This, combined with the support of EAP, would provide flexible
solutions for this issue. Currently several Diameter application
standardized or under work-in-progress address different types of
authorization - network access [2], credit control [9], quality of
service [10]. This MIGHT allow re-use of present AVPs over the
AAAH-HA interface.
3.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).
Several present Diameter applications, standardized or under work-in-
progress address an operation and authorization control over specific
services and have defined appropriate AVPs. NAS-Filter-Rule AVP,
defined by Diameter NASREQ application [2], provides IP packet filter
description. QoS-Filter-Rule AVP defined by Diameter NASREQ
application and QSPEC AVP defined by Diameter QoS Authorization [10]
provide QoS parameter description. Credit Control application [9]
provides cost control over requested services. AVPs MAY be re-used
for providing required functionality over the AAAH-HA interface.
This, combined with the possibility that any node can initiate
request message, gives control to the AAAH server over HA's
functionality.
3.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.
Diameter base protocol provides a powerful set of commands and AVPs
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 [1].
Additional AVPs for measuring the authorization duration in units
different that time are specified too [9]. 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
of a Mobile IPv6 session and need to be applied appropriately to this
Tschofenig, et al. Expires August 31, 2006 [Page 6]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
Mobile IPv6 session too.
3.2.5. G2.7. The AAAH server SHOULD be able to retrieve the Mobile IPv6
state associated to a specific MN from the correspondent HA.
This MAY be useful to periodically verify the Mobile IPv6
service status.
This issue has two sides:
1. How the AAAH SHOULD know which HA to contact to retrieve current
status of MN's Mobile IPv6 service in case of stateless MSP
architecture and several servicing AAA servers? - As analyzed
into the [11], this need would be required for re-authorization
and in this case the provision of HA info could be provided from
the MN during the re-authentication session between NM and AAAH
server.
2. Once having the HA info, AAAH SHOULD contact it to verify the
status of MN's Mobile IPv6 service. - This could be performed by
Request/Response messages initiated by the AAAH server. This
functionality is supported by the Diameter protocol and currently
is applied into Diameter SIP application for updating user
profiles at Diameter client (i.e., SIP server).
3.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer
of accounting records needed for service control and charging
Diameter accounting protocol provides a variety of options - real-
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.
3.4. Mobile Node Authentication (G4.1. and G4.2.)
These issues require the functionality 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. These functionalities are provided by Diameter
NASREQ and EAP applications, and MIGHT be re-used at the AAAH-AH
interface.[2], [3]
Tschofenig, et al. Expires August 31, 2006 [Page 7]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
3.5. Provisioning of configuration parameters
Issues G5.1 - G5.3 are related to capability of exchanging and
negotiating of operational parameters for Mobile IPv6 protocol
bootstrapping and providing appropriate security level for this
information.
Diameter provides secure transport by means of IPsec, TLS and
possible AVPs integrity and confidentiality support (currently with
no interest from the community). Several AVPs could be re-used for
carrying the operational parameters for the Mobile IPv6
bootstrapping. Framed-IPv6-Prefix AVP, Login-IPv6-Host AVP, Framed-
Interface-Id AVP, Framed-IPv6-Route AVP defined by NASREQ MIGHT be
used for home address provision and AVPs defined in EAP application
MIGHT be used for key transport [3].
Tschofenig, et al. Expires August 31, 2006 [Page 8]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
4. Bootstrapping Mobile IPv6 in the split scenario
In the split scenario for bootstrapping Mobile IPv6 [4], the MN
discovers HA through DNS mechanism. Then it uses IKEv2 [5] to setup
IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus
the MN. As such, the MN can use its credentials (obtained from the
MSA) to be authenticated for the IPv6 mobility service. The HA MAY
rely on a EAP server co-located on a AAA server for this purpose. In
this case, a HA-AAA interface is needed. This interface MUST support
transport of EAP packets.
+----+ IKEv2 +----+ Diameter EAP +---+
| MN |<----------->| HA |<-------------------->|AAA|
+----+ +----+ +---+
Figure 1: Diameter EAP as the HA-AAA interface in Split scenario
For this purpose, the HA can use Diameter EAP Application [3] (cf.
Figure 1). As shown in the previous section, this protocol fulfill
goals described in [8]
Tschofenig, et al. Expires August 31, 2006 [Page 9]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
MN HA AAAH
-- -- ----
IKE_SA_INIT
<------------------------------>
HDR, SK{IDi,[CERTREQ,] [IDr,]
SAi2, TSi, TSr}
------------------------------->
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 Diameter EAP
MN and HA start 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. However it indicates its identity (e.g. NAI) by
using the IDi field. If the HA supports EAP for authentication, it
forwards the identity to the AAAH by sending a Diameter-EAP-Request
(DER) message containing the identity in the EAP-Payload AVP and in
the User-Name AVP. Based on this identity, the AAAH chooses an
Tschofenig, et al. Expires August 31, 2006 [Page 10]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
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 and the AAAH. 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 EAP authentication method . Note
that EAP authentication methods that do not derive keys are not
recommended. This key is used by both MN and HA to generate the AUTH
payload. In the latter message, MN and HA finish to setup IPsec SAs
for Mobile IPv6.
Tschofenig, et al. Expires August 31, 2006 [Page 11]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
5. Security considerations
[Editor's Note: Since the document is not complete it is necessary to
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 [11], [8] and [1].]
Tschofenig, et al. Expires August 31, 2006 [Page 12]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
6. IANA Considerations
The AVP code for the Home-Agent AVP needs to be allocated.
Tschofenig, et al. Expires August 31, 2006 [Page 13]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
7. Acknowledgements
We would like to thank the MIPv6 Bootstrapping Design Team for their
comments. Additionally, we would like to thank Junghoon Jee for his
feedback.
Tschofenig, et al. Expires August 31, 2006 [Page 14]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
8. References
8.1. Normative References
[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[2] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-01 (work in progress),
October 2005.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005.
[7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
8.2. Informative References
[8] Giaretta, G., "Goals for AAA-HA interface",
draft-ietf-mip6-aaa-ha-goals-01 (work in progress),
January 2006.
[9] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H.
Hakala, "Diameter Credit-control Application",
draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004.
[10] Alfano, F., "Diameter Quality of Service Application",
draft-alfano-aaa-qosprot-05 (work in progress), October 2005.
[11] Giaretta, G., "MIPv6 Authorization and Configuration based on
EAP", draft-giaretta-mip6-authorization-eap-02 (work in
progress), October 2004.
Tschofenig, et al. Expires August 31, 2006 [Page 15]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Tseno Tsenov
Sofia,
Bulgaria
Email: tseno.tsenov@mytum.de
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
TORINO, 10148
Italy
Email: gerardo.giaretta@tilab.com
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Tschofenig, et al. Expires August 31, 2006 [Page 16]
Internet-Draft MIP6 Bootstrapping with Diameter February 2006
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.
Tschofenig, et al. Expires August 31, 2006 [Page 17]