[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-giaretta-mip6-aaa-ha-goals) 00 01 02 03

   MIP6 Working Group                                       G. Giaretta
   Internet Draft                                           I. Guardini
   Expires: Ocotber 29 2005                                  E. Demaria
                                                                  TILab
                                                           J. Bournelle
                                                                GET/INT
                                                               R. Lopez
                                                        Univ. of Murcia
                                                             April 2005


                        Goals for AAA-HA interface
                   draft-ietf-mip6-aaa-ha-goals-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 October 29, 2005.

   Copyright Notice

      Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   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 explicitely authorized and traced. A
   convenient approach to do that is to define an interface between the
   Home Agent (HA) and the AAA infrastructure of the MSP, which stores
   user's credentials and service profiles. The availability of this
   interface can be useful also to enable dynamic Mobile IPv6
   bootstrapping on both the mobile node and the designated HA. 

Internet-Draft          AAA-HA interface goals          September 2004

   This document describes various scenarios where an interface between
   the HA and the AAA infrastructure of the MSP is required.
   Furthermore, a list of design goals for this interface is provided.

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.   Basic security model........................................5
   4.   Bootstrapping scenarios.....................................6
      4.1  Scenario 1...............................................6
      4.2  Scenario 2...............................................6
      4.3  Scenario 3...............................................7
      4.4  Scenario 4...............................................8
   5.   Goals for the AAA-HA interface..............................9
      5.1  General goals............................................9
      5.2  Service Authorization....................................9
      5.3  Accounting..............................................10
      5.4  Mobile Node Authentication..............................10
      5.5  Provisioning of configuration parameters................10
   6.   Mapping between goals and scenarios........................11
   7.   IANA Considerations........................................12
   8.   Security Considerations....................................13
   9.   Acknowledgment.............................................14
   10.  References.................................................15
      10.1   Normative References..................................15
      10.2   Informative References................................15
   AuthorsÆ Addresses..............................................16
















Giaretta, et al.        Expires - October 2005               [Page 2]

Internet-Draft          AAA-HA interface goals          September 2004

1. Introduction

   Mobile IPv6 [2] was originally designed as a standalone protocol to
   handle terminal mobility relying on a centralized and pre-configured
   Home Agent (HA). Nonetheless, if Mobile IPv6 is a service offered by
   a Mobility Services Provider (MSP), all protocol operations may need
   to be explicitely authorized and traced (e.g. for accounting
   purposes). A convenient approach to achieve this result is to define
   an interface between the AAA infrastructure of the MSP and the HA.
   Such an interface may be useful also in some Mobile IPv6 dynamic
   bootstrapping scenarios [3].

   This document describes various scenarios for which an interface
   between the HA and the AAA infrastructure of the MSP is useful.
   Furthermore, a list of goals for such an interface is provided.

   No assumptions are made on the protocol used to implement the
   interface. An obvious choice may be the employment of a AAA protocol
   such as RADIUS or Diameter. Nonetheless, for some scenarios, other
   non AAA protocols such as SNMPv3 [5] or COPS-PR [6] may satisfy all
   the goals described herewith.































Giaretta, et al.        Expires - October 2005               [Page 3]

Internet-Draft          AAA-HA interface goals          September 2004

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 an IPsec security association).

   The simplest option is to statically provision all the necessary
   configuration data on MNs and HAs. This solution raises obvious
   scalability issues especially in a large network with a lot of users
   (e.g. a mobile operator network). For this reason the dynamic Mobile
   IPv6 bootstrapping problem is currently under study [3].

   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 explicitely 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 is the basic set of features needed in any Mobile IPv6
   bootstrapping scenario (i.e. static or dynamic).

   Moreover, whenever static provisioning is not feasible, the AAA
   infrastructure of the MSP can be used as the central element to
   build a dynamic Mobile IPv6 bootstrapping solution. In this case the
   AAA infrastructure can be exploited also to send to the designated
   HA the needed configuration parameters (e.g. keying material) as
   well as to assist the HA with mobile node authentication.

   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 - October 2005               [Page 4]

Internet-Draft          AAA-HA interface goals          September 2004

3. Basic security model

   The basic security model behind this draft assumes that the mobile
   node shares a pre-configured trust relationship with the AAA server
   of the MSP (AAAH), as stated in [3]. Furthermore the HA is expected
   to share a trust relationship with the AAAH server (see Figure 1).


                     MN               AAAH              HA
                     ^                ^  ^               ^
                     |                |  |               |
                     +----------------+  +---------------+
                     trust relationship  trust relationship

                          Figure 1 - Basic Model





































Giaretta, et al.        Expires - October 2005               [Page 5]

Internet-Draft          AAA-HA interface goals          September 2004

4. 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. These scenarios include both
   dynamic (Scenario 1 and Scenario 2) and static (Scenario 3 and
   Scenario 4) bootstrapping.

4.1 Scenario 1

   In this scenario, depicted in Figure 2, the MN discovers the Home
   Agent address (e.g. by means of a new DNS SRV record or DHCP) and
   performs an IKEv2 [4] exchange with the HA to setup the IPsec SA
   needed to protect mobility signaling. Eventually, during this
   handshake, the MN can also obtain a valid Home Address from the HA.

   The MN is not expected to share a pre-configured trust relationship
   with the HA, nor to share a secret with it. For this reason, peer
   authentication in IKEv2 can be performed through an EAP exchange.
   The HA, behaving as an EAP authenticator operating in pass-through
   mode, forwards this EAP exchange to the AAAH server, that can
   authenticate the MN and authorize the Mobile IPv6 service.
   Therefore, in this case an interface between the HA and the AAAH
   server is needed at least for authentication and authorization
   purposes.

                 MN                AAAH            HA

                   <---------- IKEv2(EAP) -------->

                                        <--------->
                                      AAA-HA protocol

       Figure 2 - Dynamic MIPv6 bootstrapping through IKEv2 and EAP

4.2 Scenario 2

   In this scenario Mobile IPv6 bootstrapping is performed during
   network access authentication (it is assumed that the access
   provider and the MSP are the same entity, i.e. Integrated ASP [3])
   and the AAA server of the MSP (AAAH) controls the whole
   bootstrapping procedure interacting with both the mobile node and
   the designated HA.

   The AAAH server and the MN can exploit AAA routing to exchange
   configuration data. Possible approaches to implement this
   communication are the following:

   - if network access authentication is carried out using EAP, it is
     possible to piggyback Mobile IPv6 configuration parameters (e.g.


Giaretta, et al.        Expires - October 2005               [Page 6]

Internet-Draft          AAA-HA interface goals          September 2004

     Home Agent address, Home Address) within the EAP exchange [7]. See
     Figure 3;

   - alternatively, Mobile IPv6 parameters can be transferred to the
     Network Access Server (NAS) by means of RADIUS or Diameter AVPs
     [8] and then forwarded to the MN through other means (e.g. L2-
     specific extensions, DHCP [9]). See Figure 4 for an example.

   In both cases, the AAAH server must communicate with the designated
   HA to select a suitable Home Address for the MN and to deliver to
   the HA the necessary configuration parameters (e.g. pre-shared key
   for IKE bootstrapping). Therefore in this scenario an interface
   between the AAAH server and the HA must be defined for parameter
   exchange as well as authentication and Mobile IPv6 service
   authorization.

              MN                          AAAH           HA
                <------------------------>     <-------->
                  Piggybacking of MIPv6      AAA-HA protocol
                     data within EAP

       Figure 3 - MIPv6 bootstrapping with piggybacking within EAP


              MN            NAS           AAAH           HA
                <---------->   <--------->     <-------->
                L2-specific       MIPv6      AAA-HA protocol
                extensions     RADIUS AVPs

             Figure 4 - MIPv6 bootstrapping with RADIUS AVPs

4.3 Scenario 3

   In this scenario the MN is statically provisioned with the data
   needed to bootstrap Mobile IPv6 service (i.e. Home Agent Address,
   Home Address and a shared secret with the HA). For example, the MN
   can be configured with a pre-shared key to dynamically establish an
   IPsec Security Association with the HA using IKE.

   However, in general the static configuration of these parameters and
   the authentication performed through the pre-shared key may not be
   sufficient to conclude that the MN is authorized for MIPv6 service.
   For example, the MSP might want to prevent the usage of MIPv6 if the
   the credit of the MN is going to exhaust. Moreover, there might be
   the need for the MSP to enforce more complex dynamic authorization
   policies based on time of day and/or visited location.

   This implies that during the IKE exchange the HA must communicate
   with the AAAH server in order to explicitly authorize MIPv6 service
   for that particular MN. See Figure 5.


Giaretta, et al.        Expires - October 2005               [Page 7]

Internet-Draft          AAA-HA interface goals          September 2004





                 MN                AAAH             HA

                   <-------------- IKE ------------>

                                       <----------->
                                      AAA-HA protocol

      Figure 5 - Mobile IPv6 authorization with static boostrapping

4.4 Scenario 4

   In this scenario, the IPsec SA between MN and HA is statically and
   manually configured, thus the MN does not need to perform an IKE
   exchange with the HA. The MN activates MIPv6 service, sending a
   Binding Update message to the HA in order to update its location.

   The presence of the IPsec SA between MN and HA is enough in order to
   authenticate the binding management messages. However, it is not
   enough to authorize MIPv6 service; thus, as soon as it receives a
   Binding Update, the HA must explicitly authorize MIPv6 service
   interacting with the AAAH server (Figure 6). For this purpose, an
   interface between the HA and the AAAH is needed at least for
   authorization purposes.

   If deemed necessary, the explicit authorization of Binding Updates
   based on the handshake depicted in Figure 5 can be used also in the
   bootstrapping scenarios described in the previous sections. It may
   be useful to enforce dynamic authorization policies, such as those
   based on the MN's location.

                 MN               AAAH             HA

                      ------------ BU ------------>

                                      <----------->
                                     AAA-HA protocol

                      <----------- BA -------------

                 Figure 6 - Binding Update Authorization








Giaretta, et al.        Expires - October 2005               [Page 8]

Internet-Draft          AAA-HA interface goals          September 2004

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

5.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 security parameters (e.g. IKE pre-
        shared key).

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

5.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 should be able to enforce explicit operational
        limitations and authorization restrictions on the HA (e.g.
        packet filters, QoS parameters).

   G2.4 The AAAH server should be able to send an authorization
        lifetime to the HA to limit Mobile IPv6 session duration for
        the MN.

   G2.5 The HA should be able to request to the AAAH server an
        extension of the authorization lifetime granted to the MN.

   G2.6 The AAAH server should 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 - October 2005               [Page 9]

Internet-Draft          AAA-HA interface goals          September 2004

   G2.7 The AAAH server should be able to retreive 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.

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

5.4 Mobile Node Authentication

   G4.1 The AAA-HA interface should support MN authentication (and re-
        authentication) with the HA working as NAS and the AAAH server
        working as back-end authentication server.

   G4.2 The AAA-HA interface should support at least 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.

5.5 Provisioning of configuration parameters

   G5.1 The AAAH server should be able to poll the designated HA for
        the allocation of a Home Address to the MN. Optionally, the
        AAAH server can provide a set of hints for the construction of
        the Home Address (e.g. a preferred Home Address or a preferred
        Interface Identifier).

   G5.2 The HA should be able to communicate to the AAAH server the
        Home Address allocated to the MN.

   G5.3 The AAAH server should be able to send to the HA the security
        data needed to setup the IPsec SA between the MN and the HA.
        Possible security data are the authentication method and the
        cryptographic material to be used for IKE bootstrapping.













Giaretta, et al.        Expires - October 2005               [Page 10]

Internet-Draft          AAA-HA interface goals          September 2004

6. Mapping between goals and scenarios

   The table below shows which goals, among those listed in section 5,
   are strictly (X) or optionally (O) required for each of the
   scenarios discussed in section 4.


        Section           +---------------------------------------+
        Defined   Goals   | Scen. 1 | Scen. 2 | Scen. 3 | Scen. 4 |
       -------------------+---------|---------|---------|---------|
                   G1.1   |    X    |    X    |    X    |    X    |
                   G1.2   |    X    |    X    |    X    |    X    |
          5.1      G1.3   |    X    |    X    |    X    |    X    |
                   G1.4   |    O    |    X    |    O    |    O    |
                   G1.5   |    X    |    X    |    X    |    X    |
       -------------------|---------|---------|---------|---------|
                   G2.1   |    X    |    X    |    O    |    O    |
                   G2.2   |    X    |    X    |    X    |    X    |
                   G2.3   |    X    |    X    |    X    |    X    |
          5.2      G2.4   |    X    |    X    |    X    |    X    |
                   G2.5   |    X    |    X    |    X    |    X    |
                   G2.6   |    X    |    X    |    X    |    X    |
                   G2.7   |    X    |    X    |    X    |    X    |
       -------------------|---------|---------|---------|---------|
          5.3      G3.1   |    X    |    X    |    X    |    X    |
       -------------------|---------|---------|---------|---------|
          5.4      G4.1   |    X    |         |         |         |
                   G4.2   |    X    |         |         |         |
       -------------------|---------|---------|---------|---------|
                   G5.1   |         |    X    |         |         |
          5.5      G5.2   |         |    X    |         |         |
                   G5.3   |         |    X    |         |         |
       -------------------+---------+---------+---------+---------+



















Giaretta, et al.        Expires - October 2005               [Page 11]

Internet-Draft          AAA-HA interface goals          September 2004

7. IANA Considerations

   No new message formats or services are defined in this document.

















































Giaretta, et al.        Expires - October 2005               [Page 12]

Internet-Draft          AAA-HA interface goals          September 2004


8. Security Considerations

   As stated in section 5.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 support is also required.













































Giaretta, et al.        Expires - October 2005               [Page 13]

Internet-Draft          AAA-HA interface goals          September 2004

9. Acknowledgment

   The authors would like to thank James Kempf, Alper Yegin, Vijay
   Devarapalli, Basavaraj Patil, Gopal Dommety and Hannes Tschofenig
   for their comments and feedback.















































Giaretta, et al.        Expires - October 2005               [Page 14]

Internet-Draft          AAA-HA interface goals          September 2004


10. References

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

10.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] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
   draft-ietf-ipsec-ikev2-17 (work in progress), September 2004.

[5] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and
   Applicability Statements for Internet-Standard Management
   Framework", RFC 3410, December 2002.

[6] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F.
   Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for
   Policy Provisioning,", RFC 3084, March 2001.

[7] 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.

[8] Chowdhury, K. and Lior, A., "RADIUS Attributes for Mobile IPv6
   bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in
   progress), October 2004.

[9] Jang, H. J. and Yegin, A., "DHCP Option for Home Agent Discovery in
   MIPv6", draft-jang-dhc-haopt-01 (work in progress), April 2005.








Giaretta, et al.        Expires - October 2005               [Page 15]

Internet-Draft          AAA-HA interface goals          September 2004


AuthorsÆ Addresses

   Gerardo Giaretta
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy
   Phone: +39 011 2286904
   Email: gerardo.giaretta@tilab.com

   Ivano Guardini
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy
   Phone: +39 011 2285424
   Email: ivano.guardini@tilab.com

   Elena Demaria
   Telecom Italia Lab
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy
   Phone: +39 011 2285403
   Email: elena.demaria@tilab.com

   Julien Bournelle
   GET/INT
   9 rue Charles Fourier
   Evry  91011
   France
   Email: julien.bournelle@int-evry.fr

   Rafa Marin Lopez
   University of Murcia
   30071 Murcia
   Spain
   EMail: rafa@dif.um.es













Giaretta, et al.        Expires - October 2005               [Page 16]

Internet-Draft          AAA-HA interface goals          September 2004


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

   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.





Giaretta, et al.        Expires - October 2005               [Page 17]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/