[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
                  MIP6 Working Group                                       G. Giaretta
                  Internet Draft                                           I. Guardini
                  Expires: July 2006                                        E. Demaria
                                                                          J. Bournelle
                                                                              R. Lopez
                                                                       Univ. of Murcia
                                                                          January 2006
                                        Goals for AAA-HA interface
               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-
                  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
                  The list of Internet-Draft Shadow Directories can be accessed at
                  This Internet-Draft will expire on July 27, 2006.
                  Copyright Notice
                     Copyright (C) The Internet Society (2006).  All Rights Reserved.
                  In commercial deployments Mobile IPv6 can be a service offered by a
                  Mobility Services Provider (MSP). In this case all protocol
                  operations may need to be explicitly authorized and traced,
                  requiring the interaction between Mobile IPv6 and the AAA
                  infrastructure. Integrating the AAA infrastructure offers also a
                  solution component for Mobile IPv6 bootstrapping in integrated and
                  split scenarios.
               Internet-Draft          AAA-HA interface goals          January 2006
                  This document describes various scenarios where a AAA interface for
                  Mobile IPv6 is actually required. Additionally, it lists design
                  goals and requirements for such an interface.
               Conventions used in this document
                  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                  document are to be interpreted as described in RFC-2119 [1].
               Table of Contents
                  1.   Introduction................................................3
                  2.   Motivation..................................................4
                  3.   Bootstrapping scenarios.....................................5
                     3.1  Split Scenario...........................................5
                     3.2  Integrated Scenario......................................6
                  4.   Goals for the AAA-HA interface..............................7
                     4.1  General goals............................................7
                     4.2  Service Authorization....................................7
                     4.3  Accounting...............................................8
                     4.4  Mobile Node Authentication...............................8
                     4.5  Provisioning of configuration parameters.................8
                  5.   IANA Considerations.........................................9
                  6.   Security Considerations....................................10
                  7.   Acknowledgment.............................................11
                  8.   References.................................................12
                     8.1  Normative References....................................12
                     8.2  Informative References..................................12
                  AuthorsÂ’ Addresses..............................................13
               Giaretta, et al.        Expires - July 2006               [Page 2]

               Internet-Draft          AAA-HA interface goals          January 2006
               1. Introduction
                  Mobile IPv6 [2] was originally designed as a protocol without any
                  integration with the AAA infrastructure of the Mobility Service
                  Provider (MSP) that offers mobility service. Nonetheless, in some
                  environments it might be desirable to authenticate the user based on
                  existing credentials stored in the AAA infrastructure, to authorize
                  protocol operations and to enable accounting. Due to this
                  requirement, Mobile IPv6 might require the interaction with the AAA
                  infrastructure. Integrating the AAA infrastructure offers also a
                  solution component for Mobile IPv6 bootstrapping [3] in split [4]
                  and integrated [5] scenarios.
                  This document describes various scenarios where a AAA interface is
                  required. Additionally, it lists design goals and requirements for
                  such an interface.
                  This document only describes requirements, goals and scenarios. It
                  does not provide solutions.
                  Notice that this document builds on the security model of the AAA
                  infrastructure. As such, the end host shares credentials with the
                  home AAA server and the communication between the  AAA server and
                  the AAA client can be protected. If the AAA server and the AAA
                  client are not part of the same administrative domain, then some
                  sort of contractual relationship between the involved administrative
                  domains is typically in place in form of roaming agreements.
               Giaretta, et al.        Expires - July 2006               [Page 3]

               Internet-Draft          AAA-HA interface goals          January 2006
               2. Motivation
                  Mobile IPv6 specification [2] requires that Mobile Nodes (MNs) are
                  provisioned with a set of configuration parameters, namely the Home
                  Address and the Home Agent Address, in order to accomplish a home
                  registration. Moreover MNs and Home Agents (HAs) must share the
                  cryptographic material needed to protect Mobile IPv6 signaling (e.g.
                  shared keys or certificates to setup IPsec security associations).
                  One approach is to statically provision the necessary configuration
                  parameters at MNs and HAs. This solution is sub-optimal from a
                  deployment perspective, especially in large networks with a lot of
                  users (e.g., a mobile operator network). For this reason the Mobile
                  IPv6 bootstrapping problem was investigated [3]. Based on the
                  analysed scenarios (i.e. integrated and split), two solutions were
                  developed. The solution for the split scenario is described in [4]
                  and the one for the integrated scenario can be found at [5]. A key
                  point behind these mechanisms is that, whenever static provisioning
                  is not feasible, the AAA infrastructure of the MSP can be used as
                  the central element to enable dynamic Mobile IPv6 bootstrapping. In
                  this case the AAA infrastructure can be exploited to offload the end
                  host's authentication to the AAA server as well as to deliver the
                  necessary configuration parameters to the HA.
                  Moreover, in case Mobile IPv6 is a service offered by a Mobility
                  Service Provider (MSP), all protocol operations (e.g. home
                  registrations) may need to be explicitly authorized and monitored
                  (e.g. for accounting purposes). This can be accomplished relying on
                  the AAA infrastructure of the MSP, that stores users' service
                  profiles and credentials.
                  The deployment of this service model requires the availability of an
                  interface between the AAA infrastructure and the HA, that can be
                  seen as the Network Access Server (NAS) for Mobile IPv6. The core
                  capabilities that should be supported by this interface include
                  Mobile IPv6 service authorization and maintenance (e.g. asynchronous
                  service termination) as well as the exchange of accounting data.
                  This basic set of features is needed in any Mobile IPv6
                  bootstrapping scenario.
                  There is therefore space for the definition of a general AAA-HA
                  communication interface capable to support the basic features
                  described above (e.g. authorization and accounting) as well as the
                  extended capabilities (e.g. transfer of configuration data) needed
                  to enable various dynamic Mobile IPv6 bootstrapping scenarios.
               Giaretta, et al.        Expires - July 2006               [Page 4]

               Internet-Draft          AAA-HA interface goals          January 2006
               3. Bootstrapping scenarios
                  This section describes some bootstrapping scenarios in which a
                  communication between the AAA infrastructure of the Mobility Service
                  Provider and the Home Agent is needed.
               3.1 Split Scenario
                  In the split scenario [4], there is the assumption that the mobility
                  service and network access service are separate. This implies that
                  the mobility service can be authorized by a different entity
                  deploying its own AAA infrastructure. The entity offering the
                  mobility service is called Mobility Service Provider (MSP) while the
                  entity authorizing the service is the Mobility Service Authorizer
                  In this scenario, the Mobile Node discovers the Home Agent Address
                  using the Domain Name Service (DNS). It queries the address based on
                  the Home Agent name or by service name. In the former case, the
                  Mobile Node is configured with the  Fully Qualified Domain Name
                  (FDQN) of the Home Agent. In the latter case, the document [4]
                  defines a new service resource record (SRV RR).
                  Then the Mobile Node performs an IKEv2 [6] exchange with the HA to
                  setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure
                  its Home Address (HoA). The IKEv2 Mobile Node to Home Agent
                  authentication can be done using either public key signatures or the
                  Extensible Authentication Protocol (EAP).
                  If EAP is used for authentication, the operator can choose any
                  available EAP authentication methods. Note that even if EAP is used,
                  the MN authenticates the HA using public key signature based
                  authentication. The HA may rely on a remote EAP server. In this
                  case, a AAA protocol such as RADIUS EAP [7] or Diameter EAP Error!
                  Reference source not found. must be used between the HA and the home
                  EAP server. This allows a pool of HAs to rely on the same EAP server
                  to authenticate Mobile Nodes. It also allows the roaming mobility
                  case in which the Mobile Node obtains the mobility service in a
                  different administrative domain (MSP != MSA).
                  The Mobile Node may also want to update its FQDN in the DNS with the
                  newly allocated Home Address. The document [4] recommends that the
                  HA performs the DNS entry update on behalf of the Mobile Node. For
                  that purpose, the Mobile Node indicates its FDQN in the IKEv2
                  exchange (IDii field in IKE_AUTH) and adds a DNS Update Option in
                  the Binding Update message sent to the HA.
                  When the Mobile Node uses a Home Agent belonging to a different
                  administrative domain (MSP != MSA), the local HA may not share a
                  security association with the home DNS server. In this case, the
               Giaretta, et al.        Expires - July 2006               [Page 5]

               Internet-Draft          AAA-HA interface goals          January 2006
                  document [4] suggests the home AAA server to be responsible of the
                  update. Thus the HA should send to the home AAA server the FDQN-HoA
                  pair through the AAA protocol. Note that the AAA exchange between
                  the HA and the AAA infrastructure is normally terminated before the
                  HA receives the Binding Update message. The reason is that the
                  authentication has succeeded if the Mobile Node is able to send the
               3.2 Integrated Scenario
                  In the integrated scenario [5], the assumption is which the mobile
                  user's mobility service is authorized by the same authorizer than
                  network access service. Basically Mobility Service Authorizer (MSA)
                  and the Access Service Authorizer (ASA) are the same entity. The
                  scenario considers two cases:
                  1. Mobile Node requests a home agent to its home domain (ASA/MSA)
                  2. Mobile Node requests a home agent to the Access Service Provider
                  In the first case, Home Agent is allocated by user's home domain. In
                  the second case it is allocated by user's visited domain. In both
                  cases, it is assumed that the AAA server in the home domain (AAAH)
                  authorizes both network access service and mobility service.
                  In this scenario, Mobile Node discovers the Home Agent Address using
                  DHCPv6. During network access service authentication and
                  authorization, AAAH also verifies if authenticating user is
                  authorized to use mobility service. In affirmative case, AAAH sends
                  to the Network Access Server (NAS) where the Mobile Node is
                  attached, the information about the assigned home agent. Then NAS
                  stores that information. To request home agent data, Mobile Node
                  sends a DHCPv6 Information Request to the
                  All_DHCP_Relay_Agents_and_Servers multicast address. With this
                  request, Mobile Node can specify if it wants a home agent provided
                  by the visited domain (ASP) or by the home domain (ASA). In both
                  cases, the NAS acts a DHCPv6 relay. When the NAS receives DHCPv6
                  Information Request then it attaches home agent information received
                  from AAAH in a new DHC Relay Agent Option defined in [5].
                  In case Mobile Node cannot acquire home agent information via
                  DHCPv6, it can try the default mechanism based on DNS described in
                  [4]. After the Mobile Node has acquired home agent information, the
                  mechanism used to bootstrap the HoA, IPsec Security Association, and
                  Authentication and Authorization with the MSA is the same described
                  in the bootstrapping solution for split scenario [4].
               Giaretta, et al.        Expires - July 2006               [Page 6]

               Internet-Draft          AAA-HA interface goals          January 2006
               4. Goals for the AAA-HA interface
                  The motivations and scenarios illustrated in previous sections raise
                  the need to define an interface between the AAAH server and the HA.
                  The following sections list a set of goals for this interface.
               4.1 General goals
                  G1.1 The AAAH server and the HA MUST be able to authenticate each
                        other (mutual authentication) in order to prevent the
                        installation of unauthorized state on the HA.
                  G1.2 The AAA-HA interface MUST provide integrity protection in
                        order to prevent any alteration of exchanged data (e.g. Mobile
                        IPv6 configuration parameters).
                  G1.3 The AAA-HA interface MUST provide replay protection.
                  G1.4 The AAA-HA interface SHOULD provide confidentiality since it
                        may be used to transfer keying material (e.g. shared key
                        generated during EAP authentication).
                  G1.5 The AAA-HA interface should support inactive peer detection.
                        This functionality can be used by the AAAH server to maintain
                        a list of active HAs (e.g. useful for HA selection).
               4.2 Service Authorization
                  G2.1 The AAA-HA interface SHOULD allow the use of Network Access
                        Identifier (NAI) to identify the mobile node.
                  G2.2 The HA SHOULD be able to query the AAAH server to verify
                        Mobile IPv6 service authorization for the mobile node.
                  G2.3 The AAAH server MAY enforce explicit operational limitations
                        and authorization restrictions on the HA (e.g. packet filters,
                        QoS parameters).
                  G2.4 The AAAH server MUST be able to send an authorization lifetime
                        to the HA to limit Mobile IPv6 session duration for the MN.
                  G2.5 The HA MUST be able to request to the AAAH server an extension
                        of the authorization lifetime granted to the MN.
                  G2.6 The AAAH server MUST be able to force the HA to terminate an
                        active Mobile IPv6 session for authorization policy reasons
                        (e.g. credit exhaustion).
               Giaretta, et al.        Expires - July 2006               [Page 7]

               Internet-Draft          AAA-HA interface goals          January 2006
               4.3 Accounting
                  G3.1 The AAA-HA interface must support the transfer of accounting
                        records needed for service control and charging. These include
                        (but may not be limited to): time of binding cache entry
                        creation and deletion, octets sent and received by the mobile
                        node in Bi-directional Tunneling, etc.
               4.4 Mobile Node Authentication
                  G4.1 The AAA-HA interface MUST support pass-through EAP
                        authentication with the HA working as EAP authenticator
                        operating in pass-through mode and the AAAH server working as
                        back-end authentication server.
               4.5 Provisioning of configuration parameters
                  G5.1 The HA should be able to communicate to the AAAH server the
                        Home Address allocated to the MN (e.g. for allowing the AAAH
                        server to perform DNS update on behalf of the MN).
               Giaretta, et al.        Expires - July 2006               [Page 8]

               Internet-Draft          AAA-HA interface goals          January 2006
               5. IANA Considerations
                  No new message formats or services are defined in this document.
               Giaretta, et al.        Expires - July 2006               [Page 9]

               Internet-Draft          AAA-HA interface goals          January 2006
               6. Security Considerations
                  As stated in section 4.1 the AAA-HA interface must provide mutual
                  authentication, integrity and replay protection. Furthermore, if
                  security parameters (e.g. IKE pre-shared key) are transferred
                  through this interface, confidentiality is a feature that is
                  strongly recommended to be supported. However note that some
                  suitable interfaces may not provide end-to-end confidentiality
                  between AAA and HA (e.g. AAA protocols).
               Giaretta, et al.        Expires - July 2006               [Page 10]

               Internet-Draft          AAA-HA interface goals          January 2006
               7. Acknowledgments
                  The authors would like to thank James Kempf, Alper Yegin, Vijay
                  Devarapalli, Basavaraj Patil, Gopal Dommety for their comments and
                  feedback. Moreover the authors would like to thank Hannes Tschofenig
                  for his deep technical and editorial review of the draft.
               Giaretta, et al.        Expires - July 2006               [Page 11]

               Internet-Draft          AAA-HA interface goals          January 2006
               8. References
               8.1  Normative References
               [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
                   Levels", BCP 14, RFC 2119, March 1997.
               [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6",
                   RFC 3775, June 2004.
               8.2  Informative References
               [3] Patel, A. et al. "Problem Statement for bootstrapping Mobile IPv6",
                   draft-ietf-mip6-bootstrap-ps-02 (work in progress), March 2005.
               [4] Giaretta, G., Kempf, J. and Devarapalli, V., "Mobile IPv6
                   bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-
                   split-01 (work in progress), October 2005.
               [5] Chowdhury, K. and Yegin, A., "MIP6-bootstrapping via DHCPv6 for the
                   Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-
                   00 (work in progress), October 2005.
               [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",  draft-ietf-
                   ipsec-ikev2-17 (work in progress), September 2004.
               [7] Aboba, B. and Calhoun, P., "RADIUS (Remote Authentication Dial In
                   User Service) Support For Extensible Authentication Protocol
                   (EAP)", RFC 3579, September 2003.
               [8] Eronen, P., Hiller, T. and Zorn, G., "Diameter Extensible
                   Authentication Protocol (EAP) Application", RFC 4072, August 2005.
               [9] Chowdhury, K. and Lior, A., "RADIUS Attributes for Mobile IPv6
                   bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in
                   progress), October 2004.
               [10]  Jang, H. J. and Yegin, A., "DHCP Option for Home Agent Discovery
                   in MIPv6", draft-jang-dhc-haopt-01 (work in progress), April 2005.
               [11]  Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., Laurent-
                   Maknavicius, M., "MIPv6 Authorization and Configuration based on
                   EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress),
                   September 2004.
               Giaretta, et al.        Expires - July 2006               [Page 12]

               Internet-Draft          AAA-HA interface goals          January 2006
               AuthorsÂ’ Addresses
                  Gerardo Giaretta
                  Telecom Italia Lab
                  via G. Reiss Romoli, 274
                  10148 TORINO
                  Phone: +39 011 2286904
                  Email: gerardo.giaretta@tilab.com
                  Ivano Guardini
                  Telecom Italia Lab
                  via G. Reiss Romoli, 274
                  10148 TORINO
                  Phone: +39 011 2285424
                  Email: ivano.guardini@tilab.com
                  Elena Demaria
                  Telecom Italia Lab
                  via G. Reiss Romoli, 274
                  10148 TORINO
                  Phone: +39 011 2285403
                  Email: elena.demaria@tilab.com
                  Julien Bournelle
                  9 rue Charles Fourier
                  Evry  91011
                  Email: julien.bournelle@int-evry.fr
                  Rafa Marin Lopez
                  University of Murcia
                  30071 Murcia
                  EMail: rafa@dif.um.es
               Giaretta, et al.        Expires - July 2006               [Page 13]

               Internet-Draft          AAA-HA interface goals          January 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
               Disclaimer of Validity
                  This document and the information contained herein are provided on
                  an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
               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.
                  Funding for the RFC Editor function is currently provided by the
                  Internet Society.
               Giaretta, et al.        Expires - July 2006               [Page 14]