Internet DRAFT - draft-hiko-pana-fpana

draft-hiko-pana-fpana






IETF pana WG                                                  Y. Kainuma
Internet-Draft                                           KEIO University
Expires: December 3, 2005                                         N. Ono
                                                              H. Hayashi
                                                 BB Mobile/Japan Telecom
                                                              F. Teraoka
                                                         KEIO University
                                                               June 2005


  FPANA: combining PANA and FMIPv6 for fast authentication at handover
                        draft-hiko-pana-fpana-00

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 December 3, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document proposes a fast authentication protocol called FPANA.
   A combination of PANA (for node authentication) and FMIP (for fast
   handover), it offers fast node authentication upon intra-domain
   handover of a mobile node.  Since FPANA makes use of context transfer



Kainuma, et al.         Expires December 3, 2005                [Page 1]

Internet-Draft          fast PANA authentication               June 2005


   of the PANA session from the previous access router to the new access
   router by the HI message of FMIPv6, the PANA session can be set
   between the mobile node and the new access router prior to the mobile
   node moving to the new access router.  Thus, the mobile node can
   continue authenticated communication upon intra-domain fast handover.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  PANA Overview  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   PANA Session . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2   Message Sequence . . . . . . . . . . . . . . . . . . . . .  7
     3.3   Problem Statement  . . . . . . . . . . . . . . . . . . . .  8

   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1   Design Principles  . . . . . . . . . . . . . . . . . . . .  9
     4.2   Conditions . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   Protocol Operation of Predictive Mode  . . . . . . . . . . 11
     4.4   Protocol Operation of Reactive Mode  . . . . . . . . . . . 12
     4.5   Getting PANA Session Attributes  . . . . . . . . . . . . . 13
     4.6   PANA Session Termination . . . . . . . . . . . . . . . . . 15

   5.  Definitions of Messages  . . . . . . . . . . . . . . . . . . . 16
     5.1   FPANA Option Header  . . . . . . . . . . . . . . . . . . . 16
     5.2   Message Format . . . . . . . . . . . . . . . . . . . . . . 17
     5.3   FPANA Messages . . . . . . . . . . . . . . . . . . . . . . 20

   6.  Node Operation . . . . . . . . . . . . . . . . . . . . . . . . 23
     6.1   All Node Operation . . . . . . . . . . . . . . . . . . . . 23
     6.2   Mobile Node Operation  . . . . . . . . . . . . . . . . . . 23
     6.3   Previous Access Router Operation . . . . . . . . . . . . . 24
     6.4   New Access Router Operation  . . . . . . . . . . . . . . . 24

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     7.1   MN-PAR security  . . . . . . . . . . . . . . . . . . . . . 26
     7.2   AR-AR security . . . . . . . . . . . . . . . . . . . . . . 26
     7.3   Validity of transferring PANA session attributes . . . . . 26

   8.  Intellectual Property Right  . . . . . . . . . . . . . . . . . 28

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28

       Intellectual Property and Copyright Statements . . . . . . . . 30



Kainuma, et al.         Expires December 3, 2005                [Page 2]

Internet-Draft          fast PANA authentication               June 2005


1.  Introduction

   In the Internet, every mobile node should be authenticated prior to
   network access.  If a mobile node moves to other subnet, it must be
   authenticated again.  PANA (Protocol for carrying Authentication for
   Network Access) [1] is a protocol for authenticating clients that are
   trying to access the network.  PANA needs the exchange of many
   messages between PaC (PANA client) and PAA (PANA Authentication
   Agent) for authentication.  Since, PAA must execute full EAP
   authentication by requiring PaC's AAA server to verify PaC's
   authentication information, authentication via PANA takes a long
   time.  Given that mobile nodes move frequently, smooth handover will
   be difficult because of delay imposed by PANA authentication.

   FPANA, the protocol proposed in this document, enables PANA
   authentication upon intra-domain handover to be greatly accelerated.
   To realize FPANA,  a mobile node (including PaC) predicts the new
   access router (including PAA) by using FMIPv6 (Fast Handovers for
   MIPv6) [2].  The previous access router (including PAA) transfers the
   PANA session attributes to the new access router.  Thus, the mobile
   node can keep the PANA session a live through the handover.






























Kainuma, et al.         Expires December 3, 2005                [Page 3]

Internet-Draft          fast PANA authentication               June 2005


2.  Terminology

   Most of the terms are defined in the PANA [1] and FMIPv6 [2]
   specifications:

   MN:

      Mobile Node.  A Mobile IPv6 host.

   AR:

      Access Router.  The MN's default router.

   NAR:

      New Access Router.  The router to which the MN is attached after
      the handover.

   PAR:

      Previous Access Router.  The router to which the MN was attached
      before the handover.

   AAA:

      Authentication, Authorization and Accounting.

   AAAv:

      AAA server in the MN's visited domain.

   AAAh:

      AAA server in the MN's home domain.

   AAAc:

      AAA client.  An AAAc requests the authentication and authorization
      of the MN to the backend AAA server.  We assume that AAAc is
      collocated in AR.

   PANA Context:

      PANA session attributes shared between PAA and PaC.







Kainuma, et al.         Expires December 3, 2005                [Page 4]

Internet-Draft          fast PANA authentication               June 2005


   PANA CT:

      The operation of transferring PANA context from PAR to NAR.

   FPANA-FBU:

      The message used in FPANA.  The extension message of the FBU
      message used in FMIPv6.  Message detail is described in
      Section 5.3.

   FPANA-HI:

      The message used in FPANA.  The extension message of the HI
      message used in FMIPv6.  Message detail is described in
      Section 5.3.

   FPANA-HAck:

      The message used in FPANA.  The extension message of the HAck
      message used in FMIPv6.  Message detail is described in
      Section 5.3.

   FPANA-FBack:

      The message used in FPANA.  The extension message of the FBack
      message used in FMIPv6.  Message detail is described in
      Section 5.3.

   FPANA-FNA:

      The message used in FPANA.  The extension message of the FNA
      message used in FMIPv6.  Message detail is described in
      Section 5.3.

   FPANA-NAack:

      The message used in FPANA.  The extension message of the NAack
      message used in FMIPv6.  Message detail is described in
      Section 5.3.












Kainuma, et al.         Expires December 3, 2005                [Page 5]

Internet-Draft          fast PANA authentication               June 2005


3.  PANA Overview

   PANA (Protocol for Carrying Authentication for Network Access) [1] is
   an authentication protocol for network access.  This section
   describes how PANA authenticates nodes and what problems are caused
   by PANA authentication.  It is assumed that some AAA protocol is
   executed in the back-end.

3.1  PANA Session

   To start PANA authentication, a PANA session must be established
   between a PaC and a PAA.  The PaC and the PAA share authentication
   information through the PANA session.  The PANA session has a
   lifetime, if this lifetime expires, re-authentication must be
   executed to continue communication.  In the PANA session, the PaC and
   the PAA exchange the following information to complete
   authentication.

   -Session-Id

   -Device-Id of PaC

   -IP address and UDP port number of PaC

   -IP address of PAA

   -List of device identifiers of EPs

   -Sequence number of the last transmitted request

   -Sequence number of the last received request

   -Last transmitted message payload

   -Retransmission Interval

   -Session Lifetime

   -Protection-Capability

   -PANA SA attributes

      +Nonce generated by PaC

      +Nonce generated by PAA






Kainuma, et al.         Expires December 3, 2005                [Page 6]

Internet-Draft          fast PANA authentication               June 2005


      +AAA-Key

      +AAA-Key identifier

      +PANA_MAC_KEY

   A PANA session consists of distinct phases.  The PaC initiates a PANA
   session in the "discovery and handshake phase".  The PaC and the PAA
   execute EAP authentication in the "authentication and authorization
   phase".  After the PaC succeeds in authentication and gains access to
   the network, the PaC and the PAA maintain the PANA session in the
   "access phase".  The PaC and the PAA exchange attributes in the
   "discovery and handshake phase" and the "authentication and
   authorization phase".  The PaC and the PAA share all attributes shown
   above, and the PANA session then enters the "access phase".

3.2  Message Sequence

   The PANA messages are sent to create and maintain the PANA session.
   The PANA messages contain some information in the form of AVP.  The
   PANA session attributes shown above are also exchanged in the form of
   AVP.  Figure 1 depicts the message flow of authentication in PANA.

          PaC   PAA   PaC's AAAh    | Message
        ----------------------------+---------------------------
        // Discovery and            |
              handshake phase       |
           ------>                  | PANA-PAA-Discover
                                    |
           <------                  | PANA-Start-Request
           ------>                  | PANA-Start-Answer
                                    |
        // Authentication and       |
              authorization phase   |
           <------                  | PANA-Auth-Request
                                    |   (including EAP Request)
           ------>                  | PANA-Auth-Answer
           ------>                  | PANA-Auth-Request
                                    |   (including EAP Response)
           <------                  | PANA-Auth-Answer
                                    |
                  ------------>     | EAP Request
                  <------------     | EAP Response
                                    |
           <------                  | PANA-Bind-Request
                                    |   (including EAP Success)
           ------>                  | PANA-Bind-Answer




Kainuma, et al.         Expires December 3, 2005                [Page 7]

Internet-Draft          fast PANA authentication               June 2005


               Figure 1: Authentication message flow in PANA

   First, the PaC multicasts the PANA-PAA-Discover message to discover a
   PAA.  The PAA that receives the PANA-PAA-Discover message sends the
   PANA-Start-Request message to the PaC to start a PANA session.  The
   EAP Request and EAP Response messages are included in the PANA-Auth-
   Request message.  After the PaC sends the PANA-Auth-Answer message,
   the PaC sends own authentication information to the PAA in the PANA-
   Auth-Request message.  After the PAA sends the PANA-Auth-Answer
   message to the PaC, the PAA must verify PaC's EAP Response by polling
   the PaC's AAAh in the home domain.  If the AAAh sends the EAP Success
   message to the PAA, the PAA sends the PANA-Bind-Request message to
   inform the PaC that authentication has succeeded.

3.3  Problem Statement

   According to the above explanation, authentication in PANA involves
   the exchange of a lot of messages.  Furthermore, the inquiry to the
   AAAh experiences long round trip times.  The further the PaC is from
   the home domain, the longer the round trip time of the inquiry to the
   AAAh will be.  This round trip time will be so large that the PaC may
   be continuing communication after the PaC's handover.  Thus, for
   nodes that move frequently, communication may be interrupted because
   of the large delay caused by authentication.  This is significant
   barrier to the practical use of PANA.


























Kainuma, et al.         Expires December 3, 2005                [Page 8]

Internet-Draft          fast PANA authentication               June 2005


4.  Protocol Overview

4.1  Design Principles

   When authentication is completed in the PANA session, all session
   attributes denoted in Section 3.1 are shared between PAA and PaC, and
   the session phase is changed to the "access phase".  The MN(PaC) can
   send and receive packets through the EP only when the PANA session is
   in the access phase.  For seamless handover, it is necessary for the
   NAR(nPAA) and the MN to establish a PANA session in the access phase.
   In order to reduce this establishment time, FPANA operates in such a
   way that the PAR transfers PANA session attributes, already
   negotiated between the PAR(pPAA) and the MN, to the NAR.  The
   authenticated state on the PAR can be carried over to the NAR by
   using FPANA without a new inquiry to the AAA server.

   In FPANA, the PAR should decide to which AR the context is to be
   transferred and when the context transfer should start.  FMIPv6 is
   utilized to achieve these goals.  Even if fast authentication is
   achieved, an L3 fast handover mechanism is necessary for seamless
   communications.  FMIPv6 is also employed for this purpose.  Moreover,
   using FMIPv6 messages to transfer PANA session attributes and using
   information from FMIPv6 to establish the new access phase of PANA
   session, means that PANA authentication can be finished with minimal
   message exchange compared to performing PANA and FMIPv6 sequentially.

4.2  Conditions

   FPANA architecture is the integration of PANA architecture with AAA
   architecture as denoted in Figure 2.





















Kainuma, et al.         Expires December 3, 2005                [Page 9]

Internet-Draft          fast PANA authentication               June 2005


        +-------Visited Domain------+              +-Home Domain--+
        |           +-------+       | +----------+ |   +------+   |
        |           | AAAv  |<------+-| Internet |-+-->| AAAh |   |
        |           +---+---+       | +----------+ |   +---+--+   |
        |               |           |              |       |      |
        |       --+-----+------+--  |              |       |      |
        |         |            |    |              |       |      |
        | +-------+-------+    |    |              |       |      |
        | | AR +--+-+     | +--+--+ |              |    +--+-+    |
        | |    |AAAc|     | | AR  | |              |    | AR |    |
        | |    +----+     | +-----+ |              |    +----+    |
        | | +----+ +----+ |         |              +--------------+
        | | |PAA | | EP | |         |
        | | +----+ +----+ |         |
        | +-------+-------+         |
        |         |                 |
        |     +---+---+             |
        |     |MN     |             |
        |     |+-----+|             |
        |     || PaC ||             |
        |     |+-----+|             |
        |     +-------+             |
        +---------------------------+

                       Figure 2: FPANA Architecture

   By way of example, DIAMETER is used as the AAA backend protocol to
   poll the AAA server about EAP authentication information.  AAAc, PAA
   and EP must be collocated in an AR, and PaC must be collocated in an
   MN, in order to collect some IDs and IP addresses which are some of
   the PANA session attributes for easy and rapid authentication (See
   Section 4.5.2).

   The following conditions must be met for FPANA operation:


   -A specific AAA backend infrastructure (e.g., using DIAMETER) must be
   present.


   -AAAc, PAA, and EP must reside in the same AR.


   -Communications between AAAv and AAAh and between PAR and NAR must be
   secure (e.g., through the use of IPsec).


   The PANA session parameters are called "the PANA context", and the



Kainuma, et al.         Expires December 3, 2005               [Page 10]

Internet-Draft          fast PANA authentication               June 2005


   operation of transferring the PANA context is called "context
   transfer (CT)".

   In order to protect context transfer, communications between a PAR
   and an NAR must be secure (e.g., through the use of IPsec).  Since it
   is difficult to establish a secure channel between ARs of different
   administrative domains in advance, FPANA is more applicable for MNs
   that move within the same administrative domain.

4.3  Protocol Operation of Predictive Mode

   For realizing FPANA, the messages and the functionality defined in
   FMIPv6 are extended with additional messages related to PANA CT.
   FPANA has two operation scenarios, "Predictive mode" and "Reactive
   mode", that are the same as FMIPv6.  In the former case, FMIP tunnel
   is established and the PANA CT is achieved before an MN attaches to
   the NAR.  In the latter case, an FMIP tunnel establishment and the CT
   are performed after the MN attaches to the NAR.

   In "Predictive mode", the MN sends the FPANA-FBU message and receives
   the FPANA-FBack message on the PAR's link.  Predictive mode operation
   is illustrated in Figure 3.  "RtSolPr", "PrRtAdv", "Hi", "HAck",
   "FBack", "FNA", and "NAack" are the messages of FMPIv6.  "PANA-PAA-
   Discovery", "PANA-Bind-Request", and "PANA-Bind-Answer" are the PANA
   messages.

   To determine which AR the MN will move to, the MN sends the RtSolPr
   message to the PAR and the PAR responds with the PrRtAdv message in
   the same manner as FMIPv6 (1,2).  The MN decides the target AR (NAR)
   and sends the FBU message to the PAR requesting PANA CT (FPANA-FBU)
   (3).  The PAR knows that the MN wants to perform FPANA, and so
   includes the MN's PANA session attributes in the HI message and sends
   it to the NAR (FPANA-HI) (4).  Details of the transfer of PANA
   session attributes are clarified in Section 4.5.  The NAR receives
   the FPANA-HI message and sends the HAck message to the PAR with the
   result of PANA CT (success/failure) (FPANA-HAck) (5).  The PAR sends
   the FPANA-FBack message to the MN and the NAR in order to relay the
   PANA CT result (6).  After receiving the FPANA-FBack message, the MN
   drops the PAR's link.  If the result is "success", the MN sends the
   FPANA-FNA message to notify the NAR of a new session as soon as the
   MN attaches to the NAR (7).  The NAR sends the PANA-Bind-Request
   message to the MN to confirm the new PANA session attributes (8).
   Lastly, the MN sends the PANA-Bind-Answer message to the NAR (9) and
   new PANA session are established in the access phase.

   If PANA CT results in "failure" when the PAR sends the FPANA-HI
   message including PANA session attributes, the NAR indicates the
   failure in FPANA-Hack and the PAR relays this to the MN.  In that



Kainuma, et al.         Expires December 3, 2005               [Page 11]

Internet-Draft          fast PANA authentication               June 2005


   case, after attaching to the NAR, the MN initiates the full PANA
   process.

        MN                        PAR                       NAR
         |        (1)RtSolPr       |                         |
         |------------------------>|                         |
         |        (2)PrRtAdv       |                         |
         |<------------------------|                         |
         | (3)FBPANA-FBU           |                         |
         |    (Request of PANA CT) |                         |
         |------------------------>|                         |
         |                         |(4)FPANA-HI              |
         |                         |(PANA Session Attributes)|
         |                         |------------------------>|
         |                         |(5)FPANA-HAck            |
         |                         | (PANA CT Result)        |
         |                         |<------------------------|
         |(6)FPANA-FBack           |(6)FPANA-FBack           |
         |        (PANA CT Result) |        (PANA CT Result) |
         |<------------------------|------------------------>|
         ~                         |                         |
        disconnect from PAR        |                         |
        connect to NAR             |                         |
         ~                         |                         |
         |                   (7)FPANA-FNA                    |
         |-------------------------|------------------------>|
         |               (8)PANA-Bind-Request                |
         |<------------------------|-------------------------|
         |                (9)PANA-Bind-Answer                |
         |-------------------------|------------------------>|

                  Figure 3: Operation in Predictive Mode


4.4  Protocol Operation of Reactive Mode

   If an MN does not receive the FPANA-FBack message on the PAR's link,
   it enters the "Reactive mode".  Reactive mode operation is
   illustrated in Figure 4.

   The RtSolPr message and the PrRtAdv message are sent in the same
   manner as FMIPv6 (1,2).  After connecting to the NAR, the MN sends
   the FPANA-FNA message including the FPANA-FBU message to the NAR to
   indicate the start of FPANA (3).  The NAR extracts the FPANA-FBU
   message from the FPANA-FNA message and sends it with the request of
   PANA CT to the PAR (FPANA-FBU) (4).  The PAR prepares the PANA
   session attributes of the MN and sends the FPANA-FBack message
   including those attributes to the NAR (5).  The NAR receives it and



Kainuma, et al.         Expires December 3, 2005               [Page 12]

Internet-Draft          fast PANA authentication               June 2005


   extracts the PANA session attributes.  If PANA CT completes
   successfully, the NAR sends the FPANA-FBack message includeing some
   AVPs which are conventionally contained in the original PANA-Bind-
   Request message, to the MN (6).  If the FPANA-FBack message contains
   the Result Code AVP without the AVPs of the original PANA-Bind-
   Request message, the MN knows that PANA CT has not been achieved and
   initiates the full PANA process.  Even if the MN receives the FPANA-
   NAack message from the NAR in the case that the new care-of address
   of the MN is not available, the MN also initiates the full PANA
   process.  In the case that the MN receives the FPANA-FBack message
   including the AVPs of the PANA-Bind-Request message, the MN responds
   by sending the PANA-Bind-Answer message to NAR (7), and a new PANA
   session between the MN and the NAR will be established in the access
   phase.

        MN                        PAR                       NAR
         |       (1)RtSolPr        |                         |
         |------------------------>|                         |
         |       (2)PrRtAdv        |                         |
         |<------------------------|                         |
         ~                         |                         |
        disconnect from PAR        |                         |
        connect to NAR             |                         |
         ~                         |                         |
         |              (3)FPANA-FNA(FPANA-FBU)              |
         |-------------------------|------------------------>|
         |                         |(4)FPANA-FBU             |
         |                         |       (PANA CT Request) |
         |                         |<------------------------|
         |                         |(5)FPANA-FBack           |
         |                         |(PANA Session Attributes)|
         |                         |------------------------>|
         |         (6)FPANA-FBack(PANA Bind Request)         |
         |<------------------------|-------------------------|
         |                (7)PANA-Bind-Answer                |
         |-------------------------|------------------------>|

                   Figure 4: Operation in Reactive Mode


4.5  Getting PANA Session Attributes

   In order to establish a PANA session in the access phase between an
   NAR and an MN, almost all PANA session attributes denoted in
   Section 3.1  must be set in the NAR and the MN.  However, it isn't
   necessary to transfer all these parameters because some of the
   parameters must be changed or can be gained from FMIPv6 messages.




Kainuma, et al.         Expires December 3, 2005               [Page 13]

Internet-Draft          fast PANA authentication               June 2005


4.5.1  Transfer Attributes

   FPANA transfers the following PANA session attributes via AVP:


      -Retransmission Interval

      -Session Lifetime

      -PANA_MAC_KEY

      -Nonce generated by PaC (PaC_nonce)

      -Nonce generated by PAA (PAA_nonce)

      -ISP's Information

   FPANA transfers some of the PANA session attributes such as "Session
   lifetime", "PaC_nonce", "PAA_nonce", "PANA_MAC_KEY" and
   "Retransmission interval".  Although the NAR and MN use the same
   PANA_MAC_KEY as the previous session, security is maintained by
   carrying over the "Session lifetime" from the previous session.  It
   is not necessary to transfer "AAA-Key" and "AAA-Key Identifier"
   because they are data of PANA_MAC_KEY.  In the re-authentication
   phase of PANA, PaC and PAA do not exchange nonces, so that
   "PaC_nonce" and "PAA_nonce" must be transferred.

   FPANA transfers information beyond the PANA session attributes such
   as "ISP's information".  "ISP's information" is used in the re-
   authentication phase of PANA to decide which AAA server the MN should
   go to for MN's authentication information.

4.5.2  Attributes gained from FMIPv6

   When PaC is collocated in the MN, the MAC address of the MN may be
   utilized as "Device-Id of PaC", and the IP address of the MN may be
   the same as the "IP address of PaC".  In predictive mode, the NAR
   gets these two attributes from the HI message of FMIPv6 in the
   options field (Figure 5): "Link-layer address of MN Option" and "New
   Care of Address Option".  In reactive mode, the NAR gets the two
   attributes from the FPANA-FNA message.  "Device-ID of PaC" is in the
   Mobility options field: "MH (Mobile Host)-LLA (Link Layer Address)
   option".  "IP address of PaC" is in the source address field.

   When EP and PAA are collocated in the AR, the MAC address of an NAR
   may be utilized as "Device identifier of EP", and the IP address of a
   NAR may be the same as the "IP address of PAA", so the MN gets these
   two parameters from the PrRtAdv message of FMIPv6 in the fields of



Kainuma, et al.         Expires December 3, 2005               [Page 14]

Internet-Draft          fast PANA authentication               June 2005


   "New Router's Link-layer Address Option" and "New Router's IP Address
   Option".

   In order to get the above attributes from FMIPv6 messages, PaC must
   be collocated in the MN, and EP and PAA must be collocated in the AR.

4.5.3  Other Method

   "Session-Id" is shared between the NAR and the MN by the PANA-Bind-
   Request message, because it is created by combining the NAR (PAA)'s
   ID and the MN (PaC)'s ID, and so represents a change from the
   previous one.  "Sequence number of last transmitted/received request"
   and "Last transmitted message payload" are initialized by exchanging
   the PANA-Bind-Request/Answer messages.

4.6  PANA Session Termination

   The lifetime of the PANA session between the PAR and MN may change to
   FMIP's tunnel lifetime when an FMIP tunnel is established.  When this
   lifetime expires, the previous PANA session is also terminated.  This
   termination reduces PAR's resource consumption and the risk of being
   attacked.  At the same time, the MN achieves low packet losses,
   because MN's new MIPv6 binding has already established when previous
   PANA session is shut down according to the FMIP's tunnel lifetime.



























Kainuma, et al.         Expires December 3, 2005               [Page 15]

Internet-Draft          fast PANA authentication               June 2005


5.  Definitions of Messages

   FPANA extends the FMIPv6 messages to achieve high-speed
   authentication.  This section illustrates the new option and message
   formats used in FPANA.

5.1  FPANA Option Header

   FPANA defines the FPANA option header to append AVPs to the FMIPv6
   messages.  AVPs carried in the FPANA messages are appended in the
   FPANA option header.  Figure 5 illustrates the format of the FPANA
   option header.

        +--------------+--------------+--------------+--------------+
        |     type     |    length    |    FPANA-transaction-ID     |
        +--------------+--------------+--------------+--------------+
        | message-type |                  reserved                  |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        ~                          AVPs...                          ~
        |                                                           |
        +--------------+--------------+--------------+--------------+

                Figure 5: The format of FPANA Option Header


   type:

      Type field identifies which option is appended.  The value of the
      type field is undecided:


         TYPE-FPANA:     undecided


   length:

      Length field indicates option length including all fields of the
      FPANA option header.


   FPANA-transaction-ID:

      FPANA-transaction-ID is instantiated with the FPANA-FBU message
      (predictive mode) or the FPANA-FNA message (reactive mode) by the
      MN.  This value is consistent throughout FPANA operation.





Kainuma, et al.         Expires December 3, 2005               [Page 16]

Internet-Draft          fast PANA authentication               June 2005


   message-type:

      Message type field identifies which message this option is
      appended to.  Following list shows the correspondence between the
      FPANA messages and the value of the message-type field:


         FPANA-FBU:      1

         FPANA-HI:       2

         FPANA-HAck:     3

         FPANA-FBack:    4

         FPANA-FNA:      5

         FPANA-NAack:    6


   reserved:

      Reserved field is reserved for future work.



5.2  Message Format

   Some FPANA messages make use of some bits in the reserved field to
   distinguish FPANA messages from original FMIPv6 and PANA messages.
   Figures 6-8 illustrate the formats of the FPANA messages.  "F" bit in
   Figures 6-8 indicates the FPANA bit that distinguishes FPANA messages
   from origial FMIPv6 and PANA messages.


















Kainuma, et al.         Expires December 3, 2005               [Page 17]

Internet-Draft          fast PANA authentication               June 2005


        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                                                           +
        |                                                           |
        +                                                           +
        |                         IP header                         |
        +                                                           +
        |                                                           |
        +                                                           +
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                        ICMP header                        |
        +              +------------+-+                             +
        |              |  reserved  |F|                             |
        +--------------+------------+-+--------------+--------------+
        |                                                           |
        ~                          options                          ~
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                    FPANA option header                    +
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        ~                           AVPs                            ~
        |                                                           |
        +--------------+--------------+--------------+--------------+

          Figure 6: The format of FPANA message using ICMP header






















Kainuma, et al.         Expires December 3, 2005               [Page 18]

Internet-Draft          fast PANA authentication               June 2005


        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                                                           +
        |                                                           |
        +                                                           +
        |                         IP header                         |
        +                                                           +
        |                                                           |
        +                                                           +
        |                                                           |
        +--------------+--------------+--------------+-+------------+
        |                                            |F|  reserved  |
        +                                            +-+------------+
        |                      mobility header                      |
        +                                                           +
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        ~                      mobility options                     ~
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                    FPANA option header                    +
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        ~                            AVPs                           ~
        |                                                           |
        +--------------+--------------+--------------+--------------+

                Figure 7: The format of FPANA-FBack message




















Kainuma, et al.         Expires December 3, 2005               [Page 19]

Internet-Draft          fast PANA authentication               June 2005


        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                                                           +
        |                                                           |
        +                                                           +
        |                         IP header                         |
        +                                                           +
        |                                                           |
        +                                                           +
        |                                                           |
        +--------------+--------------+--------------+-+------------+
        |                                            |F|  reserved  |
        +                                            +-+------------+
        |                      mobility header                      |
        +                                                           +
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        ~                      mobility options                     ~
        |                                                           |
        +--------------+--------------+--------------+--------------+
        |                                                           |
        +                    FPANA option header                    +
        |                                                           |
        +--------------+--------------+--------------+--------------+

          Figure 8: The format of FPANA-FBU and FPANA-FNA message


5.3  FPANA Messages

   This section describes details of each FPANA message.  Some messages
   of FMIPv6 and PANA remain unchanged while some are extended for
   context transfer.


   RtSolPr:

      The RtSolPr message in FMIPv6 is unchanged.


   PrRtAdv:

      The PrRtAdv message in FMIPv6 is unchanged.







Kainuma, et al.         Expires December 3, 2005               [Page 20]

Internet-Draft          fast PANA authentication               June 2005


   FPANA-FBU:

      The FPANA-FBU message is an extension of the FMIPv6 message.  This
      message can be distinguished from the original FBU message by the
      "F" bit in the mobility header in Figure 8.  The FPANA option
      header is appended but AVPs are not.


   FPANA-HI:

      The FPANA-HI message is an extension of the FMIPv6 message.  This
      message can be distinguished from the original HI message by the
      "F" bit in the ICMP header in Figure 6.  This message carries the
      PANA session attributes in the form of AVP.  AVPs are appended
      following the FPANA option header.  Details of the attributes
      contained in this message are described in Section 4.5.1.


   FPANA-HAck:

      The FPANA-HAck message is an extension of the FMIPv6 message.
      This message can be distinguished from the original HAck message
      by the "F" bit in the ICMP header in Figure 6.  This message
      contains the Result Code AVP to inform whether context transfer
      succeeded.


   FPANA-FBack:

      The FPANA-FBack message is an extension of the FMIPv6 message.
      This message can be distinguished from the original FBack message
      by the "F" bit in the mobility header in Figure 7.

      If predictive mode is executed, the FPANA option header and the
      Result Code AVP are appended.

      If reactive mode is executed, this message is sent to NAR; it
      carries the PANA session attributes in the form of AVP.  AVPs are
      appended following the FPANA option header.  The attributes
      contained in this message are described in Section 4.5.1.  When
      sent to the MN, it contains AVPs which are conventionally
      contained in the original PANA-Bind-Request message to start a new
      PANA session.








Kainuma, et al.         Expires December 3, 2005               [Page 21]

Internet-Draft          fast PANA authentication               June 2005


   FPANA-FNA:

      The FPANA-FNA message is an extension of the FMIPv6 message.  This
      message can be distinguished from the original FNA message by the
      "F" bit in the mobility header in Figure 8.  The FPANA option
      header is appended but AVPs are not.


   FPANA-NAack:

      The FPANA-NAack message is an extension of the FMIPv6 message.
      This message can be distinguished from the original NAack message
      by the "F" bit in the ICMP header in Figure 6.  If address
      collision is detected by the NAR in reactive mode, the FPANA-NAack
      message, which contains Result Code AVP, is sent to the MN.  This
      message indicates that the FPANA operation failed and the
      remaining operations were not executed.


   PANA-Bind-Request:

      The PANA-Bind-Request message in PANA is unchanged.  This message
      contains a new Session-Id calculated by the NAR and the MAC
      derived from the transferred PANA_MAC_KEY.


   PANA-Bind-Answer:

      The PANA-Bind-Answer message in PANA is unchanged.






















Kainuma, et al.         Expires December 3, 2005               [Page 22]

Internet-Draft          fast PANA authentication               June 2005


6.  Node Operation

   MN, PAR and NAR are the main nodes in FPANA.  This section describes
   protocol operation of each node.  In this section, operations just
   for FMIPv6 are omitted.

6.1  All Node Operation

   A message in which the "F" flag is not set should be considered as
   the original FMIPv6 message.  If a node receives a message in which
   the "F" flag is not set, conventional FMIPv6 or PANA operation is
   executed.

6.2  Mobile Node Operation

   When the MN detects the radio signal of a new AP, it sends the
   RtSolPr message to the PAR to get the NAR's information.  After the
   MN receives the PrRtAdv message from the PAR as a response of the
   RtSolPr message, which contains NAR's network prefix, NAR's IP
   address and NAR's MAC address, the MN derives a new CoA from NAR's
   network prefix.  At this moment, NAR's information contained in the
   PrRtAdv message are retained as the new PANA session attributes.  The
   MN sends the FPANA-FBU message to inform the PAR of the new CoA, and
   the MN waits for a response.  If the MN can send the FPANA-FBU
   message across the PAR's link, predictive mode will be executed.  If
   the MN cannot send the FPANA-FBU message across the PAR's link or the
   MN cannot receive the FPANA-FBack message on the PAR's link, reactive
   mode will be executed.  The MN can learn whether context transfer
   succeeded or not by checking the Result Code AVP contained in the
   FPANA-FBack message.

   If predictive mode is executed, after MN handover, the MN first
   informs the NAR that the MN has moved to NAR by sending the FPANA-FNA
   message.  After the MN receives the PANA-Bind-Request message as the
   response of the FPANA-FNA message,  the MN checks validity of the
   PANA-Bind-Request message using the PANA_MAC_KEY shared with the PAR.
   If the PANA-Bind-Request message is valid, the MN sends the PANA-
   Bind-Answer message to the NAR and authentication is complete.

   If reactive mode is executed, the FPANA-FNA message contains an
   encapsulated FPANA-FBU message.  The MN receives the FPANA-FBack
   message as a response of the FPANA-FNA message.  If PANA CT was
   successful, this FPANA-FBack message contains the AVPs that are
   conventionally contained in the PANA-Bind-Request message.  If PANA
   CT was not successful, this FPANA-FBack message contains only Result
   Code AVP which indicates that PANA CT was not successful.





Kainuma, et al.         Expires December 3, 2005               [Page 23]

Internet-Draft          fast PANA authentication               June 2005


6.3  Previous Access Router Operation

   When the PAR receives the RtSolPr message from the MN, the PAR sends
   the PrRtAdv message containing NAR's information, which corresponds
   to the AP indicated in the RtSolPr message.  When the PAR receives
   the FPANA-FBU message, it transfers the PANA session attributes to
   the NAR, and establishes a binding between the MN's previous CoA and
   the new CoA.  Additionally, the session lifetime of the previous PANA
   session with the MN is set to the lifetime of the binding.

   If the FPANA-FBU message is sent by the MN, predictive mode is
   executed and the PAR transfers the PANA session attributes to the NAR
   by the FPANA-HI message.  The PAR receives the FPANA-HAck message and
   can learn whether context transfer succeeded or not by the Result
   Code AVP contained in the FPANA-HAck message.  Finally, the PAR sends
   the FPANA-FBack message to the MN and the NAR.  The FPANA-FBack
   message contains Result Code AVP which is the same as that of the
   FPANA-HAck message.

   If the FPANA-FBU message is sent by the NAR, reactive mode is
   executed and the PAR transfers the PANA session attributes to the NAR
   by the FPANA-FBack message.

6.4  New Access Router Operation

   If predictive mode is executed, the NAR receives the FPANA-HI message
   from the PAR.  MN's new CoA and MAC address and transferred PANA
   session attributes are retained as the new PANA session attributes.
   The NAR informs the PAR as to whether the NAR received all PANA
   session attributes by the FPANA-HAck message.  When the NAR receives
   the FPANA-FBack message from the PAR, the NAR's operations prior to
   the MN handover are completed, and the NAR waits for the FPANA-FNA
   message from the MN.  When the NAR receives the FPANA-FNA message,
   the NAR learns that the MN has attached to the NAR's link.  The NAR
   then establishes a new PANA session with the MN by using MN's
   information and the PANA session attributes contained in the FPANA-HI
   message.  The NAR sends the PANA-Bind-Request message to inform the
   MN that the new PANA session between the NAR and the MN has been
   established.  Finally, the NAR receives the PANA-Bind-Answer message
   from the MN in response to the PANA-Bind-Request message.  The NAR
   verifies the PANA-Bind-Answer message by checking the validity of the
   MAC AVP contained in the FPANA-HI message using the PANA_MAC_KEY.  If
   the PANA-Bind-Answer message is valid, MN's authentication is done.

   If reactive mode is executed, the NAR receives the FPANA-FNA message
   including the FPANA-FBU message from the MN.  MN's MAC address and
   MN's new CoA are retained as the new PANA session attributes.  The
   NAR extracts the FPANA-FBU message from the FPANA-FNA message, and



Kainuma, et al.         Expires December 3, 2005               [Page 24]

Internet-Draft          fast PANA authentication               June 2005


   then sends the extracted FPANA-FBU message to the PAR.  When the NAR
   receives the FPANA-FBack message from the PAR, the PANA session
   attributes contained in the FPANA-FBack message are retained as the
   new PANA session attributes.  The NAR then sends the FPANA-FBack
   message to the MN.  This FPANA-FBack message contains the AVPs that
   are conventionally contained in the PANA-Bind-Request message.
   Subsequent operations are the same as those of predictive mode.












































Kainuma, et al.         Expires December 3, 2005               [Page 25]

Internet-Draft          fast PANA authentication               June 2005


7.  Security Considerations

   In FPANA, there may be some security vulnerabilities.  This section
   describes the security vulnerabilities and solutions.

7.1  MN-PAR security

   In FPANA, a PANA SA must be established between the MN and the PAR
   before MN handover.  Otherwise, there is no PANA context to transfer
   from PAR to NAR and PANA CT can not be executed.  A PANA SA means
   that the MN and the PAR have a relationship of mutual trust.  That
   is, spoofing of PAR can be avoided.

   In addition, another security association must be established between
   the MN and the PAR before MN handover.  All traffic including the
   FPANA messages between the MN and the PAR must be protected.  The
   effect of a PANA SA is limited to just the PANA messages, so another
   security association (e.g.  IPsec SA) to protect the FPANA messages
   is needed.  The protected FPANA-FBU message realized by the security
   association between MN and PAR secures the initiation of FPANA
   operation.

7.2  AR-AR security

   To realize FPANA, the PANA session attributes must be transferred
   between ARs.  If any packets exchanged between ARs are tampered or
   eavesdropped, authentication may result in failure.  To protect all
   packets exchanged between ARs, a security association must be
   established between the ARs.  If security association is established,
   integrity and confidentiality of packets exchanged between ARs are
   ensured.  In particular, the FPANA messages containing the PANA
   session attributes such as the FPANA-HI message and the FPANA-FBack
   message must be protected (e.g. by IPsec ESP).  A security
   association between ARs also prevent transfer to a malicious NAR.

   Establishing a security association between ARs predictively makes it
   possible to transfer the PANA session attributes without requiring
   prior authentication of other AR.  It may be possible to establish a
   security association between ARs predictively.  Since FPANA supports
   only intra-domain handover, ARs which must establish security
   association are limited to those in the same domain.  ARs in the same
   domain are managed by the same administration policy, so it is just
   conceivable that security associations are established between all
   neighbor ARs in the same domain predictively.

7.3  Validity of transferring PANA session attributes

   In FPANA, the PANA_MAC_KEY itself is transferred between ARs.  That



Kainuma, et al.         Expires December 3, 2005               [Page 26]

Internet-Draft          fast PANA authentication               June 2005


   is, the same PANA_MAC_KEY is used for the PANA SA before and after MN
   handover.  All transferred PANA session attributes including
   PANA_MAC_KEY are protected as noted above.  Furthermore, the session
   lifetime is transferred between ARs, so any degradation of the
   PANA_MAC_KEY's reliability is carried over after MN handover.  Re-
   authentication will be executed if the session lifetime is expired,
   so the safety of the PANA_MAC_KEY can be ensured.  FPANA performs no
   confirmation of MN's authorization after the handover.  Since the
   handover is limited to AR's in the same administrative domain, MN's
   authorization is not changed by handover.









































Kainuma, et al.         Expires December 3, 2005               [Page 27]

Internet-Draft          fast PANA authentication               June 2005


8.  Intellectual Property Right

   There are formats and mechanisms included in the following pending
   patent application that has been FILED to the Japanese Patent office.


      -Japanese application No.2005-093049 Keio University, Japan
      Telecom

   This includes the combining mechanisms of PANA CT and FMIPv6 and the
   formats of the messages.  It must be stressed that it has only been
   filed, and has not been granted.  We really intend to contribute to
   the development of the Internet community and to keep a good
   relationship with IETF.  Our primary concern is to promote our
   technology so that others may feel it is useful and worthwhile in the
   spirit of IETF.  If indeed the mechanisms and formats are granted as
   patents, the patents will be licensed under reasonable and non-
   discriminatory conditions to any person who wants to implement the
   mechanisms.

9.  References

   [1]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin,
        "Protocol for Carrying Authentication for Network Access
        (PANA)", draft-ietf-pana-pana-08 (work in progress), May 2005.

   [2]  Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C.,
        Soliman, H., Tsirtsis, G., and A. Yegin, "Fast Handovers for
        Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in
        progress), October 2004.


Authors' Addresses

   Yoshihiko Kainuma
   Graduate School of Science and Technology, KEIO University
   3-14-1 Hiyoshi, Kohoku-ku
   Yokohama, Kanagawa  223-8522
   Japan

   Phone: +81-45-566-1425
   Email: hiko@tera.ics.keio.ac.jp
   URI:   http://www.tera.ics.keio.ac.jp/








Kainuma, et al.         Expires December 3, 2005               [Page 28]

Internet-Draft          fast PANA authentication               June 2005


   Natsuko Ono
   R&D Center, BB Mobile Corp.
   1-9-1 Higashi-shimbashi
   Minato-ku, Tokyo  105-7304
   Japan

   Phone: +81-3-6889-2144
   Email: naono@softbank.co.jp
   and
   Laboratories, Japan Telecom Co., Ltd.
   1-9-1 Higashi-shimbashi 
   Minato-ku, Tokyo  105-7316
   Japan

   Phone: +81-50-2019-3753
   Email:natsuko.ono@japan-telecom.co.jp
   URI:   http://www.japan-telecom.co.jp/


   Hideki Hayashi
   R&D Center, BB Mobile Corp.
   1-9-1 Higashi-shimbashi
   Minato-ku, Tokyo  105-7304
   Japan

   Phone: +81-3-6889-2144
   Email: hidhayas@softbank.co.jp
   and
   Laboratories, Japan Telecom Co., Ltd.
   1-9-1 Higashi-shimbashi
   Minato-ku, Tokyo  105-7316
   Japan

   Phone: +81-50-2019-5347
   Email:hideki.hayashi@japan-telecom.co.jp   
   URI:   http://www.japan-telecom.co.jp/


   Fumio Teraoka
   Graduate School of Science and Technology, KEIO University
   3-14-1 Hiyoshi, Kohoku-ku
   Yokohama, Kanagawa  223-8522
   Japan

   Phone: +81-45-566-1425
   Email: tera@ics.keio.ac.jp
   URI:   http://www.tera.ics.keio.ac.jp/




Kainuma, et al.         Expires December 3, 2005               [Page 29]

Internet-Draft          fast PANA authentication               June 2005


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.




Kainuma, et al.         Expires December 3, 2005               [Page 30]