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]
