draft-ietf-pana-framework-02.txt draft-ietf-pana-framework-03.txt
PANA Working Group P. Jayaraman PANA Working Group P. Jayaraman
Internet-Draft Net.Com Internet-Draft Net.Com
Expires: March 16, 2005 R. Lopez Expires: June 28, 2005 R. Lopez
Univ. of Murcia Univ. of Murcia
Y. Ohba (Ed.) Y. Ohba (Ed.)
Toshiba Toshiba
M. Parthasarathy M. Parthasarathy
Nokia Nokia
A. Yegin A. Yegin
Samsung Samsung
September 15, 2004 December 28, 2004
PANA Framework PANA Framework
draft-ietf-pana-framework-02 draft-ietf-pana-framework-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
  Skipping to change at page 1, line 41:
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 16, 2005. This Internet-Draft will expire on June 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
PANA design provides support for various types of deployments. PANA (Protocol for carrying Authentication for Network Access) design
Access networks can differ based on the availability of lower-layer provides support for various types of deployments. Access networks
security, placement of PANA entities, choice of client IP can differ based on the availability of lower-layer security,
configuration and authentication methods, etc. This I-D defines a placement of PANA entities, choice of client IP configuration and
general framework for describing how these various deployment choices authentication methods, etc. This document defines a general
are handled by PANA and the access network architectures. framework for describing how these various deployment choices are
Additionally, two possible deployments are described in detail: using handled by PANA and the access network architectures. Additionally,
PANA over DSL networks and WLAN networks. two possible deployments are described in detail: using PANA over DSL
networks and wireless LANs.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Specification of Requirements . . . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General PANA Framework . . . . . . . . . . . . . . . . . . . 6 3. General PANA Framework . . . . . . . . . . . . . . . . . . . 6
4. Environments . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IP Address Configuration . . . . . . . . . . . . . . . . . . 13 5. IP Address Configuration . . . . . . . . . . . . . . . . . . 13
6. Data Traffic Protection . . . . . . . . . . . . . . . . . . 16 6. Data Traffic Protection . . . . . . . . . . . . . . . . . . 16
  Skipping to change at page 2, line 32:
7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . 18 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . 18
7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . 18 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . 18
7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 20 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 20
7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 20 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 20
8. Network Selection . . . . . . . . . . . . . . . . . . . . . 21 8. Network Selection . . . . . . . . . . . . . . . . . . . . . 21
9. Authentication Method Choice . . . . . . . . . . . . . . . . 23 9. Authentication Method Choice . . . . . . . . . . . . . . . . 23
10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . 24 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . 24
10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . 24 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . 24
10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . 24 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . 24
10.1.2 Router Mode . . . . . . . . . . . . . . . . . . . . 25 10.1.2 Router Mode . . . . . . . . . . . . . . . . . . . . 25
10.1.3 PANA and Dynamic Internet Service Provider 10.1.3 PANA and Dynamic ISP Selection . . . . . . . . . . . 26
Selection . . . . . . . . . . . . . . . . . . . . . 25 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . 27
10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . 26
10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . 28 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . 28
10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 32 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 32
10.2.3 Capability Discovery . . . . . . . . . . . . . . . . 33 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . 34
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1 Normative References . . . . . . . . . . . . . . . . . . . 36 12.1 Normative References . . . . . . . . . . . . . . . . . . . 36
12.2 Informative References . . . . . . . . . . . . . . . . . . 37 12.2 Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
A. Other Possible Cases for PANA with Bootstrapping IPsec in A. Other Possible Cases for PANA with Bootstrapping IPsec in
Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 40 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 41
A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . 47
1. Introduction 1. Introduction
PANA is a link-layer agnostic network access authentication protocol PANA (Protocol for carrying Authentication for Network Access) is a
that runs between a node that wants to gain access to the network and link-layer agnostic network access authentication protocol that runs
a server on the network side. PANA defines a new EAP [RFC3748] lower between a node that wants to gain access to the network and a server
layer that uses IP between the protocol end points. on the network side. PANA defines a new EAP [RFC3748] lower layer
that uses IP between the protocol end points.
The motivation to define such a protocol and the requirements are The motivation to define such a protocol and the requirements are
described in [I-D.ietf-pana-requirements]. Protocol details are described in [I-D.ietf-pana-requirements]. Protocol details are
documented in [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes documented in [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes
use of IPsec for access control following PANA-based authentication. use of IPsec for access control following PANA-based authentication.
IPsec can be used for per-packet access control, but nevertheless it IPsec can be used for per-packet access control, but nevertheless it
is not the only way to achieve this functionality. Alternatives is not the only way to achieve this functionality. Alternatives
include reliance on physical security and link-layer ciphering. include reliance on physical security and link-layer ciphering.
Separation of PANA server from the entity enforcing the access Separation of PANA server from the entity enforcing the access
control is envisaged as an optional deployment choice. SNMP control is envisaged as an optional deployment choice. SNMP
  Skipping to change at page 3, line 47:
placed on various elements in the access network (e.g., access point, placed on various elements in the access network (e.g., access point,
access router, dedicated host). access router, dedicated host).
IP address configuration mechanisms vary as well. Static IP address configuration mechanisms vary as well. Static
configuration, DHCP, stateless address autoconfiguration are possible configuration, DHCP, stateless address autoconfiguration are possible
mechanisms to choose from. If the client configures an IPsec tunnel mechanisms to choose from. If the client configures an IPsec tunnel
for enabling per-packet security, configuring IP addresses inside the for enabling per-packet security, configuring IP addresses inside the
tunnel becomes relevant, for which there are additional choices such tunnel becomes relevant, for which there are additional choices such
as IKE. as IKE.
This I-D defines a general framework for describing how these various This document defines a general framework for describing how these
deployment choices are handled by PANA and the access network various deployment choices are handled by PANA and the access network
architectures. Additionally, two possible deployments are described architectures. Additionally, two possible deployments are described
in detail: PANA over DSL networks and WLAN networks. in detail: PANA over DSL (Digital Subscriber Line) networks and WLANs
(Wireless LANs).
1.1 Specification of Requirements 1.1 Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
  Skipping to change at page 6, line 10:
initial entity authentication (and authorization) exchange to the initial entity authentication (and authorization) exchange to the
subsequent exchange of data packets. Examples of secure subsequent exchange of data packets. Examples of secure
association protocols include the 4-way handshake in IEEE 802.11i association protocols include the 4-way handshake in IEEE 802.11i
[802.11i], and IKE [RFC2409] in IP-based access control. [802.11i], and IKE [RFC2409] in IP-based access control.
3. General PANA Framework 3. General PANA Framework
PANA protocol is designed to facilitate authentication and PANA protocol is designed to facilitate authentication and
authorization of clients in access networks. PANA is an EAP authorization of clients in access networks. PANA is an EAP
[RFC3748] lower-layer that carries EAP authentication methods [RFC3748] lower-layer that carries EAP authentication methods
encapsulated inside EAP between a client host and an agent in the encapsulated inside EAP between a client node and an agent in the
access network. While PANA enables the authentication process access network. While PANA enables the authentication process
between the two entities, it is only a part of an overall AAA and between the two entities, it is only a part of an overall AAA
access control framework. A AAA and access control framework using (Authentication Authorization and Accounting) and access control
PANA is comprised of four functional entities. framework. A AAA and access control framework using PANA is
comprised of four functional entities.
PANA Client (PaC): PANA Client (PaC):
The PaC is the client implementation of the PANA protocol. This The PaC is the client implementation of the PANA protocol. This
entity resides on the end host that is requesting network access. entity resides on the node that is requesting network access.
The end hosts are, for example, laptops, PDAs, cell phones, PaCs can be end hosts, such as laptops, PDAs, cell phones, desktop
desktop pcs that are connected to a network via a wired or PCs, or routers that are connected to a network via a wired or
wireless interface. A PaC is responsible for requesting network wireless interface. A PaC is responsible for requesting network
access and engaging in the authentication process using the PANA access and engaging in the authentication process using the PANA
protocol protocol.
PANA Authentication Agent (PAA): PANA Authentication Agent (PAA):
The PAA is the server implementation of the PANA protocol. A PAA The PAA is the server implementation of the PANA protocol. A PAA
is in charge of interfacing with the PaCs for authenticating and is in charge of interfacing with the PaCs for authenticating and
authorizing them for the network access service. authorizing them for the network access service.
The PAA consults an authentication server in order to verify the The PAA consults an authentication server in order to verify the
credentials and rights of a PaC. If the authentication server credentials and rights of a PaC. If the authentication server
resides on the same host as the PAA, an API is sufficient for this resides on the same node as the PAA, an API is sufficient for this
interaction. When they are separated (a much more common case in interaction. When they are separated (a much more common case in
public access networks), a protocol needs to run between the two. public access networks), a protocol needs to run between the two.
LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and
Diameter [RFC3588] are commonly used for this purpose. Diameter [RFC3588] are commonly used for this purpose.
The PAA is also responsible for updating the access control state The PAA is also responsible for updating the access control state
(i.e., filters) depending on the creation and deletion of the (i.e., filters) depending on the creation and deletion of the
authorization state. The PAA communicates the updated state to authorization state. The PAA communicates the updated state to
the enforcement points in the network. If the PAA and EP are the enforcement points in the network. If the PAA and EP are
residing on the same host, an API is sufficient for this residing on the same node, an API is sufficient for this
communication. Otherwise, a protocol is required to carry the communication. Otherwise, a protocol is required to carry the
authorized client attributes from the PAA to the EP. While not authorized client attributes from the PAA to the EP. While not
prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp]
is suggested for this task. is suggested for this task.
The PAA resides on a node that is typically called a NAS (network The PAA resides on a node that is typically called a NAS (network
access server) in the local area network. PAA can be hosted on access server) in the local area network. The PAA can be hosted
any IP-enabled node on the same IP subnet as the PaC. For example on any IP-enabled node on the same IP subnet as the PaC. For
on a BAS (broadband access server) in DSL networks, or PDSN in example on a BAS (Broadband Access Server) in DSL networks, or
3GPP2 networks. PDSN (Packet Data Serving Node) in 3GPP2 networks.
Authentication Server (AS): Authentication Server (AS):
The server implementation that is in charge of verifying the The server implementation that is in charge of verifying the
credentials of a PaC that is requesting the network access credentials of a PaC that is requesting the network access
service. The AS receives requests from the PAA on behalf of the service. The AS receives requests from the PAA on behalf of the
PaCs, and responds with the result of verification together with PaCs, and responds with the result of verification together with
the authorization parameters (e.g., allowed bandwidth, IP the authorization parameters (e.g., allowed bandwidth, IP
configuration, etc). The AS might be hosted on the same host as configuration, etc). The AS might be hosted on the same node as
the PAA, on a dedicated host on the access network, or on a the PAA, on a dedicated node on the access network, or on a
central server somewhere on the Internet. central server somewhere in the Internet.
Enforcement Point (EP): Enforcement Point (EP):
The access control implementation that is in charge of allowing The access control implementation that is in charge of allowing
access to authorized clients while preventing access by others. access to authorized clients while preventing access by others.
An EP learns the attributes of the authorized clients from the An EP learns the attributes of the authorized clients from the
PAA. PAA.
The EP uses non-cryptographic or cryptographic filters to The EP uses non-cryptographic or cryptographic filters to
selectively allow and discard data packets. These filters may be selectively allow and discard data packets. These filters may be
  Skipping to change at page 7, line 43:
between the PaC and EP. Link or network layer protection (for between the PaC and EP. Link or network layer protection (for
example TKIP, IPsec ESP) is used after the secure association example TKIP, IPsec ESP) is used after the secure association
protocol established the necessary security association to enable protocol established the necessary security association to enable
integrity protection, data origin authentication, replay integrity protection, data origin authentication, replay
protection and optionally confidentiality protection. protection and optionally confidentiality protection.
An EP must be located strategically in a local area network to An EP must be located strategically in a local area network to
minimize the access of unauthorized clients to the network. For minimize the access of unauthorized clients to the network. For
example, the EP can be hosted on the switch that is directly example, the EP can be hosted on the switch that is directly
connected to the clients in a wired network. That way the EP can connected to the clients in a wired network. That way the EP can
drop unauthorized packets before they reach any other client host drop unauthorized packets before they reach any other client node
or beyond the local area network. or beyond the local area network.
Figure 1 illustrates these functional entities and the interfaces Figure 1 illustrates these functional entities and the interfaces
(protocols, APIs) among them. (protocols, APIs) among them.
RADIUS/ RADIUS/
Diameter/ Diameter/
+-----+ PANA +-----+ LDAP/ API +-----+ +-----+ PANA +-----+ LDAP/ API +-----+
| PaC |<----------------->| PAA |<---------------->| AS | | PaC |<----------------->| PAA |<---------------->| AS |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
  Skipping to change at page 8, line 27:
Some of the entities may be co-located depending on the deployment Some of the entities may be co-located depending on the deployment
scenario. For example, the PAA and EP would be on the same node scenario. For example, the PAA and EP would be on the same node
(BAS) in DSL networks. In that case a simple API is sufficient (BAS) in DSL networks. In that case a simple API is sufficient
between the PAA and EP. In small enterprise deployments the PAA and between the PAA and EP. In small enterprise deployments the PAA and
AS may be hosted on the same node (access router) that eliminates the AS may be hosted on the same node (access router) that eliminates the
need for a protocol run between the two. The decision to co-locate need for a protocol run between the two. The decision to co-locate
these entities or otherwise, and their precise location in the these entities or otherwise, and their precise location in the
network topology are deployment decisions. network topology are deployment decisions.
Use of IKE or 4-way handshake protocols for secure association is Use of IKE or IEEE 802.11i 4-way handshake protocols for secure
only required in the absence of any lower-layer security prior to association is only required in the absence of any lower-layer
running PANA. Physically secured networks (e.g., DSL) or the security prior to running PANA. Physically secured networks (e.g.,
networks that are already cryptographically secured on the link-layer DSL) or the networks that are already cryptographically secured on
prior to PANA run (e.g., cdma2000) do not require additional secure the link-layer prior to PANA run (e.g., cdma2000) do not require
association and per-packet ciphering. These networks can bind the additional secure association and per-packet ciphering. These
PANA authentication and authorization to the lower-layer secure networks can bind the PANA authentication and authorization to the
channel that is already available. lower-layer secure channel that is already available.
Figure 2 illustrates the signaling flow for authorizing a client for Figure 2 illustrates the signaling flow for authorizing a client for
network access. network access.
PaC EP PAA AS PaC EP PAA AS
| | | | | | | |
IP address o | | | IP address o | | |
config. | PANA | | AAA | config. | PANA | | AAA |
|<------------------------------>|<-------------->| |<------------------------------>|<-------------->|
| | SNMP | | | | SNMP | |
(Optional) | |<-------------->| | (Optional) | |<-------------->| |
IP address o | | | IP address o | | |
config. | Sec.Assoc. | | | reconfig. | Sec.Assoc. | | |
|<------------->| | | |<------------->| | |
| | | | | | | |
| Data traffic | | | | Data traffic | | |
|<-----------------> | | |<-----------------> | |
| | | | | | | |
Figure 2: PANA Signaling Flow Figure 2: PANA Signaling Flow
The EP on the access network allows general data traffic from any The EP on the access network allows general data traffic from any
authorized PaC, whereas it allows only limited type of traffic (e.g., authorized PaC, whereas it allows only limited type of traffic (e.g.,
PANA, DHCP, router discovery) for the unauthorized PaCs. This PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This
ensures that the newly attached clients have the minimum access ensures that the newly attached clients have the minimum access
service to engage in PANA and get authorized for the unlimited service to engage in PANA and get authorized for the unlimited
service. service.
The PaC MUST configure an IP address prior to running PANA. After The PaC MUST configure an IP address prior to running PANA. After
the successful PANA authentication, depending on the deployment the successful PANA authentication, depending on the deployment
scenario the PaC MAY need to re-configure its IP address or configure scenario the PaC MAY need to re-configure its IP address or configure
additional IP address(es). The additional address configuration MAY additional IP address(es). The additional address configuration MAY
be executed as part of the secure association protocol run. be executed as part of the secure association protocol run (e.g., via
IKE).
An initially unauthorized PaC starts the PANA authentication by An initially unauthorized PaC starts the PANA authentication by
discovering the PAA on the access network, followed by the EAP discovering the PAA on the access network, followed by the EAP
exchange over PANA. The PAA interacts with the AS during this exchange over PANA. The PAA interacts with the AS during this
process. Upon receiving the authentication and authorization result process. Upon receiving the authentication and authorization result
from the AS, the PAA informs the PaC about the result of its network from the AS, the PAA informs the PaC about the result of its network
access request. access request.
If the PaC is authorized to gain the access to the network, the PAA If the PaC is authorized to gain the access to the network, the PAA
also sends the PaC-specific attributes (e.g., IP address, also sends the PaC-specific attributes (e.g., IP address,
cryptographic keys, etc.) to the EP by using SNMP. The EP uses this cryptographic keys, etc.) to the EP by using SNMP. The EP uses this
information to alter its filters for allowing data traffic from and information to alter its filters for allowing data traffic from and
to the PaC to pass through. to the PaC to pass through.
In case cryptographic access control needs to be enabled after the In case cryptographic access control needs to be enabled after the
PANA authentication, a secure association protocol runs between the PANA authentication, a secure association protocol runs between the
PaC and the EP. The PaC should already have the input parameters to PaC and the EP. The PaC should already have the input parameters to
this process as a result of the successful PANA exchange. Similarly, this process as a result of the successful PANA exchange. Similarly,
the EP should have obtained them from the PAA via SNMP. Secure the EP should have obtained them from the PAA via SNMP. The secure
association exchange produces the required security associations association protocol exchange produces the required security
between the PaC and the EP to enable cryptographic data traffic associations between the PaC and the EP to enable cryptographic data
protection. Per-packet cryptographic data traffic protection traffic protection. Per-packet cryptographic data traffic protection
introduces additional per-packet overhead but the overhead exists introduces additional per-packet overhead but the overhead exists
only between the PaC and EP and will not affect communications beyond only between the PaC and EP and will not affect communications beyond
the EP. In this sense it is important to place the EP as close to the EP. In this sense it is important to place the EP as close to
the edge of the network as possible. the edge of the network as possible.
Finally data traffic can start flowing from and to the newly Finally data traffic can start flowing from and to the newly
authorized PaC. authorized PaC.
4. Environments 4. Environments
  Skipping to change at page 12, line 6:
association protocol to enable per-packet cryptographic association protocol to enable per-packet cryptographic
protection. protection.
PANA authentication is run on an insecure channel that is PANA authentication is run on an insecure channel that is
vulnerable to eavesdropping and spoofing. The choice of EAP vulnerable to eavesdropping and spoofing. The choice of EAP
method must be resilient to the possible attacks associated with method must be resilient to the possible attacks associated with
such an environment. Furthermore, the EAP method must be able to such an environment. Furthermore, the EAP method must be able to
create cryptographic keys that will later be used by the secure create cryptographic keys that will later be used by the secure
association protocol. association protocol.
Whether to use a link-layer per-frame security (b.1) or a network Whether to use a link-layer per-packet security (b.1) or a network
layer security (b.2) is a deployment decision. This decision also layer security (b.2) is a deployment decision. This decision also
dictates the choice of the secure association protocol. If dictates the choice of the secure association protocol. If
link-layer protection is used, the protocol would be link-layer link-layer protection is used, the protocol would be link-layer
specific. If IP-layer protection is used, the secure association specific. If IP-layer protection is used, the secure association
protocol would be IKE and the per-packet security would be protocol would be IKE and the per-packet security would be
provided by IPsec AH/ESP regardless of the underlying link-layer provided by IPsec AH/ESP regardless of the underlying link-layer
technology. technology.
5. IP Address Configuration 5. IP Address Configuration
The PaC configures an IP address before the PANA protocol exchange The PaC configures an IP address before the PANA protocol exchange
begins. This address is called a pre-PANA address (PRPA). After a begins. This address is called a pre-PANA address (PRPA). After a
successful authentication, the client may have to configure a successful authentication, the client may have to configure a
post-PANA address (POPA) for communication with other nodes, if PRPA post-PANA address (POPA) for communication with other nodes, if the
is a local-use (e.g., link-local or private address) or a temporarily PRPA is a local-use (e.g., a link-local or private address) or a
allocated IP address. An operator might choose allocating a POPA temporarily allocated IP address. An operator might choose
only after successful PANA authorization either to prevent waste of allocating a POPA only after successful PANA authorization either to
premium IP resources until the client is authorized, or to enable prevent waste of premium (e.g., globally routable) IP resources until
client identity based address assignment. the client is authorized, or to enable client identity based address
assignment.
In case the PaC is a IPv4/IPv6 dual-stacked host, it may configure In case the PaC is a IPv4/IPv6 dual-stacked node, it may configure
more than one PRPA. After a successful PANA authentication the PaC more than one PRPA. After a successful PANA authentication the PaC
may configure multiple POPAs. may configure multiple POPAs.
There are different methods by which a PRPA can be configured. There are different methods by which a PRPA can be configured.
1. In some deployments (e.g., DSL networks) the PaC may be 1. In some deployments (e.g., DSL networks) the PaC may be
statically configured with an IP address. This address SHOULD be statically configured with an IP address. This address SHOULD be
used as PRPA. used as a PRPA.
2. In IPv4, most clients attempt to configure an address dynamically 2. In IPv4, most clients attempt to configure an address dynamically
using DHCP [RFC2131]. If they are unable to configure an address using DHCP [RFC2131]. If they are unable to configure an address
using DHCP, they can configure a link-local address using using DHCP, they can configure a link-local address using
[I-D.ietf-zeroconf-ipv4-linklocal]. [I-D.ietf-zeroconf-ipv4-linklocal].
When the network access provider is able to run a DHCP server on When the network access provider is able to run a DHCP server on
the access link, the client would configure the PRPA using DHCP. the access link, the client would configure the PRPA using DHCP.
This address may be from a private address pool [RFC1918]. Also, This address may be from a private address pool [RFC1918]. Also,
the lease time on the address may vary. For example, a PRPA the lease time on the address may vary. For example, a PRPA
configured solely for running PANA can have a short lease time. configured solely for running PANA can have a short lease time.
PRPA may be used for local-use only (i.e., only for on-link The PRPA may be used for local-use only (i.e., only for on-link
communication, such as for PANA and IPsec tunneling with EP), or communication, such as for PANA and IPsec tunneling with EP), or
also for ultimate data communication. also for ultimate end-to-end data communication.
In case there is no running DHCP server on the link, the client In case there is no running DHCP server on the link, the client
would fall back to configuring a PRPA via zeroconfiguration would fall back to configuring a PRPA via zeroconfiguration
technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a
long-term address that can only be used for on-link communication. long-term address that can only be used for on-link communication.
3. In IPv6, clients configure a link-local address [RFC2462] when 3. In IPv6, clients configure a link-local address [RFC2462] when
they initialize an interface. This address SHOULD be used as a they initialize an interface. This address SHOULD be used as a
PRPA. PRPA.
When a PRPA is configured, the client starts the PANA protocol When a PRPA is configured, the client starts the PANA protocol
exchange. By that time, a dual-stacked client might have configured exchange. By that time, a dual-stacked client might have configured
both an IPv4 address, and one or more IPv6 addresses as PRPAs. When both an IPv4 address, and one or more IPv6 addresses as PRPAs.
the client successfully authenticates to the network, it may be
When the client successfully authenticates to the network, it may be
required to configure POPAs for its subsequent data communication required to configure POPAs for its subsequent data communication
with the other nodes. with the other nodes.
If the client is already configured with a non-temporary address that If the client is already configured with a non-temporary address that
can be used with data communication, it is not required to configure can be used with data communication, it is not required to configure
a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to
indicate the available configuration methods to the PaC. The PaC can indicate the available configuration methods to the PaC. The PaC can
choose one of the methods and act accordingly. choose one of the methods and act accordingly.
1. If the network relies on physical or link-layer security, the PaC 1. If the network relies on physical or link layer security, the PaC
can configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6 can configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6
stateless auto-configuration [RFC2461]. If IPv4 is being used, a stateless auto-configuration [RFC2461]. If IPv4 is being used, a
PRPA is likely to be a link-local or private address, or an PRPA is likely to be a link-local or private address, or an
address with a short DHCP lease. An IPv4 PRPA SHOULD be address with a short DHCP lease. An IPv4 PRPA SHOULD be
unconfigured when the POPA is configured to prevent IPv4 address unconfigured when the POPA is configured to prevent IPv4 address
selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is
used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484]. used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484].
If the PaC is a dual-stacked host, it can configure both IPv4 and If the PaC is a dual-stacked node, it can configure both IPv4 and
IPv6 type POPAs. IPv6 type POPAs.
The PaC with a PRPA and the PAA with IP address X can perform The PaC with a PRPA and the PAA with IP address X can perform
on-link communication as required by PANA. In IPv4, the PRPA and on-link communication as required by PANA. In IPv4, the PRPA and
IP address X have the same on-link prefix. In IPv6, the two IP address X have the same on-link prefix. In IPv6, the two
addresses are link-local addresses. When the PaC replaces its addresses are link-local addresses. When the PaC replaces its
IPv4 PRPA with an IPv4 POPA, the PaC and PAA SHOULD create host IPv4 PRPA with an IPv4 POPA, the PaC and PAA SHOULD create host
routes to each other, as they do not share the same on-link prefix routes to each other, when they do not share the same on-link
any more. This is needed for the PaC with the IPv4 POPA and the prefix any more. This is needed for the PaC with the IPv4 POPA
PAA with IP address X to continue on-link communication. In this and the PAA with IP address X to continue on-link communication.
case, the PaC SHOULD create a host route to IP address X, and the In this case, the PaC SHOULD create a host route to IP address X,
PAA SHOULD create a host route to the IPv4 POPA. PANA defines a and the PAA SHOULD create a host route to the IPv4 POPA. PANA
mechanism for the PaC to report the POPA to the PAA. defines a mechanism for the PaC to report the POPA to the PAA.
2. If the network uses IPsec for protecting the traffic on the link 2. If the network uses IPsec for protecting the traffic on the link
subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
would use the PRPA as the outer address of IPsec tunnel mode SA would use the PRPA as the outer address of IPsec tunnel mode SA
(IPsec-TOA). The PaC also needs to configure an inner address (IPsec-TOA). The PaC also needs to configure an inner address
(IPsec-TIA). There are different ways to configure an IPsec-TIA (IPsec-TIA). There are different ways to configure an IPsec-TIA
which are indicated in a PANA-Bind-Request message. which are indicated in a PANA-Bind-Request message.
When an IPv4 PRPA is configured, the same address may be used as When an IPv4 PRPA is configured, the same address may be used as
both IPsec-TOA and IPsec-TIA. In this case, a POPA is not both IPsec-TOA and IPsec-TIA. In this case, a POPA is not
  Skipping to change at page 16, line 41:
turn a session key into the required IPsec SA. The details of such a turn a session key into the required IPsec SA. The details of such a
mechanism is outside the scope of PANA protocol and is specified in mechanism is outside the scope of PANA protocol and is specified in
[I-D.ietf-pana-ipsec]. PANA provides bootstrapping functionality for [I-D.ietf-pana-ipsec]. PANA provides bootstrapping functionality for
such a mechanism by carrying EAP methods that can generate initial such a mechanism by carrying EAP methods that can generate initial
keying material. keying material.
Using network-layer ciphers should be regarded as a substitute for Using network-layer ciphers should be regarded as a substitute for
link-layer ciphers when the latter is not available. Network-layer link-layer ciphers when the latter is not available. Network-layer
ciphering can also be used in addition to link-layer ciphering if the ciphering can also be used in addition to link-layer ciphering if the
added benefits outweigh its cost to the user and the network. In added benefits outweigh its cost to the user and the network. In
this case, PANA bootstraps only the network-layer ciphering and this case, PANA bootstraps only the network-layer ciphering;
link-layer is protected using any of the existing link-layer specific link-layer ciphering is enabled using any of the existing link-layer
methods. specific methods.
7. PAA-EP Protocol 7. PAA-EP Protocol
The PANA protocol provides client authentication and authorization The PANA protocol provides client authentication and authorization
functionality for securing network access. The other component of a functionality for securing network access. The other component of a
complete solution is the access control which ensures that only complete solution is the access control which ensures that only
authenticated and authorized clients can gain access to the network. authenticated and authorized clients can gain access to the network.
PANA enables access control by distinguishing authenticated and PANA enables access control by distinguishing authenticated and
authorized clients from others and generating filtering information authorized clients from others and generating filtering information
for access control mechanisms. for access control mechanisms.
Access control can be achieved by placing EPs (Enforcement Points) in Access control can be achieved by placing EPs (Enforcement Points) in
the network for policing the traffic flow. EPs should prevent data the network for policing the traffic flow. EPs should prevent data
traffic from and to any unauthorized client unless it's either PANA traffic from and to any unauthorized client unless it's either PANA
or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
discovery, DHCP, etc.). discovery, DHCP, etc.).
When a PaC is authenticated and authorized, the PAA should notify When a PaC is authenticated and authorized, the PAA should notify
EP(s) and ask for installing filtering rules to allow the PaC to sent EP(s) and ask for installing filtering rules to allow the PaC to send
and receive data traffic. SNMP is used between PAA and EP(s) for and receive data traffic. SNMP is used between PAA and EP(s) for
this purpose when these entities are not co-located this purpose when these entities are not co-located
[I-D.ietf-pana-snmp]. [I-D.ietf-pana-snmp].
This section describes the possible models on the location of PAA and This section describes the possible models on the location of PAA and
EP, as well as the basic authorization information that needs to be EP, as well as the basic authorization information that needs to be
exchanged between PAA and EP. When PAA and EP are not co-located in exchanged between PAA and EP. When PAA and EP are not co-located in
a single device, there are other issues such as dead or rebooted peer a single device, there are other issues such as dead or rebooted peer
detection and consideration for specific authorization and accounting detection and consideration for specific authorization and accounting
models. However, these issues are closely related to the PAA-EP models. However, these issues are closely related to the PAA-EP
  Skipping to change at page 18, line 12:
This section describes all possible models on the placement of PAA(s) This section describes all possible models on the placement of PAA(s)
and EP(s). and EP(s).
7.1.1 Single PAA, Single EP, Co-located 7.1.1 Single PAA, Single EP, Co-located
This model corresponds to the legacy NAS model. Since the PAA and This model corresponds to the legacy NAS model. Since the PAA and
the EP are co-located, the PAA-EP communication can be implemented the EP are co-located, the PAA-EP communication can be implemented
locally by using, e.g., IPC (Inter-Process Communication). The only locally by using, e.g., IPC (Inter-Process Communication). The only
difference from the legacy NAS model is the case where there are difference from the legacy NAS model is the case where there are
multiple co-located PAA/EP devices on the same IP link and the PAA/EP multiple co-located PAA/EP devices on the same IP link and the PAA/EP
devices are L2 switches or access points. In this case, for a PaC devices are link-layer switches or access points. In this case, for
that attaches to a given PAA/EP device, other PAA/EP devices should a PaC that attaches to a given PAA/EP device, other PAA/EP devices
not be discovered by the PaC even if those devices are on the same IP should not be discovered by the PaC even if those devices are on the
link. Otherwise, the PaC may result in finding a PAA that is not the same IP link. Otherwise, the PaC may result in finding a PAA that is
closest one to it during the PANA discovery and initial handshake not the closest one to it during the PANA discovery and initial
phase and performing PANA with the PAA, which does not correspond to handshake phase and performing PANA with the PAA, which does not
the legacy NAS model. To prevent this, each PAA/EP device on an L2 correspond to the legacy NAS model. To prevent this, each PAA/EP
switch or access point should not forward multicast PANA discovery device on an link-layer switch or access point should not forward
message sent by PaCs attached to it to other devices. multicast PANA discovery message sent by PaCs attached to it to other
devices.
7.1.2 Separate PAA and EP 7.1.2 Separate PAA and EP
When PAA is separated from EP, two cases are possible with regard to When PAA is separated from EP, two cases are possible with regard to
whether PAA and EP are located in parallel or serial when viewed from whether PAA and EP are located in parallel or serial when viewed from
PaC, for each of models described in this section. PaC, for each of models described in this section.
In the first case, PAA is located behind EP. The EP should be In the first case, PAA is located behind EP. The EP should be
configured to always pass through PANA messages and address configured to always pass through PANA messages and address
configuration protocol messages used for configuring an IP address configuration protocol messages used for configuring an IP address
used for initial PANA messaging. This case can typically happen when used for initial PANA messaging. This case can typically happen when
the EP is an L2 switch or an access point (the EP also has an IP the EP is an link-layer switch or an access point (the EP also has an
stack to communicate with PAA via a PAA-EP protocol). IP stack to communicate with PAA via a PAA-EP protocol).
+---+ +---+ +---+ +---+ +---+ +---+
|PaC|--------|EP |--------|PAA| |PaC|--------|EP |--------|PAA|
+---+ +---+\ +---+ +---+ +---+\ +---+
\ \
+---- Internet +---- Internet
Figure 3: PAA and EP in Serial Figure 3: PAA and EP in Serial
In the other case, PAA is located in parallel to EP. Since the EP is In the other case, PAA is located in parallel to EP. Since the EP is
  Skipping to change at page 19, line 17:
/ +---+ / +---+
+---+/ +---+/
|PaC| |PaC|
+---+\ +---+\
\ +---+ \ +---+
+-----|EP |---- Internet +-----|EP |---- Internet
+---+ +---+
Figure 4: PAA and EP in Parallel Figure 4: PAA and EP in Parallel
In the remaining of this section, PaC is not shown in figures and the
figures cover both the serial and parallel models.
7.1.2.1 Single PAA, Single EP, Separated 7.1.2.1 Single PAA, Single EP, Separated
The model benefits from separation of data traffic handling and AAA. The model benefits from separation of data traffic handling and AAA.
The EP does not need to have a AAA protocol implementation which The EP does not need to have a AAA protocol implementation which
might be updated relatively more frequently than the per-packet might be updated relatively more frequently than the per-packet
access enforcement implementation. access enforcement implementation.
7.1.2.2 Single PAA, Multiple EPs 7.1.2.2 Single PAA, Multiple EPs
In this model, a single PAA controls multiple EPs. The PAA may be In this model, a single PAA controls multiple EPs. The PAA may be
separated from any EP or co-located with a particular EP. This model separated from any EP or co-located with a particular EP. This model
might be useful where it is preferable to run a AAA protocol at a might be useful where it is preferable to run a AAA protocol at a
single, manageable point. This model is particularly useful in an single, manageable point. This model is particularly useful in an
access network that consists of a large number of access points on access network that consists of a large number of access points on
which per-packet access enforcement is made. When a PaC is which per-packet access enforcement is made. When a PaC is
authenticated to the PAA, the PAA should install access control authenticated to the PAA, the PAA should install access control
filters to each of the EPs under control of the PAA if the PAA cannot filters on each of the EPs under control of the PAA if the PAA cannot
tell which EP the PaC is attached to. Even if the PAA can tell which tell which EP the PaC is attached to. Even if the PAA can tell which
EP the PaC is attached to, the PAA may install access control filters EP the PaC is attached to, the PAA may install access control filters
to those EPs if the PaC is a mobile device that can roam among the to those EPs if the PaC is a mobile device that can roam among the
EPs. Such pre-installation of filters can reduce handoff latency. EPs. Such pre-installation of filters can reduce handoff latency.
If different access authorization policies are applied to different If different access authorization policies are applied to different
EPs, different filter rules for a PaC may be installed on different EPs, different filter rules for a PaC may be installed on different
EPs. EPs.
+---+ +---+
|EP |--+ |EP |--+
+---+ \ +---+ \
\ \
+---+ +---+ +---+ +---+ +---+
|EP |----|PAA| |PaC| |EP |----|PAA|
+---+ +---+ +---+ +---+ +---+
/ /
+---+ / +---+ /
|EP |--+ |EP |--+
+---+ +---+
Figure 5: An example model for a single PAA and multiple EPs Figure 5: An example model for a single PAA and multiple EPs
7.1.2.3 Multiple PAAs 7.1.2.3 Multiple PAAs
The PANA protocol allows multiple PAAs to exist on the same IP link The PANA protocol allows multiple PAAs to exist on the same IP link
and to be visible to PaCs on the link. PAAs may or may not be and to be visible to PaCs on the link. PAAs may or may not be
co-located with EPs as long as authorization results do not depend on co-located with EPs [I-D.ietf-pana-pana].
whichever PAAs are chosen by a PaC [I-D.ietf-pana-pana].
7.2 Notification of PaC Presence 7.2 Notification of PaC Presence
When PAA and EP are separated and PAA is configured to be the When PAA and EP are separated and PAA is configured to be the
initiator of the discovery and initial handshake phase of PANA, EP initiator of the discovery and initial handshake phase of PANA, EP
has the responsibility to detect presence of a new PaC and notifies has the responsibility to detect presence of a new PaC and notifies
the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a
presence notification is carried in a PAA-EP protocol message presence notification is carried in a PAA-EP protocol message
[I-D.ietf-pana-snmp]. [I-D.ietf-pana-snmp].
  Skipping to change at page 21, line 10:
control and security reasons in general. In addition to the device control and security reasons in general. In addition to the device
identifier and keying material, other filter rules, such as the IP identifier and keying material, other filter rules, such as the IP
filter rules specified in NAS-Filter-Rule AVPs carried in Diameter filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
EAP application [I-D.ietf-aaa-eap] may be installed on EP. EAP application [I-D.ietf-aaa-eap] may be installed on EP.
8. Network Selection 8. Network Selection
The network selection problem statement is made in The network selection problem statement is made in
[I-D.ietf-eap-netsel-problem]. The PANA protocol [I-D.ietf-eap-netsel-problem]. The PANA protocol
[I-D.ietf-pana-pana] provides a way for networks to advertise which [I-D.ietf-pana-pana] provides a way for networks to advertise which
ISPs are available and for PaC to choose one ISP from the advertised ISPs are available and for a PaC to choose one ISP from the
information. When a PaC chooses an ISP in the PANA protocol advertised information. When the PaC chooses an ISP in the PANA
exchange, the ultimate destination of the AAA exchange is determined protocol exchange, the ultimate destination of the AAA exchange is
based on the identity of the chosen service provider. It is also determined based on the identity of the chosen service provider. It
possible that the PaC does not choose a specific ISP in the PANA is also possible that the PaC does not choose a specific ISP in the
protocol exchange. In this case, both the ISP choice and the AAA PANA protocol exchange. In this case, both the ISP choice and the
destination are determined based on the PaC's identity, where the AAA destination are determined based on the PaC's identity, where the
identity may be an NAI [RFC2486] or the physical port number or L2 identifier may be an NAI [RFC2486] or the physical port number or
address of the subscriber. link-layer address of the subscriber.
As described in [I-D.ietf-eap-netsel-problem], network selection is As described in [I-D.ietf-eap-netsel-problem], network selection is
not only related to AAA routing but also related to payload routing. not only related to AAA routing but also related to payload routing.
Once an ISP is chosen and the PaC is successfully authenticated and Once an ISP is chosen and the PaC is successfully authenticated and
authorized, PaC is assigned an address by the ISP whose IP prefix may authorized, the PaC is assigned an address by the ISP.
be different from that of the AR. This affects the routing of the
subsequent data traffic between AR and PaC. A suggested solution is
to add host route from AR to PaC's POPA address and host route from
PaC to AR.
Consider a typical DSL network where the AR, EP, and PAA are Consider a typical DSL network where the AR (access router), EP, and
co-located on a BAS (Broadband Access Server) in the access network PAA are co-located on a BAS (Broadband Access Server) in the access
operated by a NAP (Network Access Provider). Figure 6 shows a network operated by a NAP (Network Access Provider). Figure 6 shows
typical model for ISP selection. a typical model for ISP selection.
<---- NAP ----><--------- ISP ---------> <---- NAP ----><--------- ISP --------->
+---ISP1 +---ISP1
/ /
+---+ +---------+/ +---+ +---------+/
|PaC|----|AR/EP/PAA| |PaC|----|AR/EP/PAA|
+---+ +---------+\ +---+ +---------+\
BAS \ BAS \
+---ISP2 +---ISP2
Figure 6: A Network Selection Model Figure 6: A Network Selection Model
When network selection is made at L3 with the use of the PANA When network selection is made at network-layer with the use of the
protocol instead of L2-specific authentication mechanisms, the IP PANA protocol instead of link-layer specific authentication
link between PaC and PAA needs to exist prior to doing PANA (and mechanisms, the IP link between the PaC and PAA needs to exist prior
prior to network selection). In this model, the PRPA is either given to doing PANA (and prior to network selection). In this model, the
by NAP or a link-local address is auto-configured. After the PRPA is either given by the NAP or a link-local address is
successful authentication with the ISP, PaC may acquire an address auto-configured. After the successful authentication with the ISP,
(POPA) from the ISP. It also learns the address of the AR, e.g., the PaC may acquire an address (POPA) from the ISP. It also learns
through DHCP, to be used as its default router. The address of the the address of the access router (AR), e.g., through DHCP, to be used
AR may or may not be in the same IP subnet as that of the PaC's POPA. as its default router. The address of the AR may or may not be in
If they don't share the same prefix, they SHOULD use host routes to the same IP subnet as that of the PaC's POPA. If they don't share
reach each other. Note that the physically secured DSL networks do the same prefix, they SHOULD use host routes to reach each other.
not require IPsec-based access control. Therefore the PaCs use one
IP address at a time where POPA replaces PRPA upon configuration. Note that the physically secured DSL networks do not require
IPsec-based access control. Therefore the PaC uses one IP address at
a time where the POPA replaces the PRPA upon configuration.
9. Authentication Method Choice 9. Authentication Method Choice
Authentication methods' capabilities and therefore applicability to Authentication methods' capabilities and therefore applicability to
various environments differ among them. Not all methods provide various environments differ among them. Not all methods provide
support for mutual authentication, key derivation or distribution, support for mutual authentication, key derivation or distribution,
and DoS attack resiliency that are necessary for operating in and DoS attack resiliency that are necessary for operating in
insecure networks. Such networks might be susceptible to insecure networks. Such networks might be susceptible to
eavesdropping and spoofing, therefore a stronger authentication eavesdropping and spoofing, therefore a stronger authentication
method needs to be used to prevent attacks on the client and the method needs to be used to prevent attacks on the client and the
  Skipping to change at page 24, line 17:
10.1 DSL Access Network 10.1 DSL Access Network
In a DSL access network, PANA is seen applicable in the following In a DSL access network, PANA is seen applicable in the following
scenarios. scenarios.
A typical DSL access consists of a NAS device at the DSL-access A typical DSL access consists of a NAS device at the DSL-access
provider and a DSL-modem (CPE) at the customer premises. The CPE provider and a DSL-modem (CPE) at the customer premises. The CPE
devices support multiple modes of operation and PANA is applicable in devices support multiple modes of operation and PANA is applicable in
each of these modes. each of these modes.
In the current DSL deployment, a DSLAM (DSL Access Multiplexor) which
is placed between the CPE and NAS is a transparent device from PANA
perspective. In a future DSL model, the PAA may reside in the DSLAM
which may directly connect ISP routers through VLANs.
Host--+ +-------- ISP1 Host--+ +-------- ISP1
| DSL link | | DSL link |
+----- CPE ---------------- NAS ----+-------- ISP2 +----- CPE ----- DSLAM ----- NAS ----+-------- ISP2
| (Bridge/NAPT/Router) | | (Bridge/ |
Host--+ +-------- ISP3 Host--+ NAPT/Router) +-------- ISP3jG
<------- customer --> <------- NAP -----> <---- ISP ---> <------- customer --> <------- NAP -----> <---- ISP --->
premise premise
Figure 7: DSL Model Figure 7: DSL Model
The devices at the customer premises have been shown as "hosts" in The devices at the customer premises have been shown as "hosts" in
the above network. the above network.
DSL networks are protected by physical means. Eavesdropping and DSL networks are protected by physical means. Eavesdropping and
spoofing attacks are prevented by keeping the unintended users spoofing attacks are prevented by keeping the unintended users
physically away from the network media. Therefore, generally physically away from the network media. Therefore, generally
cryptographic protection of data traffic is not necessary. cryptographic protection of data traffic is not necessary.
Nevertheless, if enhanced security is deemed necessary for any Nevertheless, if enhanced security is deemed necessary for any
reason, IPsec-based access control can be enabled on DSL networks as reason, IPsec-based access control can be enabled on DSL networks as
well by using the method described in [I-D.ietf-pana-ipsec]. well by using the method described in [I-D.ietf-pana-ipsec].
10.1.1 Bridging Mode 10.1.1 Bridging Mode
In the bridging mode, the CPE acts as a simple layer-2 bridge. The In the bridging mode, the CPE acts as a simple link-layer bridge.
hosts at the customer premises will function as clients to obtain The hosts at the customer premises will function as clients to obtain
addresses from the NAS device by using DHCP or PPPoE. addresses from the NAS device by using DHCP or PPPoE.
If PPPoE is used, authentication is typically performed using CHAP or If PPPoE is used, authentication is typically performed using CHAP or
MS-CHAP. MS-CHAP.
PANA will be applicable when the hosts use DHCP to obtain IP address. PANA will be applicable when the hosts use DHCP to obtain IP address.
DHCP does not support authentication of the devices on either side of DHCP does not support authentication of the devices on either side of
the DSL access line. In the simplest method of address assignment, the DSL access line. In the simplest method of address assignment,
the NAS will allocate the IP address to a host with a lease time the NAS will allocate the IP address to a host with a lease time
reasonably sufficient to complete a full PANA based authentication reasonably sufficient to complete a full PANA based authentication
which will be triggered immediately after the address assignment. which will be triggered immediately after the address assignment.
The hosts will perform the PaC function and the NAS will perform the The hosts will perform the PaC function and the NAS will perform the
PAA, EP and AR functions. PAA, EP and AR functions.
Host--+ Host--+
(PaC) | (PaC) |
+----- CPE ---------------- NAS ------------- ISP +----- CPE ----- DSLAM ----- NAS ------------- ISP
| (Bridge) (PAA,EP,AR) | (Bridge) (PAA,EP,AR)
Host--+ Host--+
(PaC) (PaC)
Figure 8: Bridge Mode Figure 8: Bridge Mode
The DSL service provider's trunk network should not be accessible to The DSL service provider's trunk network should not be accessible to
any host that has not successfully completed the PANA authentication any host that has not successfully completed the PANA authentication
phase. phase.
  Skipping to change at page 25, line 33:
In this mode, the CPE acts as a router for the customer premises In this mode, the CPE acts as a router for the customer premises
network. The CPE itself may obtain the IP address using DHCP or be network. The CPE itself may obtain the IP address using DHCP or be
configured with a static IP address. Once the CPE is authenticated configured with a static IP address. Once the CPE is authenticated
using PANA and is provided access to the service provider's network, using PANA and is provided access to the service provider's network,
the NAS should begin exchanging routing updates with the CPE. All the NAS should begin exchanging routing updates with the CPE. All
devices at the customer premises will then have access to the service devices at the customer premises will then have access to the service
provider's network. provider's network.
Host--+ Host--+
| |
+----- CPE ---------------- NAS ------------- ISP +----- CPE ----- DSLAM ----- NAS ------------- ISP
| (Router, PaC) (PAA,EP,AR) | (Router, PaC) (PAA,EP,AR)
Host--+ Host--+
Figure 9: Router Mode Figure 9: Router Mode
It is possible that both ends of the DSL link are configured with It is possible that both ends of the DSL link are configured with
static IP addresses. PANA-based mutual authentication of CPE and NAS static IP addresses. PANA-based mutual authentication of CPE and NAS
is desirable before data-traffic is exchanged between the customer is desirable before data traffic is exchanged between the customer
premises network and the service provider network. The CPE router premises network and the service provider network. The CPE router
may also use NAPT (Network Address Port Tranlation). may also use NAPT (Network Address Port Tranlation).
10.1.3 PANA and Dynamic Internet Service Provider Selection 10.1.3 PANA and Dynamic ISP Selection
In some installations, a NAS device is shared by multiple service In some installations, a NAS device is shared by multiple service
providers. Each service provider configures the NAS with a certain providers. Each service provider configures the NAS with a certain
IP address space. IP address space.
The devices at the customer premises network indicate their choice of The devices at the customer premises network indicate their choice of
service provider and the NAS chooses the IP address from the service provider and the NAS chooses the IP address from the
appropriate service provider's pool. In many cases, the address is appropriate service provider's pool. In many cases, the address is
assigned not by the NAS but by the AAA server that is managed fully assigned not by the NAS but by the AAA server that is managed fully
by the service provider. by the service provider.
  Skipping to change at page 26, line 48:
temporary IP address (PRPA) prior to PANA authentication. This IP temporary IP address (PRPA) prior to PANA authentication. This IP
address might be obtained via DHCP with a lease reasonably long to address might be obtained via DHCP with a lease reasonably long to
complete PANA authentication, or via the zeroconf technique complete PANA authentication, or via the zeroconf technique
[I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA
authentication signalling prompts the client to obtain a new (long authentication signalling prompts the client to obtain a new (long
term) IP address via DHCP. This new IP address (POPA) replaces the term) IP address via DHCP. This new IP address (POPA) replaces the
previously allocated temporary IP address. previously allocated temporary IP address.
10.2 Wireless LAN Example 10.2 Wireless LAN Example
This section describes how PANA can be used on WLAN networks. In This section describes how PANA can be used on WLANs. In most common
most common WLAN deployments the IP addresses are dynamically WLAN deployments the IP addresses are dynamically configured.
configured. Therefore this section does not cover the scenarios Therefore this section does not cover the scenarios where the IP
where the IP address is statically configured. There are two models address is statically configured. There are two models depending on
depending on which layer security is bootstrapped from PANA which layer security is bootstrapped from PANA authentication,
authentication, L2 or L3. When PANA authentication is used for link-layer or IP-layer. When PANA authentication is used for
bootstrapping L3 security, L2 security is not necessarily to exist bootstrapping IP-layer security, link-layer security is not
even after PANA authentication. Instead, IPsec-based data traffic necessarily to exist even after PANA authentication. Instead,
protection is bootstrapped from PANA. The PAA can indicate the PaC IPsec-based data traffic protection is bootstrapped from PANA. The
as to whether L2 or L3 protection is needed, by including a PAA can indicate the PaC as to whether link-layer or IP-layer
Protection-Capability AVP in PANA-Bind-Request message. In both protection is needed, by including a Protection-Capability AVP in
cases, the most common deployment would be illustrated in Figure 10, PANA-Bind-Request message. In both cases, the most common deployment
where EP is typically co-located with AP (access point) when PANA is would be illustrated in Figure 10, where EP is typically co-located
used for bootstrapping L2 security or with AR when PANA is used for with AP (access point) when PANA is used for bootstrapping link-layer
bootstrapping L3 security. security or with AR when PANA is used for bootstrapping IP-layer
security.
+-----+ +-----+
|AP/EP|----+ |AP/EP|----+
+-----+ | +-----+ |
| |
+---+ +-----+ | +---------+ +---+ +-----+ | +---------+
|PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet
+---+ +-----+ | +---------+ +---+ +-----+ | +---------+
| |
+-----+ | +-----+ |
|AP/EP|----+ |AP/EP|----+
+-----+ +-----+
Figure 10: PANA Wireless LAN Model Figure 10: PANA Wireless LAN Model
10.2.1 PANA with Bootstrapping IPsec 10.2.1 PANA with Bootstrapping IPsec
In this model, data traffic is protected by using IPsec tunnel mode In this model, data traffic is protected by using IPsec tunnel mode
SA and an IP address is used as the device identifier of PaC (see SA and an IP address is used as the device identifier of the PaC (see
Section 5 for details). Some or all of AP, DHCPv4 Server (including Section 5 for details). Some or all of AP, DHCPv4 Server (including
PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA
and EP may be co-located in a single device. EP is always co-located and EP may be co-located in a single device. EP is always co-located
with AR and may be co-located with PAA. When EP and PAA are not with AR and may be co-located with PAA. When EP and PAA are not
co-located, PAA-EP protocol is used for communication between PAA and co-located, PAA-EP protocol is used for communication between PAA and
EP. EP.
Note that for all of the cases described in this section, PBR Note that for all of the cases described in this section, a PBR
(PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA
[I-D.ietf-pana-pana] should occur after installing the authorization [I-D.ietf-pana-pana] should occur after installing the authorization
parameter to AR, so that IKE can be performed immediately after PANA parameter to the AR, so that IKE can be performed immediately after
is successfully completed. the PANA authentication is successfully completed. The PAA can
obtain the required device identifer (i.e., the IPsec-TOA in this
case) to be installed on the AR from the IP header of a PANA message
sent by the PaC before sending the PBR. However, when the PBR/PBA
exchange fails, the authorization parameters already installed on the
AR must be immediately revoked to avoid unauthorized access.
10.2.1.1 IPv4 10.2.1.1 IPv4
Case A: IPsec-TIA obtained by using DHCPv4 Case A: IPsec-TIA obtained by using DHCPv4
In this case, the IPsec-TIA and IPsec-TOA are the same as the In this case, the IPsec-TIA and IPsec-TOA are the same as the
PRPA, and all configuration information including the IP address PRPA, and all configuration information including the IP address
is obtained by using DHCPv4 [RFC2131]. No POPA is configured. is obtained by using DHCPv4 [RFC2131]. No POPA is configured.
Case A is the simplest compared to other ones and might be used in Case A is the simplest compared to other ones and might be used in
a network where IP address depletion attack on DHCP is not a a network where IP address depletion attack on DHCP is not a
significant concern. The PRPA needs to be a routable address significant concern. The PRPA needs to be a routable address
unless NAT is performed on AR. unless NAT is performed on AR.
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv4 | | | | DHCPv4 | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in Authentication phase) | | & PAR/PAN exchange in authentication |
| and authorization phase) | |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | | |Authorization| | | |Authorization|
| | | |[IKE-PSK, | | | |[IKE-PSK, |
| | | | PaC-DI, | | | | PaC-DI, |
| | | | Session-Id] | | | | Session-Id] |
| | | |------------>| | | |------------>|
| | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | |
| | | | |
Figure 11: An example case for configuring IPsec-TIA by using Figure 11: An example case for configuring IPsec-TIA by using
DHCPv4 DHCPv4
Case B: IPsec-TIA obtained by using IKE Case B: IPsec-TIA obtained by using IKE
In this case, the PRPA is obtained by using DHCPv4 and used as In this case, the PRPA is obtained by using DHCPv4 and used as the
IPsec-TOA. The POPA is obtained by using IKE (via a Configuration IPsec-TOA. The POPA is obtained by using IKE (via a Configuration
Payload exchange or equivalent) and used as IPsec-TIA. Payload exchange or equivalent) and used as the IPsec-TIA. An
example sequence for Case B is shown in Figure 12.
Case C: IPsec-TIA obtained by using RFC3456 Case C: IPsec-TIA obtained by using RFC3456
Like Case B, the PRPA is obtained by using DHCPv4. The difference Like Case B, the PRPA is obtained by using DHCPv4. The difference
is that the POPA (eventually used as IPsec-TIA) and other is that the POPA (eventually used as IPsec-TIA) and other
configuration parameter are configured by running DHCPv4 over a configuration parameter are configured by running DHCPv4 over a
special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4 special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4
Server and IPsec-TIA DHCPv4 Server may be co-located on the same Server and IPsec-TIA DHCPv4 Server may be co-located on the same
node. node.
  Skipping to change at page 30, line 17:
equivalent case). equivalent case).
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv4 | | | | DHCPv4 | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | | | | | | | |
|PANA(Discovery and initial handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in authentication phase) | | & PAR/PAN exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| | |Authorization| | | |Authorization|
| | |[IKE-PSK, | | | |[IKE-PSK, |
| | | PaC-DI, | | | | PaC-DI, |
| | | Session-Id] | | | | Session-Id] |
| | |------------>| | | |------------>|
| | | | | | | |
|PANA(PBR-PBA exchange in authentication phase) | |PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | |
| | IKE | | | | IKE |
| (with Configuration Payload exchange or equivalent) | | (with Configuration Payload exchange) |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
| | | | | | | |
Figure 12: An example case for IPsec-TIA obtained by using IKE Figure 12: An example case for IPsec-TIA obtained by using IKE
PRPA
PaC AP DHCPv4 Server PAA PaC AP DHCPv4 Server PAA
| Link-layer | | | | Link-layer | | |
| association| | | | association| | |
|<---------->| | | |<---------->| | |
| | | | | | | |
| DHCPv4 | | | DHCPv4 | |
|<-----------+-------->| | |<-----------+-------->| |
| | | | | |
|PANA(Discovery and initial handshake phase |PANA(Discovery and handshake phase |
| & PAR-PAN exchange in authentication phase) | & PAR/PAN exchange in |
| authentication and authorization phase)
|<-----------+-------------------------->| |<-----------+-------------------------->|
| | | | | |
| | EP(AR) | | | | EP(AR)
| | |Authorization| | | | |Authorization
| | |[IKE-PSK, | | | | |[IKE-PSK,
| | | PaC-DI, | | | | | PaC-DI,
| | | Session-Id] | | | | | Session-Id]
| | |<------------| | | |------------->|
| | | |
|PANA(PBR/PBA exchange in authentication | |
| and authorization phase) | |
|<-----------+-------------------------->| |
| | | | | | | |
|PANA(PBR-PBA exchange in authentication phase)
|<-----------+-------------------------->|
| | |
| IKEv1 phase I & II | | IKEv1 phase I & II |
| (to create DHCP SA) | | (to create DHCP SA) |
|<-----------+------------>| |<-----------+----------------------------------------->|
| | | | | |
| DHCP over DHCP SA | | DHCP over DHCP SA |
|<-----------+------------>| |<-----------+----------------------------------------->|
| | | | | |
| IKEv1 phase II | | IKEv1 phase II |
| (to create IPsec SA for data traffic) | (to create IPsec SA for data traffic) |
|<-----------+------------>| |<-----------+----------------------------------------->|
Figure 13: An example case for configuring IPsec-TIA by using Figure 13: An example case for configuring IPsec-TIA by using
RFC3456 RFC3456
10.2.1.2 IPv6 10.2.1.2 IPv6
In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local
address. IPsec-TIA (POPA) is obtained by using Configuration Payload address. IPsec-TIA (POPA) is obtained by using IKE (via a
exchange of IKE version 2 (Note that there is no standard method for Configuration Payload exchange or equivalent). Other configuration
configuring IPsec-TIA in IKEv1). Other configuration information may information may be obtained in the same Configuration Payload
be obtained in the same Configuration Payload exchange or may be exchange or may be obtained by running an additional DHCPv6.
obtained by running an additional DHCPv6.
PaC AP EP(AR) PAA PaC AP PAA EP(AR)
| Link-layer | | | | Link-layer | | |
| association| | | | association| | |
|<---------->| | | |<---------->| | |
| | | | | | | |
| | | | | | | |
|PANA(Discovery and Initial Handshake phase |PANA(Discovery and handshake phase |
| & PAR-PAN exchange in Authentication phase) | & PAR/PAN exchange in |
|<-----------+-------------------------->| | authentication and authorization phase)
|<-----------+------------>| |
| | | | | | | |
| | | | | | | |
| | |Authorization| | | |Authorization|
| | |[IKE-PSK, | | | |[IKE-PSK, |
| | | PaC-DI, | | | | PaC-DI, |
| | | Session-Id] | | | | Session-Id] |
| | |<------------| | | |------------>|
| | | |
|PANA(PBR-PBA exchange in authentication phase)
|<-----------+-------------------------->|
| | | | | | | |
| IKEv2 | | |PANA(PBR/PBA exchange in | |
|(w/Configuration Payload | | | authentication and authorization phase)
| exchange to obtain IPsec-TIA) |
|<-----------+------------>| | |<-----------+------------>| |
| | |
| IKEv2 |
| (with Configuration Payload exchange) |
|<-----------+-------------------------->|
| | | | | | | |
Figure 14: An example sequence for configuring IPsec-TIA in IPv6 Figure 14: An example sequence for configuring IPsec-TIA in IPv6
10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i
In this model, PANA is used for authentication and authorization, and In this model, PANA is used for authentication and authorization, and
L2 ciphering is used for access control, the latter is enabled by the link-layer ciphering is used for access control. Successful PANA
former. The L2 ciphering is based on using PSK (Pre-Shared Key) mode authentication enables link-layer ciphering which is based on PSK
of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i], (Pre-Shared Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE
which is derived from the EAP MSK as a result of successful PANA 802.11i [802.11i]. In this document, the key shared between a
authentication. In this document, the pre-shared key shared between station and an AP is referred to as the PMK (Pair-wise Master Key).
station and AP is referred to as PMK (Pair-wise Master Key). In this The PMK is derived from the EAP AAA-Key as a result of successful
model, MAC address is used as the device identifier in PANA. PANA authentication. In this model, MAC addresses are used as the
device identifiers in PANA.
This model allows the separation of PAA from APs (EPs). A typical This model allows the separation of PAA from EPs(APs). A typical
purpose of using this model is to reduce AP management cost by purpose of using this model is to reduce AP management cost by
allowing physical separation of RADIUS/Diameter client from access allowing physical separation of RADIUS/Diameter client from access
points, where AP management can be a significant issue when deploying points, where AP management can be a significant issue when deploying
a large number of access points. a large number of access points. Additionally, this centralized AAA
framework enhances mobility-related performance (inter-AP but
intra-PAA mobility does not require additional PANA executions).
By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is
also possible to improve wireless LAN security by providing protected also possible to improve wireless LAN security by providing protected
disconnection procedure at L3. disconnection procedure at L3.
This model does not require any change in the current WPA and IEEE This model does not require any change in the current WPA and IEEE
802.11i specifications. This also means that PANA doesn't provide 802.11i specifications. This also means that PANA doesn't provide
any L2 security features beyond those already provided for in WPA and any link-layer security features beyond those already provided for in
IEEE 802.11i. WPA and IEEE 802.11i.
The IEEE 802.11 specification [802.11] allows Class 1 data frames to The IEEE 802.11 specification [802.11] allows Class 1 data frames to
be received in any state. Also, the latest version of IEEE 802.11i be received in any state. Also, IEEE 802.11i [802.11i] optionally
[802.11i] optionally allows higher-layer data traffic to be received allows higher-layer data traffic to be received and processed on the
and processed on their IEEE 802.1X Uncontrolled Ports. This feature IEEE 802.1X Uncontrolled Ports. This feature allows processing
allows processing IP-based traffic (such as ARP, IPv6 neighbor IP-based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and
discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to PANA) on IEEE 802.1X Uncontrolled Port prior to client
client authentication. (Note: WPA does not explicitly define this authentication.
operation, so it may be safer not to use this in WPA).
Until the PaC is successfully authenticated, only a selected type of Until the PaC is successfully authenticated, only a selected type of
IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any
other IP traffic is dropped on the AP without being forwarded to the other IP traffic is dropped at the AP without being forwarded to the
DS (Distribution System). Upon successful PANA authentication, the DS (Distribution System). Upon successful PANA authentication, the
traffic switches to the controlled port. Host configuration, traffic switches to the controlled port. Host configuration,
including obtaining an (potentially new) IP address, takes place on including obtaining an (potentially new) IP address, takes place on
this port. Usual DHCP-based, and also in the case of IPv6 stateless this port. Usual DHCP-based, and also in the case of IPv6 stateless
autoconfiguration, mechanism is available to the PaC. After this autoconfiguration, mechanism is available to the PaC. After this
point, the rest of the IP traffic, including PANA exchanges, are point, the rest of the IP traffic, including PANA exchanges, are
processed on the controlled port. processed on the controlled port.
When a PaC does not have a PMK for the AP, the following procedure is When a PaC does not have a PMK for the AP, the following procedure is
taken: taken:
1. The PaC associates with the AP. 1. The PaC associates with the AP.
2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or
configures a link-local address (in the case of IPv6), and then configures a link-local address (in the case of IPv6), and then
runs PANA by using the address. runs PANA.
3. Upon successful authentication, the PaC obtains a PMK for each AP 3. Upon successful authentication, the PaC obtains a separate PMK
controlled by the PAA. for each AP controlled by the PAA.
4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK
(Pair-wise Transient Key) with the PaC, by using the PMK. (Pair-wise Transient Key) with the PaC, by using the PMK.
5. The PaC obtains a POPA by using any method that the client 5. The PaC obtains a POPA by using any method that the client
normally uses. normally uses.
10.2.3 Capability Discovery 10.2.3 Capability Discovery
When a PaC is a mobile, there may be multiple APs available in its When a PaC is a mobile, there may be multiple APs available in its
  Skipping to change at page 35, line 7:
discovery. A type (b) network would send a PANA-Start-Request to the discovery. A type (b) network would send a PANA-Start-Request to the
client and block general purpose data traffic. This helps the client client and block general purpose data traffic. This helps the client
discover whether the network is type (a) or type (b). Or if the PaC discover whether the network is type (a) or type (b). Or if the PaC
is pre-provisioned with the information that this is a PANA enabled is pre-provisioned with the information that this is a PANA enabled
network, it can attempt PAA discovery immediately. The PaC behavior network, it can attempt PAA discovery immediately. The PaC behavior
after connecting to an AP of type (b) network is described in Section after connecting to an AP of type (b) network is described in Section
10.2, Section 10.2.1 and Section 10.2.2. 10.2, Section 10.2.1 and Section 10.2.2.
11. Acknowledgments 11. Acknowledgments
We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner We would like to thank Bernard Aboba, Yacine El Mghazli, Randy
and Hannes Tschofenig for their valuable comments. Turner, Hannes Tschofenig and Lionel Morand for their valuable
comments.
12. References 12. References
12.1 Normative References 12.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
  Skipping to change at page 36, line 36:
1998. 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-15 (work in progress), August 2004. draft-ietf-ipsec-ikev2-17 (work in progress), October
2004.
[I-D.ietf-pana-snmp] [I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-01 (work in PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in
progress), July 2004. progress), October 2004.
[I-D.ietf-pana-pana] [I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-05 (work in Access (PANA)", draft-ietf-pana-pana-06 (work in
progress), July 2004. progress), October 2004.
[I-D.ietf-pana-ipsec] [I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-04 (work in progress), Control", draft-ietf-pana-ipsec-05 (work in progress),
September 2004. December 2004.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of Host Configuration Protocol (DHCPv4) Configuration of
  Skipping to change at page 37, line 35:
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[I-D.ietf-eap-netsel-problem] [I-D.ietf-eap-netsel-problem]
Arkko, J. and B. Aboba, "Network Discovery and Selection Arkko, J. and B. Aboba, "Network Discovery and Selection
Problem", draft-ietf-eap-netsel-problem-01 (work in Problem", draft-ietf-eap-netsel-problem-02 (work in
progress), July 2004. progress), October 2004.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. RFC 2486, January 1999.
[I-D.ietf-pana-requirements] [I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements", Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-09 (work in progress), August draft-ietf-pana-requirements-09 (work in progress), August
2004. 2004.
[I-D.ietf-aaa-eap] [I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-09 (work in progress), August 2004. draft-ietf-aaa-eap-10 (work in progress), November 2004.
[I-D.yegin-eap-boot-rfc3118] [I-D.yegin-eap-boot-rfc3118]
Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping
RFC3118 Delayed DHCP Authentication Using EAP-based RFC3118 Delayed DHCP Authentication Using EAP-based
Network Access Authentication", Network Access Authentication",
draft-yegin-eap-boot-rfc3118-00 (work in progress), draft-yegin-eap-boot-rfc3118-00 (work in progress),
February 2004. February 2004.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[I-D.josefsson-pppext-eap-tls-eap] [I-D.josefsson-pppext-eap-tls-eap]
Josefsson, S., Palekar, A., Simon, D. and G. Zorn, Josefsson, S., Palekar, A., Simon, D. and G. Zorn,
"Protected EAP Protocol (PEAP) Version 2", "Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-08 (work in progress), draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
July 2004. October 2004.
[I-D.ietf-pppext-eap-ttls] [I-D.ietf-pppext-eap-ttls]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", Authentication Protocol (EAP-TTLS)",
draft-ietf-pppext-eap-ttls-05 (work in progress), July draft-ietf-pppext-eap-ttls-05 (work in progress), July
2004. 2004.
[I-D.tschofenig-eap-ikev2] [I-D.tschofenig-eap-ikev2]
Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method
(EAP-IKEv2)", draft-tschofenig-eap-ikev2-04 (work in (EAP-IKEv2)", draft-tschofenig-eap-ikev2-05 (work in
progress), July 2004. progress), October 2004.
[DSL] DSL Forum Architecture and Transport Working Group, "DSL [DSL] DSL Forum Architecture and Transport Working Group, "DSL
Forum TR-058 Multi-Service Architecture and Framework Forum TR-058 Multi-Service Architecture and Framework
Requirements", September 2003. Requirements", September 2003.
[802.11i] Institute of Electrical and Electronics Engineers, "Draft [802.11i] Institute of Electrical and Electronics Engineers, "Draft
supplement to standard for telecommunications and supplement to standard for telecommunications and
information exchange between systems - lan/man specific information exchange between systems - lan/man specific
requirements - part 11: Wireless medium access control requirements - part 11: Wireless medium access control
(mac) and physical layer (phy) specifications: (mac) and physical layer (phy) specifications:
  Skipping to change at page 38, line 51:
[802.11] Institute of Electrical and Electronics Engineers, [802.11] Institute of Electrical and Electronics Engineers,
"Information technology - telecommunications and "Information technology - telecommunications and
information exchange between systems - local and information exchange between systems - local and
metropolitan area networks - specific requirements part metropolitan area networks - specific requirements part
11: Wireless lan medium access control (mac) and physical 11: Wireless lan medium access control (mac) and physical
layer (phy) specifications", IEEE Standard 802.11, layer (phy) specifications", IEEE Standard 802.11,
1999(R2003). 1999(R2003).
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi
WPA v2.0, 2003. WPA v3.1, 2004.
Authors' Addresses Authors' Addresses
Prakash Jayaraman Prakash Jayaraman
Network Equipment Technologies, Inc. Network Equipment Technologies, Inc.
6900 Paseo Padre Parkway 6900 Paseo Padre Parkway
Fremont, CA 94555 Fremont, CA 94555
USA USA
Phone: +1 510 574 2305 Phone: +1 510 574 2305
  Skipping to change at page 40, line 17:
This section describes other possible cases for PANA with This section describes other possible cases for PANA with
Bootstrapping IPsec in wireless LAN environments. Bootstrapping IPsec in wireless LAN environments.
Appendix A.1 IPv4 Appendix A.1 IPv4
Case D: IPsec-TIA obtained by using RFC3118 Case D: IPsec-TIA obtained by using RFC3118
In this case, the POPA is configured and used as both IPsec-TIA In this case, the POPA is configured and used as both IPsec-TIA
and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118 and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118
(authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK (authenticated DHCP) [RFC3118] before running IKE. The PaC
needed for authenticated DHCP is distributed from the PAA to the unconfigures the PRPA immediately after the IPsec-TIA is obtained.
POPA DHCPv4 server by using the method specified in The DHCP-PSK needed for authenticated DHCP is distributed from the
PAA to the POPA DHCPv4 server by using the method specified in
[I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using
DHCPv4 and may be assigned with a short lease period in order to DHCPv4 and may be assigned with a short lease period in order to
provide some level of robustness against IP address depletion provide some level of robustness against IP address depletion
attack. The IPsec-TIA is bound to an IPsec SA by using specifying attack. The IPsec-TIA is bound to an IPsec SA by using specifying
the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2 the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2
CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec]. CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec].
Once the IPsec-TIA is obtained, the PANA re-authentication based Once the IPsec-TIA is obtained, the PUR (PANA-Update-Request) and
on PUR (PANA-Update-Rquest) and PUA (PANA-Update-Answer) exchange PUA (PANA-Update-Answer) exchange is performed with using the
is performed with using the obtained IPsec-TIA in order to inform obtained IPsec-TIA in order to inform the PAA of the update of the
PAA of the update of PaC-DI. The IKE procedure should occur after IP address of the PaC. The IKE procedure should occur after the
the PUR-PUA exchange procedure. The PaC unconfigures the PRPA PANA-Update exchange.
immediately after the IPsec-TIA is obtained.
Note that different DHCP servers may be used for obtaining the
PRPA and the POPA, when the PRPA address space and POPA address
space are under different administrative domains.
PRPA
PaC AP DHCPv4 Server PAA EP(AR) PaC AP DHCPv4 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv4 | | | | DHCPv4 | | |
|<-----------+--------->| | | |<-----------+--------->| | |
| | | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in Authentication phase) | | & PAR/PAN exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | | | | | | | |
| | POPA | |
| | DHCPv4 Server | |
| | |Authorization| | | | |Authorization| |
| | |[DHCP-PSK, | | | | |[DHCP-PSK, | |
| | | Session-Id] | | | | | Session-Id] | |
| | |<------------| | | | |<---------------| |
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| Authenticated DHCPv4 | | | | Authenticated DHCPv4 | | |
| (RFC3118) | | | | (RFC3118) | | |
|<-----------+------------>| | | |<-----------+--------->| | |
| | | | | | | | |
| PANA(PUR-PUA exchange based on POPA) | | | PANA(PUR/PUA exchange in access phase based on POPA) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | | |Authorization| | | |Authorization|
| | | |[IKE-PSK, | | | |[IKE-PSK, |
| | | | PaC-DI, | | | | PaC-DI, |
| | | | Session-Id] | | | | Session-Id] |
| | | |------------>| | | |------------>|
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | |
| | | | | | | | |
Figure 15: An example case for IPsec-TIA obtained by using RFC3118 Figure 15: An example case for IPsec-TIA obtained by using RFC3118
Appendix A.2 IPv6 Appendix A.2 IPv6
Case A: IPsec-TIA obtained by using DHCPv6 Case A: IPsec-TIA obtained by using DHCPv6
This case is similar to Case A in IPv4, except that a link-local This case is similar to Case A in IPv4, except that a link-local
address is used as the PRPA and IPsec-TOA, and that the DHCPv6 address is used as the PRPA and IPsec-TOA, and that the DHCPv6
procedure can occur at any time after link-layer association and procedure can occur at any time after link-layer association and
before IKE. before IKE.
  Skipping to change at page 42, line 22:
whether IPv6 Neighbor Discovery for the POPA should run on the whether IPv6 Neighbor Discovery for the POPA should run on the
physical interface or inside the IPsec tunnel or both. physical interface or inside the IPsec tunnel or both.
PaC AP DHCPv6 Server PAA EP(AR) PaC AP DHCPv6 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| DHCPv6 | | | | DHCPv6 | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in Authentication phase) | | & PAR/PAN exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | | |Authorization| | | |Authorization|
| | | |[IKE-PSK, | | | |[IKE-PSK, |
| | | | PaC-DI, | | | | PaC-DI, |
| | | | Session-Id] | | | | Session-Id] |
| | | |------------>| | | |------------>|
| | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | |
| | IKE | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | | |
| | | | | | | | |
Figure 16: An example case for IPsec-TIA obtained by using DHCPv6 Figure 16: An example case for IPsec-TIA obtained by using DHCPv6
Case B: IPsec-TIA obtained by using IPv6 stateless address Case B: IPsec-TIA obtained by using IPv6 stateless address
autoconfiguration autoconfiguration
In this case, the IPsec-TOA (link-local address) and IPsec-TIA In this case, the IPsec-TOA (link-local address) and IPsec-TIA
(global address) are configured through IPv6 stateless address (global address) are configured through IPv6 stateless address
autoconfiguration before running IKE. Other configuration autoconfiguration before running IKE. Other configuration
information can be obtained by using several methods including information can be obtained by using several methods including
authenticated DHCPv6, Configuration Payload exchange and DHCPv6 authenticated DHCPv6, Configuration Payload exchange and DHCPv6
over IPsec SA. over IPsec SA.
This case is not recommended for the same reason as Case A of This case is not recommended for the same reason as Case A of
IPv6. IPv6.
  Skipping to change at page 44, line 11:
This case is not recommended for the same reason as Case A of This case is not recommended for the same reason as Case A of
IPv6. IPv6.
PaC AP PAA EP(AR) PaC AP PAA EP(AR)
| Link-layer | | | | Link-layer | | |
| association| | | | association| | |
|<---------->| | | |<---------->| | |
| | | | | | | |
| | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in Authentication phase) | | & PAR/PAN exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| | |Authorization| | | |Authorization|
| | |[IKE-PSK, | | | |[IKE-PSK, |
| | | PaC-DI, | | | | PaC-DI, |
| | | Session-Id] | | | | Session-Id] |
| | |------------>| | | |------------>|
| | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR/PBA exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | |
| IPv6 stateless address autoconfiguration | | IPv6 stateless address autoconfiguration |
| (can occur at any time before Association and IKEv2) | | (can occur at any time after association and before IKE)
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
| | IKEv2 | | | | IKE | |
|<-----------+---------------------------------------->| |<-----------+---------------------------------------->|
| | | | | | | |
Figure 17: An example sequence for IPsec-TIA obtained by using Figure 17: An example sequence for IPsec-TIA obtained by using
IPv6 stateless address autoconfiguration IPv6 stateless address autoconfiguration
Case C: IPsec-TIA obtained by using authenticated DHCPv6 Case C: IPsec-TIA obtained by using authenticated DHCPv6
This case is similar to Case C of IPv4, except that a link-local This case is similar to Case C of IPv4, except that a link-local
address is used as the PRPA, and that there is no need for address is used as the PRPA, and that there is no need for
additional PUR-PUA exchange to update the PaC-DI. additional PANA-Update exchange to update the the IP address of
the PaC.
PaC AP DHCPv6 Server PAA EP(AR) PaC AP DHCPv6 Server PAA EP(AR)
| Link-layer | | | | | Link-layer | | | |
| association| | | | | association| | | |
|<---------->| | | | |<---------->| | | |
| | | | | | | | | |
| | | | | | | | | |
|PANA(Discovery and Initial Handshake phase | |PANA(Discovery and handshake phase | |
| & PAR-PAN exchange in Authentication phase) | | & PAR/PAN exchange in | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| | |Authorization|Authorization| | | |Authorization|Authorization|
| | |[DHCP-PSK, |[IKE-PSK, | | | |[DHCP-PSK, |[IKE-PSK, |
| | | Session-Id] | PaC-DI, | | | | Session-Id] | PaC-DI, |
| | | | Session-Id] | | | | | Session-Id] |
| | |<------------|------------>| | | |<------------|------------>|
| | | | | | | | | |
|PANA(PBR-PBA exchange in Authentication phase) | |PANA(PBR/PBA exchange in | | |
| authentication and authorization phase) |
|<-----------+-------------------------->| | |<-----------+-------------------------->| |
| | | | | | | | | |
| Authenticated DHCPv6 | | | | Authenticated DHCPv6 | | |
|<-----------+------------>| | | |<-----------+------------>| | |
| | | |Authorization| | | | |Authorization|
| | | | [IKE-PSK, | | | | | [IKE-PSK, |
| | | | PaC-DI, | | | | | PaC-DI, |
| | | | Session-Id]| | | | | Session-Id]|
| | | |------------>| | | | |------------>|
| | IKE | | | | IKE | |