[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

   MIP6 Working Group                                       G. Giaretta
   Internet Draft                                           I. Guardini
   Expires: August 2004                                      E. Demaria
                                                                  TILab
                                                          February 2004


            MIPv6 Authorization and Configuration based on EAP
              <draft-giaretta-mip6-authorization-eap-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

   This draft defines an architecture, and related protocols, for
   performing dynamic Mobile IPv6 authorization and configuration
   relaying on a AAA infrastructure. The necessary interaction between
   the AAA server of the home provider and the mobile node is realized
   using EAP, exploiting the capability of some EAP methods to convey
   generic information items together with authentication data. This
   approach has the advantage that the access equipment acts just as a
   pass-through for EAP messages and therefore does not play any active
   role in the Mobile IPv6 negotiation procedure, which makes the
   solution easier to deploy and maintain.
   The same approach can be ported also to environments performing user
   authentication with methods other than EAP (e.g. GSM, UMTS or CDMA),
   by simply using PANA with null authentication to undertake MIPv6
   negotiation after the user has gained IP access to the network.



Giaretta Guardini Demaria       Expires - August 2004         [Page 1]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



Table of Contents

   1.   Introduction................................................2
   2.   Protocol Overview...........................................3
   3.   Detailed Description of the Protocol........................6
      3.1  Mobile Node bootstrap....................................7
      3.2  Management of reauthentication events...................15
      3.3  Session Termination.....................................16
   4.   Home Agent considerations..................................19
      4.1  Service Authorization Cache (SAC).......................19
      4.2  Management of Binding Cache entries.....................19
   5.   Protocol Applicability in Cellular Networks................20
   6.   New Messages and Attributes................................24
      6.1  New EAP-TLVs............................................24
      6.2  New Diameter messages and AVPs..........................29
   7.   Open Issues................................................31
   8.   Security Considerations....................................32
   Acknowledgments.................................................32
   References......................................................32
   Appendix A - Home Agent allocation in a foreign domain..........34
   Authors' Addresses..............................................37
   Intellectual Property Statement.................................37



1. Introduction

   Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents
   (HAs) share a set of configuration parameters: for example, the MN
   must know its Home Address, the Home Agent Address and the
   cryptographic material needed to protect MIPv6 signaling (e.g. shared
   keys or certificates to setup an IPsec security association). MIPv6
   base protocol does not specify any method to automatically acquire
   this information; which means that network administrators are
   normally required to manually set configuration data on MNs and HAs.

   Manual configuration of Home Agents and Mobile Nodes also works as an
   implicit method for Mobile IPv6 authorization, because only the users
   that have been administratively enabled on a specific Home Agent are
   allowed to exploit Mobile IPv6 and its features.

   However, in a large network (e.g. the network of a mobile operator),
   which may include millions of users and many Home Agents, the
   operational and administrative burden of this procedure may easily
   become overwhelming. In addition, the extensive use of manual and
   static configurations limits the flexibility and reliability of the
   system, in that it is not possible to dynamically assign the HA when
   the user enters the network, which would help to optimize performance


Giaretta Guardini Demaria       Expires - August 2004         [Page 2]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   and resource utilization (e.g. assignment of the HA closest to the
   MN's point of attachment).

   With the objective to solve the limitations described above, this
   draft defines an architecture, and related protocols, for performing
   dynamic Mobile IPv6 authorization and configuration relaying on a AAA
   infrastructure. The necessary interaction between the AAA server of
   the home provider and the mobile node is realized using EAP,
   exploiting the capability of some EAP methods, and in particular
   PEAPv2 [2], to convey generic information items together with
   authentication data.

   The suggested approach can be deployed, with no changes to existing
   access equipment (Access Points, Access Gateways, etc.), in any
   network supporting EAP-based authentication (e.g. IEEE 802.1x
   Wireless LANs), but can be ported also to environments performing
   user authentication with methods other than EAP (e.g. GSM, UMTS or
   CDMA), by simply using PANA [9] with null authentication to undertake
   MIPv6 negotiation after the user has gained IP access to the network.


2. Protocol Overview

   The basic idea behind the solution proposed herewith is to perform
   Mobile IPv6 authorization and configuration during the authentication
   procedure undertaken by the Mobile Node to gain network access.
   In particular, this draft defines a method to:

   - explicitly authorize the use of Mobile IPv6 based on the service
     profile of the user, its position within the network, etc.

   - dynamically allocate a Home Agent to the Mobile Node;

   - dynamically configure Mobile IPv6 start-up parameters on both the
     Home Agent and the Mobile Node. These parameters include the Home
     Address and the cryptographic material needed to set-up the IPsec
     Security Association used to protect Mobile IPv6 signaling (i.e.
     Binding Updates and Binding Acknowledges);

   - allow the MN to negotiate additional Mobile IPv6 service options,
     such as the possibility to use multiple access networks at the
     same time (i.e. registration of multiple Care-of Addresses), the
     assignment of a HA within the visited domain, etc.

   Figure 1 shows the overall architecture of the solution proposed in
   this draft. The central element of the architecture is the AAA server
   of the Home Domain (i.e. AAAH), which interacts with both the MN and
   the selected HA to perform service authorization and configuration.



Giaretta Guardini Demaria       Expires - August 2004         [Page 3]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


                                  AAA
                                 Client
                  IEEE 802.1x   +------+      RADIUS
                   or PANA      |      |    or Diameter
    +--------+ /---------------TLS Tunnel------------------\ +--------+
    | Mobile |/ <------------Authentication---------------> \|  AAAH  |
    |  Node  |\ <--MIPv6 authorization and configuration--> /| Server |
    +--------+ \-------------------------------------------/ +--------+
                                |      |                         /\
                                +------+                        /||\
                                 Router                          ||
                                 or AP               Diameter    ||
                             (pass-through)          HA Appl.    ||
                                                                \||/
                                                                 \/
                                                             +--------+
                                                             |  Home  |
                                                             |  Agent |
                                                             +--------+

                     Figure 1 - Solution architecture


   The solution can be deployed in any access network where EAP [3] and,
   in particular, PEAPv2 [2] are used to perform user authentication;
   this is because the messages exchanged between the MN and the AAAH
   server to achieve dynamic Mobile IPv6 authorization and configuration
   are carried in EAP-TLVs (i.e. information fields in the form of Type
   Length Value) delivered within the TLS tunnel created in the phase 1
   of PEAPv2. Anyway, the same approach could be ported to any other EAP
   method having the capability to establish a secure tunnel between the
   MN and the AAAH server (e.g. EAP-TTLS [4]).

   Figure 2 shows an overview of the procedure defined to handle MIPv6
   bootstrap on the Mobile Node. The whole procedure can be divided in
   five steps:

   1.EAP identity exchange (i.e. exchange of EAP Request Identity and
     EAP Response Identity messages);

   2.PEAPv2 Phase 1: MN and AAAH establish a TLS tunnel to protect
     subsequent authentication data. This phase is completely
     conformant to [2];

   3.PEAPv2 Phase 2: MN and AAAH negotiate an EAP method (e.g. EAP-MD5,
     EAP-SIM, EAP-AKA) and undertake the authentication phase. Then,
     within the TLS tunnel, MN and AAAH exchange a sequence of EAP-TLVs
     to authorize and configure Mobile IPv6. During this phase, AAAH
     selects a suitable Home Agent for the MN and exchanges


Giaretta Guardini Demaria       Expires - August 2004         [Page 4]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


     authorization and configuration data with it using a new Diameter
     Application. At the end of this phase, the MN knows its own Home
     Address, the address of the correspondent Home Agent and the
     cryptographic material (e.g. pre-shared key) needed to set-up an
     IPsec security association with IKE;

   4.EAP session termination (EAP Success/Failure);

   5.set-up of IPsec Security Association and MIPv6 registration: at
     the end of the EAP communication, the MN gains network access and
     acquires a valid Care-of Address within the visited subnet (e.g.
     stateless autoconfiguration); then, using the cryptographic
     material collected in PEAPv2 phase 2, it performs an IKE exchange
     to establish the IPsec Security Association with the HA. Finally,
     the MN performs MIPv6 registration, sending a Binding Update
     (protected with IPsec) to the HA.

         EAP over
        IEEE 802.1x     EAP over Diameter               Diameter
         (or PANA)         (or RADIUS)      AAAH     HA Application
    MN +----------+ AP +-----------------+ Server +-----------------+ HA

   1) <--Req. Id.---
      --Identity--->  --Diameter EAP Req.-->
       /----------------------------------\
   2) /          PEAPv2 Phase 1:           \
      \        set-up of TLS tunnel        /
       \----------------------------------/
       /----------------------------------\ +-+ /------------------\ +-+
   3) /   PEAPv2 Phase 2: authentication   \| |/   Home Address     \| |
      \     and Mobile IPv6 negotiation    /| |\     Selection      /| |
       \----------------------------------/ +-+ \------------------/ +-+
                                         Home Agent                  DAD
                                         Selection

   4) <-----EAP-----  <-----Diameter EAP----
      Success/Failure  Answer (Success/Failure
                       and authorization AVPs)

       /-----------------------------------------------------------\
   5) /           Set-up Security Association MN-HA and             \
      \             Mobile IPv6 registration (BU, BA)               /
       \-----------------------------------------------------------/

          Figure 2 - Overview of Mobile IPv6 bootstrap procedure


   This draft also defines the procedures to handle re-authentication
   events and to manage the termination of the Mobile IPv6 session.


Giaretta Guardini Demaria       Expires - August 2004         [Page 5]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   In summary, the proposed architecture has the following advantages:

   - allows the operator to maintain a centralized management (on the
     AAA server) of the user profiles and the authentication,
     authorization and accounting procedures for any type of service,
     including Mobile IPv6;

   - improves the reliability and performance of the Mobile IPv6
     protocol, in that the HA to be dynamically assigned to the MN can
     be freely chosen among those that are closest to the user's point
     of attachment, thus optimizing network usage and reducing the
     transfer delay for data traffic in bi-directional tunneling;

   - can be deployed, or extended with new features, without having to
     update the access equipment and the AAA protocols in use. Only
     minor changes in the AAA servers, the Home Agents and the mobile
     terminals are required, in that the AAA client does not play any
     active role in MIPv6 negotiation (i.e. it is a pass-through for
     EAP signaling). This reduces the deployment costs and makes the
     solution easy to use even when a Mobile Node is roaming with a
     provider different from its own;

   - allows the usage of any AAA protocol supporting the transport of
     EAP messages for the communication between the AAA client and
     server (i.e. not just Diameter, but also RADIUS). This
     significantly simplifies the deployment of the arrangement
     described herein in existing communication networks, where support
     for Diameter protocol in access equipment is not so extensive.

   Conversely, the drawback of the solution is the high number of RTTs
   needed for the completion of the entire procedure. This limitation is
   mainly due to the choice of relaying on a tunneled EAP method (such
   as PEAPv2) for exchanging protected signaling related to MIPv6 during
   the authentication phase. Nevertheless, it should be noted that the
   full procedure can be undertaken by the MN only during its initial
   bootstrap, and therefore the performance requirements are not so
   strict.


3. Detailed Description of the Protocol

   This section details all the procedures and message exchanges that
   can be used by the network operator to explicitly authorize the
   activation of Mobile IPv6 support for a specific user as well as
   enable dynamic negotiation of MIPv6 protocol parameters (e.g. Home
   Address, Home Agent Address).




Giaretta Guardini Demaria       Expires - August 2004         [Page 6]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   For the sake of simplicity, protocol description is carried out
   assuming that the access network is a Wireless LAN IEEE 802.11 where
   user authentication is performed at Layer 2 through IEEE 802.1x and
   EAP. However, the same approach can be deployed in any other network
   using EAP for access control.


3.1 Mobile Node bootstrap

   In a WLAN where IEEE 802.1x and EAP are used for access control, when
   the MN enters the network it immediately receives an EAP Request
   Identity message. This message is used to start the EAP
   communication. The MN replies sending its identity, in the form of a
   NAI (Network Access Identifier), within an EAP Response Identity
   message, that is received by a local attendant (i.e. the Access Point
   in the case of a WLAN) and  forwarded to AAAH using the Diameter EAP
   Application (or the RADIUS EAP extensions). Then the AAAH server
   selects an EAP method (e.g. based on the user service profile) and
   proposes it to the MN in subsequent EAP messages. In order to use the
   MIPv6 negotiation procedure defined in this document, the EAP method
   chosen by the AAAH server must be PEAPv2 or another tunneled EAP
   method supporting the transport of optional information fields.

   After this initial handshake, MN and AAAH establish a TLS tunnel
   exchanging PEAPv2 phase 1 messages. The procedure is the same
   specified in [2] and the Access Point acts as a simple pass-through
   for all the signaling transferred, on an end-to-end basis, between
   the MN and the AAA server.

   As soon as the TLS tunnel is established, the actual authentication
   phase takes place and all messages exchanged between MN and AAAH are
   encrypted through the TLS Security Association. The authentication
   can be based on any EAP method (e.g. EAP-MD5, EAP-SIM, EAP-AKA): the
   choice can be done based on the desired security level and keeping in
   mind that the EAP method affects the number of RTTs needed to
   accomplish the authentication.

   The authentication procedure performed within the TLS tunnel (i.e.
   inner authentication) can be divided in three main steps:

   1.Identity Exchange: exchange of EAP Identity Request/Reply
     messages;

   2.Authentication Algorithm: this is the real authentication
     procedure. The number of round trips (RTTs) needed to complete
     this phase depends on the EAP method chosen to perform inner
     authentication;




Giaretta Guardini Demaria       Expires - August 2004         [Page 7]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   3.Authentication Result: in the last round trip, AAAH sends to the
     MN the result of the authentication procedure (success/failure)
     and the MN confirms the reception of this notification.

   PEAPv2 phase 2 messages exchanged within the TLS tunnel are conveyed
   in EAP-TLVs, according to the latest version of PEAPv2 specification.

   As soon as the authentication phase is completed (i.e. MN has
   received an EAP Response message containing an Intermediate-Result-
   TLV), the procedure for Mobile IPv6 authorization and parameter
   negotiation takes place. This is achieved exploiting the TLS tunnel
   to exchange a sequence of EAP messages containing a new TLV, called
   MIPv6-Authorization-TLV (see section 6.1), that is a very generic TLV
   containing other, more specific, TLVs.

   AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6-
   Authorization-TLV including the following TLVs:

   - Service-Status-TLV: used to communicate to the MN whether the
     Mobile IPv6 service is actually available, or unavailable, in the
     visited location; this might depend on characteristics of the
     visited domain, on the user service profile or on other
     administrative rules (e.g. service accountability);

   - Service-Options-TLV (optional): used to specify other service
     options the MN can ask for (possibility to register multiple CoAs,
     allocation of a HA in the visited domain, etc.). See Appendix A
     for an example.

   MN replies to this first message confirming its intention to start
   Mobile IPv6 and, optionally, providing a set of hints on the desired
   service capabilities; this is achieved delivering a MIPv6-
   Authorization-TLV including the following TLVs:

   - Service-Selection-TLV: used by the MN to specify if it is willing
     to activate Mobile IPv6 protocol operation;

   - Service-Options-TLV (optional): used by the MN to communicate
     which service options, among those previously advertised by AAAH,
     it would like make use of;

   - Home-Agent-Address-TLV (optional): used by the MN to suggest a
     preferred Home Agent (e.g. a HA with whom the MN has a pre-
     configured Security Association). The AAAH server treats this
     indication just as a hint, which means that, for administrative
     reasons, the MN may be assigned a Home Agent different from the
     one previously requested;




Giaretta Guardini Demaria       Expires - August 2004         [Page 8]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   - Home-Address-TLV (optional): used by the MN to suggest a preferred
     Home Address (e.g. an address pre-configured on one of its network
     interfaces); like the previous TLV, this indication is considered
     only as a hint by the AAAH;

   - Interface-Identifier-TLV (optional): through this TLV, the MN can
     suggest a preferred Interface Identifier (selected according to
     [5] or following other criteria) to be used by the AAA
     infrastructure to build the Home Address starting from the
     selected home prefix. Also in this case, this information, if
     present, is treated as a pure hint by AAAH.

   The whole message exchange is depicted in Figure 3. For the sake of
   simplicity, the diagram shows only the content of the EAP-TLVs
   exchanged within the TLS tunnel in place between the MN and AAAH
   server.

                   PEAPv2                           Diameter
                 TLS Tunnel            AAAH      HA Application
    MN +----------------------------+ Server +---------------------+ HA

                   <---------------------
                    EAP-TLV(MIPv6-Authorization-TLV(
                    Service-Status, [Service-Options]))

     ----------------------->
     EAP-TLV(MIPv6-Authorization-TLV(
     Service-Selection, [Service-Options],
     [Home-Agent-Address], [Home-Address],
     [Interface-Identifier]))

          Figure 3 - Mobile IPv6 authorization: initial handshake


   If in the Service-Selection-TLV the MN has chosen not to make use of
   Mobile IPv6, AAAH immediately terminates the EAP communication
   skipping any further MIPv6 negotiation.

   Otherwise, if the MN has confirmed its willingness to start MIPv6
   service, AAAH selects a suitable Home Agent through a Home Agent
   Selection Algorithm. Possible parameters to be taken into account by
   this algorithm include: current load of available HAs, location of
   the MN and, eventually, the preferences provided by the MN itself in
   the previous message exchange (i.e. Service-Options-TLV, Home-Agent-
   Address-TLV, Home-Address-TLV). However, the detailed definition of a
   Home Agent Selection Algorithm is out of the scope of this document.

   As soon as a suitable HA has been identified, AAAH interacts with it
   to dynamically configure all the state needed to enable subsequent


Giaretta Guardini Demaria       Expires - August 2004         [Page 9]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   MIPv6 protocol operations. The communication between AAAH and HA is
   achieved through a new Diameter Application defined in this document,
   that is called Diameter Home Agent Application and is similar to the
   one specified in [6].

   AAAH starts the handshake sending to the designated HA a Diameter
   Home Address Request (HAR) message containing the following AVPs:

   - User-Name-AVP: specifies the MN's identity, that is the NAI
     provided by the user while executing the inner EAP method;

   - Home-Address-AVP or Interface-Identifier-AVP (optional): specify
     the Home Address, or the Interface Identifier, provided by the MN
     in the correspondent TLVs (i.e. Home-Address-TLV and Interface-
     Identifier-TLV);

   - HA-Features-AVP (optional): lists the additional features that the
     HA is required to provide to the mobile node (e.g. support for the
     registration of multiple CoAs). The content of this AVP is set by
     the AAAH server based on the negotiation undertaken with the MN
     through the Service-Options-TLV.

   When the HA receives the message, it picks up a Home Address for the
   MN, generating an Interface Identifier based on [5] or using the
   hints included in the Home-Address-AVP (or in the Interface-
   Identifier-AVP). Then the HA undertakes the Duplicate Address
   Detection (DAD) procedure to verify the uniqueness of the selected
   Home Address.

   If DAD fails (i.e. an address duplication is detected on the home
   link), the HA selects another Home Address for the MN and repeats the
   whole DAD procedure. If this operation fails for three times in a
   row, the Home Agent sends to the AAAH a Diameter Home Address Answer
   (HAA) message with Result-Code equal to FAILURE. At this stage, AAAH
   can try to assign another HA or close the negotiation sending to the
   MN a Service-Status-TLV stating that the Mobile IPv6 service is not
   active and not available (see section 6.1).

   If DAD is completed successfully, the HA uses proxy Neighbor
   Discovery to defend the Home Address on the home link but does not
   begin to intercept data packets addressed to it until a valid Binding
   Update (BU) is received from the MN (see section 4). Then the HA
   replies to AAAH delivering a Diameter Home Address Answer (HAA)
   containing the following AVPs:

   - User-Name-AVP: as usual it includes the NAI of the MN;

   - Home-Address-AVP: specifies the Home Address that the Home Agent
     has allocated to the MN.


Giaretta Guardini Demaria       Expires - August 2004        [Page 10]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   Figure 4 depicts the exchange of HAR and HAA messages in the case the
   Home Address selection procedure carried out by the HA terminates
   without errors.

                   PEAPv2                           Diameter
                 TLS Tunnel            AAAH      HA Application
    MN +----------------------------+ Server +---------------------+ HA

                                       +-+
                                       |O|
                                       +-+
                                    Home Agent
                                    Selection

                                        ---------------------->
                                        Home-Address-Request(
                                        User-Name, [HA-Features],
                                        [Home-Address], [Interface-ID])

                                              <-----------------------
                                               Home-Address-Answer(
                                               User-Name, Home-Address)


       Figure 4 - Mobile IPv6 authorization: Home Address selection


   AAAH also acts as Key Distribution Center, delivering to MN and HA
   the cryptographic data needed to bootstrap the IPsec Security
   Association for protecting subsequent Mobile IPv6 signaling. For this
   reason, after the reception of the designated Home Address from the
   HA, AAAH continues the handshake sending to the HA a Diameter Home
   Agent Configuration Request (HACR) message containing the following
   AVPs:

   - User-Name-AVP: the NAI of the MN;

   - Authorization-Lifetime-AVP: it is the authorization lifetime (in
     seconds) of the Mobile IPv6 service granted to the MN;

   - IKE-Bootstrap-Information-AVP: this AVP specifies the peer
     authentication method to be used for IKE phase 1 (Pre-Shared key,
     certificates, etc.) and the related parameters (e.g. value of the
     pre-shared key and its lifetime). This is all the information the
     HA needs to negotiate the IPsec Security Association with the MN.
     This draft specifies in detail only the approach based on a Pre-
     shared Key (PSK);



Giaretta Guardini Demaria       Expires - August 2004        [Page 11]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   - Policy-AVP (optional): contains some filtering rules (e.g. access
     lists) to be enforced by the HA on the traffic the MN transmits
     and/or receives in bi-directional tunneling.

   Once the HA has stored these data in its Service Authorization Cache
   (see section 4.1), it sends to AAAH a Diameter Home Agent
   Configuration Answer (HACA) containing a Result-Code-AVP used to
   confirm the success (or failure) of the procedure (see Figure 5).

                   PEAPv2                          Diameter
                 TLS Tunnel           AAA       HA Application
    MN +---------------------------+ Server +----------------------+ HA

                                      +-+
                                      |O|
                                      +-+
                                IKE Configuration
                                    Selection

                                       ----------------------->
                                       HA-Configuration-Request(
                                       User-Name, Auth. Lifetime,
                                       IKE-Bootstrap-Info, [Policy])

                                              <-----------------------
                                               HA-Configuration-Answer(
                                               User-Name, Result-Code)

          Figure 5 - Mobile IPv6 authorization: HA configuration


   At this stage, the HA is ready to accept future MIPv6 registrations
   coming from the MN. Therefore, AAAH can restart the EAP session with
   the MN communicating to it all the MIPv6 configuration data it is
   waiting for. This is achieved delivering to the MN an EAP Request
   containing a MIPv6-Authorization-TLV including the following TLVs:
   Home-Address-TLV (i.e. the home address), Home-Agent-Address-TLV
   (i.e. the address of the HA), IKE-Bootstrap-Information-TLV (i.e. the
   information needed to bootstrap the IKE session with the HA).

   As soon as it receives this message, the MN stores all the
   configuration data and sends back an EAP Reply containing a
   Negotiation-Result-TLV, stating whether it accepts, or refuses, the
   proposed configuration (see Figure 6). If the MN refuses the
   configuration, AAAH should immediately release the resources
   previously allocated on the HA. To complete this task, AAAH sends a
   Diameter Abort Session Request (ASR) message to the Home Agent (see
   paragraph 3.3).



Giaretta Guardini Demaria       Expires - August 2004        [Page 12]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


                   PEAPv2                           Diameter
                 TLS Tunnel            AAAH      HA Application
    MN +----------------------------+ Server +---------------------+ HA

                   <---------------------
                    EAP-TLV(Result-TLV,
                    Crypto-Binding-TLV,
                    MIPv6-Authorization-TLV(
                    Home-Address, HA-Address,
                    IKE-Bootstrap-Info))

     ----------------------->
     EAP-TLV(Result-TLV,
     Crypto-Binding-TLV,
     MIPv6-Authorization-TLV(
     Negotiation-Result))

          Figure 6 - Mobile IPv6 authorization: MN configuration

   To terminate the EAP session, AAAH sends to the Access Point a
   Diameter EAP Answer message with Result-Code equal to SUCCESS and,
   optionally, other authorization AVPs containing some filtering rules
   to be enforced on MN's traffic (see Figure 7).

        EAP Over         EAP over                   Diameter
         802.1x          Diameter     AAA        HA Application
    MN +---------+ AP +------------+ Server +----------------------+ HA

                    <-------------------
                       Diameter-EAP-Answer(
                       Result-Code-AVP(Success),
                       EAP-Payload-AVP(EAP-Success),
                       [Authorization AVPs])
                  +-+
                  |O| Enforcement of
                  +-+ authorization rules

     <-------------
       EAP-Success

                 Figure 7 - Termination of the EAP session

   After the completion of the EAP session, MN holds all data needed to
   perform Mobile IPv6 registrations: the MN knows its Home Address, the
   address of the correspondent Home Agent and all cryptographic
   material needed to establish the IPsec security association with it;
   furthermore, since it has been successfully authenticated, the MN is
   receiving Router Advertisements on the visited subnet and can build
   its Care-of Address through IPv6 stateless autoconfiguration.


Giaretta Guardini Demaria       Expires - August 2004        [Page 13]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   The first operation carried out by the MN after the acquisition of
   the Care-of Address is the establishment of the IPsec Security
   Association with the HA, that is mandated by [1] to protect MIPv6
   location update signaling. Set-up of the IPsec SA can be accomplished
   following the procedure detailed in [7]. In this regard, it is
   important to note that:

   - if the mutual authentication in IKE Phase 1 is based on a Pre-
     Shared Key (PSK), Aggressive Mode must be used. This is because
     Aggressive Mode is the only way to use PSK authentication with a
     NAI as peer identifier [8]. Indeed, the NAI of the MN is the only
     identity information stored in the Service Authorization Cache of
     the HA;

   - in IKE phase 1 messages, the source address used by the MN has to
     be the Care-of Address, as described in [7]; the Home Address is
     used only in IKE phase 2;

   - in IKE phase 2 (Quick Mode), while still using the CoA as source
     address of IKE messages, the MN has to use the Home Address as its
     peer identifier, so that the HA can correctly set the MN entries
     in its Security Policy Database (SPD) and in the Security
     Association Database (SAD).

   As soon as the IPsec Security Association is established, MN can send
   a Binding Update to the HA, thus starting up Mobile IPv6 service
   (Figure 8).

                                       AAA
    MN +--------+ AP +--------------+ Server +---------------------+ HA

       /------------------------------------------------------------\
      /                           IKE Phase 1                        \
      \                      Aggressive Mode (2 RTT)                 /
       \------------------------------------------------------------/

       /------------------------------------------------------------\
      /                           IKE Phase 2                        \
      \                     Quick Mode (1 + 1/2 RTT)                 /
       \------------------------------------------------------------/

     -------------------------------------------------->
     MIPv6 Binding Update

                   <--------------------------------------------------
                                             MIPv6 Binding Acknowledge

             Figure 8 - IKE Negotiation and MIPv6 Registration


Giaretta Guardini Demaria       Expires - August 2004        [Page 14]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   Considering the usage of an inner EAP method involving 2 round trips
   (e.g. EAP-AKA), the bootstrap procedure described in the foregoing
   requires a total of 13.5 round trips (RTTs) to be completed: 9 RTTs
   for authentication and Mobile IPv6 negotiation, 3.5 RTTs for setting
   up the IPsec SA (i.e. IKE) and 1 RTT for MIPv6 registration (i.e. BU,
   BA). However, since the whole procedure may be performed only at the
   MN bootstrap (e.g. when the terminal is switched on), the time
   requirements are not critical.

   Nonetheless, a number of optimization steps can be introduced in
   order to make the whole procedure faster. The PEAPv2 protocol
   provides for several tasks to be performed simultaneously by
   conveying the correspondent message exchanges in different TLV types,
   all delivered through the TLS tunnel in place between MN and AAAH.
   Exploiting this feature, the negotiation procedure for the MIPv6
   service can be performed in partial or complete superposition with
   the authentication procedure. This optimization leads to saving 2
   round trips. Additionally, the time for the HA to complete the DAD
   procedure may be partially or totally absorbed within the
   authentication procedure.


3.2 Management of reauthentication events

   At the expiration of AAA session time-outs or after a change in the
   point of attachment to the network (involving or not involving an IP
   handoff), a re-authentication procedure is performed leading to the
   user identity to be checked again along with its right to continue
   exploitation of network resources. To that purpose the AAAH server
   may repeat a full authentication or, alternatively, decide to use
   optimizations in order to make the procedure faster. Once this phase
   is completed the AAA server also undertakes the re-negotiation of the
   Mobile IPv6 service, communicating with the MN through the TLS
   tunnels established in PEAPv2 phase 1. The actual protocol behavior
   and message exchange may vary depending on the service state of the
   mobile node.

   If the MIPv6 service is not currently active for the MN, AAAH behaves
   exactly as in the bootstrap phase (see section 3.1) and proposes the
   activation of the service from scratch as if the MN was performing
   its first authentication within the visited network.

   Instead, if the MIPv6 service is already active, AAAH informs the MN
   about the current MIPv6 service status, including the respective
   service options negotiated during the bootstrap phase. AAAH performs
   this operation delivering a MIPv6-Authorization-TLV including the
   Service-Status-TLV and the Service-Options-TLV. The mobile node may
   respond in two different ways:


Giaretta Guardini Demaria       Expires - August 2004        [Page 15]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   - by means of a Negotiation-Result-TLV with result code equal to
     SUCCESS, to indicate that the service configuration is wished to
     be maintained unchanged,

   - or by means of a MIPv6-Authorization-TLV with the desired
     modifications (including the eventual request to stop the MIPv6
     service), to undertake the full or partial re-negotiation of the
     MIPv6 service.

   As a whole, the described re-authentication procedure takes 10 round
   trips, assuming that the employed EAP method requires 2 round trips
   (e.g. EAP-AKA) and the Mobile Node has undertaken an IP handoff
   without asking for any change in the service configuration.
   Consequently, 3.5 round trips are saved in comparison with the
   bootstrap phase, in that the MN already shares an IPsec Security
   Association with the HA and therefore does not need to repeat the IKE
   negotiation.

   The delay involved in completing the re-authentication procedure may
   be reduced by resorting to the optimization steps already described
   in the foregoing with reference to the bootstrap phase and, possibly,
   by exploiting some additional optimizations supported by the PEAPv2
   protocol: fast resume of the TLS tunnel and fast reconnect.


3.3 Session Termination

   Session termination may be triggered by the AAA server or the mobile
   node. The result is normally the disconnection of the user from the
   visited network, and, consequently, the release of Mobile IPv6
   service and related resources (Home Agent, Home Address, etc.).

   The AAA server may decide to close the session at any moment, for
   instance due to credit exhaustion. In general, to interrupt the
   service, the AAA server delivers to the correspondent AAA client a
   Diameter Abort Session Request (ASR) message; the AAA client
   disconnects the user, releases the resources previously allocated to
   it and confirms the session termination through a Diameter Abort
   Session Answer (ASA) message. If a plurality of clients are involved
   in the service provision, the ASR message is sent to all of them. In
   the specific case of the Mobile IPv6 service, the two Diameter
   clients involved are the HA and the equipment that is providing
   access to the network (i.e. the Access Point in case of a Wireless
   LAN), therefore both receive an ASR message from AAAH (see Figure 9)
   and enforce immediate user disconnection.





Giaretta Guardini Demaria       Expires - August 2004        [Page 16]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


                                                    Diameter
                                      AAA        HA Application
    MN +--------+ AP +-------------+ Server +----------------------+ HA

                    <-------------------
                     Diameter-Abort-Session-Request(
                     User-Name-AVP)
                                         -------------------->
                                         Diameter-Abort-Session-Request(
                                         User-Name-AVP)
                   ------------------>
                   Diameter-Abort-Session-Answer(
                   Result-Code-AVP)
                                             <------------------------
                                          Diameter-Abort-Session-Answer(
                                          Result-Code-AVP)

          Figure 9 - MIPv6 service termination triggered by AAAH


   In the case the MN wishes to disconnect, it sends an EAPOL-Logoff
   message toward the Access Point which in turn communicates the end of
   the session to the AAA server via the Diameter Session Termination
   Request (STR) message, while simultaneously releasing the resources
   involved. At the reception of the STR message, the AAA server
   releases the resources allocated on the HA exchanging Abort Session
   Request and Answer messages with it, while sending a corresponding
   Diameter Session Termination Answer message toward the AP.

   The AAA server may possibly decide to adopt different policies for
   releasing the resources (e.g. depending the user service profile).
   For instance, the AAA server may decide not to release the resources
   on the HA in order to allow the MN to exploit the Mobile IPv6 service
   even when it moves to network for which no roaming agreements exist
   (e.g. a corporate network or a network providing free and cost-free
   access). In that case, the MN can continue to use the IPsec SA
   previously negotiated with the HA and respective authorization is
   managed by means of the MIPv6 Authorization Lifetime (see Diameter
   HACR message). Once this lifetime expires (but it may even be
   infinite), the HA should send a Diameter Authorization Refresh
   Request message to the AAAH server asking for a confirmation of the
   authorization (see Figure 10).









Giaretta Guardini Demaria       Expires - August 2004        [Page 17]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


                                                    Diameter
                                      AAA        HA Application
    MN +--------+ AP +-------------+ Server +----------------------+ HA

                                                                    +-+
                                                                    |O|
                                                                    +-+
                                                           Authorization
                                                     Lifetime Expiration

                                                  <-------------------
                                                 Diameter-Authorization-
                                                 Refresh-Request(User-
                                                 Name-AVP)

                                          -------------------->
                                          Diameter-Authorization-
                                          Refresh-Answer(User-Name-AVP,
                                          Result-Code-AVP,
                                          [Authorization-Lifetime-AVP])

         Figure 10 - Diameter Authorization Refresh Request/Answer


   In some circumstances, it might be desirable for the mobile node to
   terminate the MIPv6 service only (and stop being charged for that),
   while maintaining uninterrupted access to the visited network.
   Relaying on the architecture described in the previous sections, this
   result can be achieved in two different ways:

   - the MN can wait till the next re-authentication event (usually
     triggered by the network) and perform the re-negotiation of the
     whole MIPv6 protocol operation (see section 3.2),

   - or the MN can decide to stop sending Binding Updates to the HA,
     causing the expiration of the correspondent entry in the Binding
     Cache. This is interpreted by the HA as the MN's willingness to
     stop using the Mobile IPv6 protocol. Therefore, the HA, behaving
     similarly to a standard Network Access Server (NAS), sends a
     Diameter Session Termination Request to the AAA server and, after
     the reception of the correspondent Session Termination Answer,
     releases all the resources previously allocated to the MN (i.e.
     the Home Address and the entry in its Service Authorization
     Cache).







Giaretta Guardini Demaria       Expires - August 2004        [Page 18]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


4. Home Agent considerations

   This section details some specific features and data structures that
   have to be supported by the Home Agent to allow dynamic negotiation
   of Mobile IPv6 protocol parameters during mobile node network
   attachment.


4.1 Service Authorization Cache (SAC)

   The Home Agent is required to store some authorization data for each
   of the MNs it is serving. A new data structure, called Service
   Authorization Cache (SAC), is used for this purpose. Each entry in
   the SAC should contain at least the following fields:

   - NAI of the user: it is derived from the User-Name-AVP included by
     AAAH in all the Diameter messages addressed to the HA;

   - Home Address: it is the Home Address (checked against DAD) that
     the HA has dynamically assigned to the MN during the Mobile IPv6
     bootstrap phase;

   - Authorization Lifetime: it is the authorization lifetime of the
     Mobile IPv6 service granted to the MN. AAAH selects this lifetime
     according to administrative rules and specifies it in the
     Authorization-Lifetime-AVP. Before the expiration of this
     lifetime, the HA may send a Diameter Authorization Refresh Request
     (ARR) message to AAAH asking for an extension (i.e. renewal) of
     the authorization;

   - Authentication Mode: it is the authentication mode to be used in
     IKE Phase 1 for setting up the IPsec SA with the MN. This draft
     specifies in detail only the approach based on a Pre-shared Key
     (PSK);

   - Cryptographic Data: this field includes all the information to be
     used for IKE bootstrap. The actual content of this record depends
     on the Authentication Mode chosen for IKE Phase 1: if Pre-shared
     Key is used for this purpose, this field includes the PSK value
     and its lifetime.


4.2 Management of Binding Cache entries

   The selection of the Home Address to be assigned to the MN at the end
   of the MIPv6 bootstrap phase is performed by the designated Home
   Agent at the reception of the Diameter Home Address Request (HAR)
   message from the AAAH server. Immediately after the completion of
   this procedure, the HA is required to start defending the Home


Giaretta Guardini Demaria       Expires - August 2004        [Page 19]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   Address (i.e. proxy Neighbor Discovery), even if it has not yet
   received any Binding Update from the MN. This behavior is not
   completely conformant with the Mobile IPv6 specification and has to
   be treated carefully to avoid protocol failures on the HA. In
   particular, the following anomaly might happen:

   - at the end of the MIPv6 authorization and negotiation process
     (i.e. the MN has completed the EAP communication and has been
     explicitly authorized to use MIPv6 from its current point of
     attachment), the MN sends a Binding Update (BU) message to
     register its Care-of Address on the HA;

   - the Home Agent receives the BU from the MN and, following the
     MIPv6 protocol standard, checks the Home Address included in it
     against DAD. Since the HA is already defending that Home Address,
     DAD might happen to fail, blocking Mobile IPv6 functionality on
     the MN.

   To avoid this problem, when the HA starts defending the Home Address
   allocated to the MN (i.e. immediately before replying to AAAH with
   the Diameter Home Address Answer message), it should also register it
   in its binding cache, creating a new entry where the Care-of Address,
   that is still unknown, is initially set to unspecified (::) and the
   correspondent lifetime is set to the MIPv6 authorization lifetime. In
   this way, when the HA receives the first Binding Update from the MN,
   the message is treated as an update of an existing entry in the
   Binding Cache and therefore DAD is not performed.

   In order for this procedure to work properly, the MN has to send a BU
   to the HA as soon as it is granted IPv6 access to the visited subnet
   (i.e. at the end of EAP authentication). If the visited subnet
   happens to be on the home link, the MN should send to the HA a BU
   with binding lifetime equal to 0, to make sure it cleans up the dummy
   entry in its binding cache and stops defending the home address.


5. Protocol Applicability in Cellular Networks

   Using the Mobile IPv6 protocol and the services offered thereby may
   be desirable particularly to handle mobile node movements across a
   multi-access environment, involving both WLANs and 3GPP radio
   networks (i.e. vertical handoff). This scenario, in fact, is becoming
   increasingly popular, due to the massive deployment of WLAN hot-spots
   in public indoor areas like airports and hotels.

   In cellular networks (e.g. GPRS, UMTS), access control and IP address
   assignment are managed relaying on protocols that are specific of
   cellular infrastructures (for instance, SS7/MAP), and therefore do
   not natively support the use of EAP. For this reason, in such


Giaretta Guardini Demaria       Expires - August 2004        [Page 20]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   environments the Mobile IPv6 authorization and configuration
   procedure described in the previous sections can not be employed as
   is, but must be properly adapted.

   The proposed solution is based on the assumption that the MN performs
   Mobile IPv6 service negotiation interacting with a AAA server
   supporting Diameter, which remains logically unchanged regardless of
   the access technology being used (i.e. WLAN or cellular).
   Additionally, this AAA server must support a communication interface
   towards the authentication center of the cellular operator (i.e.
   HLR/AuC), but the details about this interaction are outside the
   scope of this document.

   When the MN enters a GPRS or UMTS data network, based on layer 2
   signaling procedures specific of cellular environments, it is
   assigned an IP address (v4 or v6) by activating a so called PDP
   Context. This corresponds to establishing a direct layer 3
   communication channel between the MN and the GGSN (GPRS Gateway
   Support Node), that is basically the first router on the path towards
   any external IP cloud (e.g. the Internet).

   At this stage, to perform MIPv6 negotiation as described in the
   previous sections, it is necessary to establish an additional
   communication channel based on EAP over the existing IP transport
   (i.e. over the PDP Context). This can be achieved activating a PANA
   [9] session between the MN and the GGSN, used for the sole purpose of
   authorizing and configuring (or re-negotiating, if it was already
   active) the Mobile IPv6 service.

   This procedure consists of the exchange of MIPv6 TLVs transported
   directly over EAP (i.e. exchange of EAP messages with EAP-Type equal
   to EAP-TLV). In this case, there is no need to protect this signaling
   establishing a TLS tunnel through PEAP, because there is already a
   secure channel in place between MN and GGSN, provided by the PDP
   Context. Moreover, it is not necessary to carry out any further
   authentication procedures, because the user has already been
   authenticated via HLR/AuC and SS7/MAP.

   The whole procedure includes the following steps (Figure 11):

   - GGSN and MN establish a PANA session (PANA-Start-Request/Answer).
     The communication is triggered by the GGSN message as soon as the
     PDP Context activation is complete;

   - GGSN sends to the AAA server a Diameter EAP Request message
     containing the user identifier (NAI) and an empty EAP packet,
     indicating the need of starting an EAP exchange. The NAI is
     constructed directly by the GGSN, that is a trusted node, using
     the MN credentials collected during the PDP Context activation.


Giaretta Guardini Demaria       Expires - August 2004        [Page 21]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


     Since these credentials (i.e. essentially the data contained in
     the SIM/USIM) have already been verified using protocols specific
     of cellular networks (e.g. SS7/MAP), there is no need to undertake
     a new authentication phase;

   - at the reception of the Diameter EAP Request message from the
     GGSN, the AAA server understands that the MN is already
     authenticated (e.g. interacting with the HLR/AuC) and starts
     directly the Mobile IPv6 negotiation phase, sending EAP messages
     containing solely the MIPv6-Authorization-TLV. The negotiation
     goes on as already described in section 3.1 for WLAN access.

   - if the negotiation terminates successfully, the AAA server sends
     to the GGSN an EAP Success message conveyed within a Diameter EAP
     Answer; the GGSN forwards this notification to the MN through a
     PANA-Bind-Request message. Finally, MN closes the exchange
     replying with a PANA-Bind-Answer.


   At any time, the MN may request the termination of the PANA session,
   and consequently the release of the MIPv6 service, by means of a
   PANA-Termination-Request message sent to the GGSN node. Conversely,
   the AAA server may discontinue the delivery of the service sending a
   Diameter Abort Session Request message to the Home Agent.

   The main advantage of this procedure lies in the possibility of re-
   using those messages and TLVs defined in section 3.1 even when the MN
   accesses a cellular network, or, in general, any IP network (wireless
   or wired) performing user authentication with methods other than EAP.
   Instead, the drawback is that the GGSN, or, in general, the first
   router on the outbound routing path, has to support a new feature
   (i.e. the PANA protocol) and the MIPv6 service negotiation is not
   carried out together with the user authentication, but as an
   additional procedure following the MN network attachment.

















Giaretta Guardini Demaria       Expires - August 2004        [Page 22]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   MN +-------------------------+ GGSN +--------------------------+ AAA

       /-----PDP Context Act. ------\
       \----------------------------/

                   <-----------------
                    PANA-Start-Request
     ------------------>
     PANA-Start-Answer                ----------------------->
                                      Diameter-EAP-Request(
                                      EAP-Payload-AVP(empty),
                                      User-Name-AVP)
                                    <---------------------------------
                        Diameter-EAP-Answer(EAP-Payload-AVP(EAP-
                        Request/EAP-Type=EAP-TLV(MIPv6-Authorization-TLV
                        (Service-Status,[Service-Options]))))
              <----------------------
           PANA-Auth-Request(EAP-Request)
     -------------------------->
     PANA-Auth-Answer(EAP-Response/EAP-Type=EAP-TLV
     (MIPv6-Authorization-TLV(Service-Selection,
     [Service-Options])))
                                   ------------------->
                                   Diameter-EAP-Request             +-+
                                                         HA select. |O|
                                                        and config. +-+

                                    <---------------------------------
                                    Diameter-EAP-Answer(EAP-Payload-AVP(
                                    EAP-Request/EAP-Type=EAP-TLV(MIPv6
                                    Authorization-TLV(Home-Address
                                    HA-Address,IKE-Bootstrap-Info))))
                   <-----------------
                    PANA-Auth-Request(
                    EAP-Request)
     ------------------>
     PANA-Auth-Answer(EAP-Response/EAP-Type=
     EAP-TLV(MIPv6-Authorization-TLV
     (Negotiation-Result)))         ------------------->
                                    Diameter-EAP-Request
                                           <--------------------------
                                            Diameter-EAP-Answer(
                                           EAP-Payload-AVP(EAP-Success))
               <---------------------
               PANA-Bind-Request(EAP-Success)
     ------------------>
     PANA-Bind-Answer

         Figure 11 - MIPv6 service authorization in 3GPP networks


Giaretta Guardini Demaria       Expires - August 2004        [Page 23]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



6. New Messages and Attributes

6.1 New EAP-TLVs

   The general format of an EAP-TLV is depicted in Figure 12 [10].

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|R|             Type          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 12 - Generic TLV format

   TLVs defined in this draft are:

   - MIPv6-Authorization-TLV. This is a generic TLV which carries all
     TLVs related to MIPv6 authorization and configuration. It is
     defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|R|             Type          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      M

         0 - Non-mandatory TLV

      R

         Reserved, set to zero (0)

      Type

         TBD - MIPv6-Authorization

      Length

         The length of the Value field in octets

      Value

         This field carries the subsequent TLVs



Giaretta Guardini Demaria       Expires - August 2004        [Page 24]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



   - Service-Status-TLV. This TLV is sent by the AAAH to inform the MN
     about the status of Mobile IPv6 service. It is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type=Service-Status      |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |
      +-+-+-+-+-+-+-+-+

      Type

         TBD - Service-Status

      Length

         1

      Code

         0 = MIPv6 service is not active and not available
         1 = MIPv6 service is not active but available
         2 = MIPv6 service is active but no more available
         3 = MIPv6 service is active and available


   - Service-Selection-TLV. This TLV is sent by the MN to inform the
     AAAH whether it accepts the AAAH proposal.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type=Service-Selection     |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |
      +-+-+-+-+-+-+-+-+

      Type

         TBD - Service-Selection

      Length

         1

      Code

         0 = MN accepts configuration options proposed by AAAH
         1 = activate MIPv6 service


Giaretta Guardini Demaria       Expires - August 2004        [Page 25]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


         2 = re-negotiate MIPv6 service
         3 = deactivate MIPv6 service


   - Service-Options-TLV. So far only two service options are defined:
     the multiple registration option and the HA in visited network
     option. This TLV is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type=Service-Options     |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |H|M|       Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD - Service-Options

      Length

         2

      H

         1 - The MN is requesting a HA in the visited network

      M

         1 - The MN is requesting multiple registration functionalities

      Reserved

         14 bit reserved set to 0


   - Home-Agent-Address-TLV. It is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type=HA-Address          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Home Agent Address                       |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Giaretta Guardini Demaria       Expires - August 2004        [Page 26]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


      Type

         TBD - Home-Agent-Address

      Length

         16

      Value

         Home Agent Address


   - Home-Address-TLV. It is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type=Home-Address        |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                        Home Address                           |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD - Home-Address

      Length

         16

      Value

         Home Address


   - IKE-Bootstrap-Information-TLV. This TLV carries data related to
     IKE bootstrap; the generic format is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=IKE-Bootstrap-Info     |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Auth. Type               |     IKE Phase 1 Mode          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Authentication Information...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Giaretta Guardini Demaria       Expires - August 2004        [Page 27]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



      Type

         TBD - IKE-Bootstrap-Information

      Length

         Depending on Authentication Type

      Value

         Authentication Type

                     The authentication method to be used in IKE Phase 1

         IKE Phase 1 Mode

                     The mode to be used in IKE Phase 1

         Authentication Information

                    This field contains cryptographic material to setup
                     the security association.

   The figure below depicts the IKE-Bootstrap-Information-TLV when PSK
   is used as Authentication Type.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=IKE-Bootstrap-Info     |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             PSK               |     Aggressive Mode           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Key Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Key Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD - IKE-Bootstrap-Information

      Length

         8 + Key length






Giaretta Guardini Demaria       Expires - August 2004        [Page 28]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


      Value

         Authentication Type

                     PSK

         IKE Phase 1 Mode

                     Aggressive Mode

         Authentication Information

                     Key Lifetime - the lifetime of the PSK

                     Key Value - the value of the PSK


   - Negotiation-Result-TLV. It is defined as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Type=Result            |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Result-Code   |
      +-+-+-+-+-+-+-+-+

      Type

         TBD - Result

      Length

         1

      Value

           0 - Success
         128 - Failure


6.2 New Diameter messages and AVPs

   In this draft a new Diameter Application, called Home Agent Diameter
   Application, is proposed. The complete and detailed definition of the
   application is outside the scope of this document; even so, this
   section lists all new Diameter messages and AVPs introduced.





Giaretta Guardini Demaria       Expires - August 2004        [Page 29]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   The Diameter messages defined are:

   - Home Address Request. This message is sent by AAAH to the HA to
     request a Home Address; it includes these AVPs:
        o User-Name-AVP
        o Home-Address-AVP (optional)
        o Interface-Identifier-AVP (optional)
        o HA-Features-AVP (optional)

   - Home Address Answer. Through this message the Home Agent sends to
     AAAH the parameters it has reserved for a particular MN; it
     includes these AVPs:
        o User-Name-AVP
        o Home-Address-AVP

   - Home Agent Configuration Request. AAAH sends this message to the
     HA to give some information related to MIPv6 service activation;
     it includes these AVPs:
        o User-Name-AVP
        o Authorization-Lifetime-AVP
        o IKE-Bootstrap-Information-AVP
        o Policy-AVP (optional)

   - Home Agent Configuration Answer. Through this message the HA gives
     to AAAH the result of MIPv6 configuration procedure; it includes
     these AVPs:
        o User-Name-AVP
        o Result-Code-AVP

   - Authorization Refresh Request. The HA sends this message to AAAH
     when the Authorization Lifetime is going to elapse, requesting
     whether the user is still authorized to use MIPv6. It includes
     these AVPs:
        o User-Name-AVP

   - Authorization Refresh Answer. Through this message, AAAH specifies
     whether the MN is still authorized to use MIPv6. If the user is no
     longer authorized, the lifetime in Authorization-Lifetime-AVP is
     set to 0. It includes these AVPs:
        o User-Name-AVP
        o Result-Code-AVP
        o Authorization-Lifetime-AVP (optional)

   - Foreign Home Agent Request. AAAH sends this message to AAAF to
     request a Home Agent allocation.
        o User-Name-AVP
        o Home-Agent-Address-AVP (optional)
        o HA-Features-AVP (optional)
        o Home-Address-AVP (optional)


Giaretta Guardini Demaria       Expires - August 2004        [Page 30]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


        o Interface-Identifier-AVP (optional)
        o Authorization-Lifetime-AVP (optional)
        o Policy-AVP (optional)

   - Foreign Home Agent Answer. AAAF sends this message to AAAH to give
     it the parameters related to MIPv6 activation.
        o User-Name-AVP
        o Home-Agent-Address-AVP
        o Home-Address-AVP
        o Authorization-Lifetime-AVP
        o IKE-Bootstrap-Information-AVP

   Diameter AVPs defined in this document are:

   - Home-Address-AVP. This AVP is of type IPAddress and the Data field
     contains a Home Address.

   - Home-Agent-Address-AVP. This AVP is of type IPAddress and the Data
     field contains the address of a Home Agent.

   - Interface-Identifier-AVP. This AVP is of type OctetString and the
     Data field contains an Interface Identifier that the MN can
     provide as a hint for Home Address selection on the HA.

   - IKE-Bootstrap-Information-AVP. This AVP is of type OctetString and
     contains data related to IKE bootstrap. The Data field has the
     same structure of the Value field defined for the IKE-Bootstrap-
     Information-TLV.

   - HA-Features-AVP. This AVP (type to be defined) carries information
     about specific features requested on the designated Home Agent
     (e.g. support for registration of multiple CoAs).

   - Policy-AVP. This AVP is of type IPFilterRule and defines a set of
     access lists to be enforced by the HA on the traffic generated by
     the mobile node.


7. Open Issues

   Possible areas for future work are:

   - the usage of the AAA infrastructure, in place of IKE, to bootstrap
     the IPsec SA between the MN and the HA. This could be useful to
     reduce the number of round trips required for the completion of
     the MIPv6 negotiation procedure;

   - the exploitation of the EAP Key Management Framework [11] to allow
     the mobile node to derive the Pre-Shared Key used for IKE phase 1.


Giaretta Guardini Demaria       Expires - August 2004        [Page 31]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


     This might improve the security of the architecture, in that it
     would not be necessary any more for the AAA server to send the PSK
     over the air (even if within a protected TLS tunnel);

   - the extension of the architecture to support the usage of digital
     certificates, in addition to PSK, for peer authentication in IKE
     phase 1;

   - a deeper analysis of the issues related to the interface between
     AAA server and HLR/AuC for the execution of the MIPv6 negotiation
     procedure in cellular networks.


8. Security Considerations

   The Mobile IPv6 authorization and configuration exchange between the
   mobile node and the AAA server of the home domain is protected by a
   TLS tunnel established using PEAPv2. Therefore the level of security
   of this communication is the same of PEAPv2 message exchanges.

   The interaction between the AAA server and the designated Home Agent
   is based on Diameter, which means that it is protected using IPsec or
   TLS, as specified by the Diameter base protocol.


Acknowledgments

   The authors would like to thank Simone Ruffino (of Telecom Italia
   Lab) for his feedback and suggestions.


References

   [1]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
         2003.

   [2]   Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2",
         draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
         October 2003.

   [3]   Blunk, L. et al., "Extensible Authentication Protocol (EAP)",
         draft-ietf-eap-rfc2284bis-07 (work in progress), November 2003.






Giaretta Guardini Demaria       Expires - August 2004        [Page 32]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   [4]   Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication
         Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03 (work in
         progress), August 2003.

   [5]   Narten, T., Draves, R., "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [6]   Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile
         IPv6 Application", draft-le-aaa-diameter- mobileipv6-03
         (expired), April 2003.

   [7]   Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect
         Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
         draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June
         2003.

   [8]   Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
         2409, November 1998.

   [9]   Forsberg, D. et al., "Protocol for Carrying Authentication for
         Network Access (PANA)", draft-ietf-pana-pana-02 (work in
         progress), October 2003.

   [10]  Hiller, T., Palekar, A., Zorn, G., "A Container Type for the
         Extensible Authentication Protocol (EAP)", draft-hiller-eap-
         tlv-01, May 2003.

   [11]  Aboba, B., Simon, D., Arkko, J., Levkowetz, H., " EAP Key
         Management Framework", draft-ietf-eap-keying-01.txt, October
         2003.
















Giaretta Guardini Demaria       Expires - August 2004        [Page 33]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



Appendix A - Home Agent allocation in a foreign domain

   Whenever the mobile node is switched on inside a foreign domain (i.e.
   roaming scenario), it may be worthwhile assigning it a local Home
   Agent provided by the visited provider, rather than allocating a
   distant HA in the home domain. This may be useful to optimize network
   usage and reduce transfer delay for data traffic in bi-directional
   tunneling.

   The decision on the preferred position of the HA is taken by the AAAH
   server, either autonomously (e.g. based on the user profile or on
   other administrative policies) or negotiating with the MN through the
   Service-Options-TLV. In the latter case, the negotiation procedure is
   undertaken as follows:

   - in the first MIPv6-Authorization-TLV sent over the TLS tunnel
     established with PEAPv2, the AAAH server includes, together with
     the Service-Status-TLV, a Service-Options-TLV with the bit H set
     to 1, meaning that the allocation of a HA within the foreign
     domain is actually supported by the home provider;

   - if the MN wants to exploit this feature, it responds sending a
     MIPv6-Authorization-TLV including, in addition to the mandatory
     Service-Selection-TLV, a Service-Options-TLV with the bit H set to
     1, as a confirmation of its preference for the assignment of a
     local HA within the foreign domain.

   The rest of the procedure for bootstrapping MIPv6 protocol operation
   on the MN is carried out essentially as already described for the
   allocation of a HA inside the home domain (see section 3.1). The only
   major difference is that the AAAH server cannot perform HA selection
   and configuration by its own but has to interact with the AAA server
   of the foreign domain (i.e. AAAF).

   As a whole, the procedure undertaken by the AAAH server to obtain and
   configure a HA inside the foreign domain is based on the following
   steps (see Figure 13):

   - AAAH sends a Diameter Foreign Home Agent Request (FHAR) message to
     AAAF, indicating the user's NAI in the User-Name-AVP. Optionally,
     AAAH may insert other AVPs including the configuration hints
     eventually provided by the MN (HA-Address-AVP, Home-Address-AVP
     and Interface-Identifier-AVP), the additional features required on
     the HA (HA-Features-AVP), the desired authorization lifetime to be
     set on the designated HA (Authorization-Lifetime-AVP) and the
     filtering rules to be enforced on the traffic generated by the
     mobile node (Policy-AVP);



Giaretta Guardini Demaria       Expires - August 2004        [Page 34]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


   - based on the information included in the request message, AAAF
     determines whether it can assign a HA within the local domain. In
     case the allocation is not possible (e.g. for administrative
     policies), or none of the available HAs actually supports the
     requested features (e.g. possibility to register multiple CoAs),
     AAAF replies with a Diameter Foreign Home Agent Answer (FHAA)
     message including a Result-Code-AVP set to FAILURE. In that case
     AAAH continues MIPv6 negotiation allocating a HA within the home
     domain. Instead, if AAAF can satisfy the request, it immediately
     determines a suitable Home Agent to be allocated to the MN using a
     Home Agent Selection Algorithm;

   - at this stage AAAF communicates with the selected HA using the
     same approach already described in section 3.1, based on the usage
     of Diameter Home Agent Request/Answer and Home Agent Configuration
     Request/Answer messages;

   - once the designated HA is properly configured (i.e. at the
     reception of the HACA message), AAAF delivers to AAAH a Diameter
     Foreign Home Agent Answer message including, in correspondent
     AVPs, all the information needed to activate the MIPv6 protocol
     operation on the MN (i.e. HA address, Home Address, Authorization
     Lifetime and IKE bootstrap information).




























Giaretta Guardini Demaria       Expires - August 2004        [Page 35]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004


                 Diameter                         Diameter
    AAAH      HA Application         AAAF      HA Application
   Server +-----------------------+ Server +----------------------+ HA

     ------------------>
    Foreign-Home-Agent-Request(User-Name,
    [Home-Agent-Address],[Home-Address],
    [Interface-ID],[HA-Features],
    [Auth. Lifetime],[Policy])
                                      +-+
                                      |O|
                                      +-+
                                   Home Agent
                                   Selection

                                        ---------------------->
                                        Home-Address-Request(
                                        User-Name, [HA-Features],
                                        [Home-Address], [Interface-ID])

                                              <-----------------------
                                               Home-Address-Answer(
                                               User-Name, Home-Address,
                                               [IKE-Bootstrap-Info])
                                      +-+
                                      |O|
                                      +-+
                                IKE Configuration
                                    Selection

                                       ----------------------->
                                       HA-Configuration-Request(
                                       User-Name, Auth. Lifetime,
                                       IKE-Bootstrap-Info, [Policy])

                                              <-----------------------
                                               HA-Configuration-Answer(
                                               User-Name, Result-Code)

                    <------------------
                   Foreign-Home-Agent-Answer(User-Name,
                   Home-Agent-Address,Home-Address,
                   Auth. Lifetime,IKE-Bootstrap-Info,
                   [Policy])

       Figure 13 - Allocation of a Home Agent in the foreign domain





Giaretta Guardini Demaria       Expires - August 2004        [Page 36]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



Authors' Addresses

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

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

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


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Giaretta Guardini Demaria       Expires - August 2004        [Page 37]


Internet-Draft     MIPv6 Authorization based on EAP       January 2004



Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

















Giaretta Guardini Demaria       Expires - August 2004        [Page 38]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/