PANA WG Yacine El Mghazli
Internet Draft Alcatel
Category: Informational
Document: draft-yacine-pana-paa-ep-reqs-00.txt
Expires: December 2003 June 2003
PANA
PAA-EP Protocol Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [STD].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies the requirements that the PAA-EP protocol
must satisfy in order to meet the needs of PANA when the PAA is
separated from EP(s).
El Mghazli Expires - December 2003 [Page 1]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Glossary.......................................................3
2. Introduction...................................................3
2.1 Scope......................................................4
3. PANA framework Assumptions/Issues..............................4
3.1 Multiple PAAs..............................................4
3.2 Inter-PAAs communication...................................6
4. PAA-EP Protocol Requirements...................................7
4.1 Push model.................................................7
4.2 Pull model.................................................7
4.3 1:n PAA-EP relation........................................8
4.4 Inactive peer detection....................................8
4.5 Stateful approach..........................................8
4.6 Recovery...................................................8
4.7 General Security Requirements..............................8
4.8 Accounting/Feedback from the EPs...........................9
4.9 Re-use of an existing protocol.............................9
Security Considerations...........................................9
References........................................................9
Acknowledgments........................Error! Bookmark not defined.
Author's Addresses...............................................10
Full Copyright Statement.........................................11
El Mghazli Expires - December 2003 [Page 2]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
1. Glossary
PANA Protocol for Carying Authentication for Network Access.
PaC (PANA Client):
The client side of the protocol that resides in the host device
which is responsible for providing the credentials to prove its
identity for network access authorization.
DI (Device Identifier):
The identifier used by the network as a handle to control and
police the network access of a client. Depending on the access
technology, this identifier might contain any of IP address, link-
layer address, switch port number, etc. of a connected device.
PAA (PANA Authentication Agent):
The access network side entity of the protocol whose responsibility
is to verify the credentials provided by a PANA client and grant
network access service to the device associated with the client and
identified by a DI.
EP (Enforcement Point):
A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of
client devices. Information such as DI and (optionally)
cryptographic keys are provided by PAA per client for constructing
filters on the EP.
2. Introduction
Client access authentication should be followed by access control to
make sure only authenticated and authorized clients can send and
receive IP packets via access network. Access control can involve
setting access control lists on the enforcement points.
Identification of clients which are authorized to access the network
is done by the PANA protocol exchange.
PANA does not assume that the PAA is always co-located with the
EP(s). Network access enforcement can be provided by one or more
nodes on the same IP subnet as the client (e.g., multiple routers),
or on another subnet in the access domain (e.g., gateway to the
Internet, depending on the network architecture). When the PAA and
the EP(s) are separated, there needs to be another transport for
client provisioning. This transport is needed to create access
El Mghazli Expires - December 2003 [Page 3]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
control lists to allow authenticated and authorized clients' traffic
through the EPs. PANA Working Group will preferably identify an
existing protocol solution that allows the PAA to deliver the
authorization information to one or more EPs when the PAA is
separated from EPs.
2.1 Scope
The following section 3 discusses the PANA framework assumptions that
are being made within the PANA working group. It deals with crucial
issues around the authentication process, when the PAA is separated
from EP(s).
From this standpoint, section 4 details the requirements that the
PAA-EP protocol must satisfy in order to meet the needs of such a
framework.
3. PANA framework Assumptions/Issues
3.1 Multiple PAAs
Multiple PAAs may be used for redundancy, load sharing, distributed
authentication, or other purposes:
a) Redundancy is the case where one or more PAAs are prepared to
take over if an active PAA fails.
b) Load sharing is the case where two or more PAAs are concurrently
active and any PaC that can be authenticated by one of the PAAs
can also be authenticated by any of the other PAAs.
For both redundancy and load sharing, the PAAs involved are
equivalently capable. The only difference between these two cases a)
and b) is in terms of how many active PAAs there are.
c) Distributed authentication is the case where two or more PAAs
are concurrently active but certain PANA requests using PANA can
only be serviced by certain PAAs. The logical separation can be
based on:
. Topology: One given PAA is in charge of authenticating a
pool of PaCs belonging to the same topological area.
. The ISP: One given PAA is in charge of authenticating the
PaCs clients to a given ISP. Then it forwards the PANA
requests based on the NAI or other identifier.
El Mghazli Expires - December 2003 [Page 4]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
. Etc.
Clearly stating the motivation for having multiples PAAs
authenticating PaCs and provisoning EPs in an access network has
direct consequences on both PaC-PAA and EP-PAA relations.
3.1.1 PAA-PaC relation assumption
According to [PANA] (section "Discovery and Initial Handshake
Phase"), "There can be multiple PAAs on the link. The result does not
depend on which PAA PaC chooses. By default PaC chooses the PAA that
sent the first response."
Then, it is straighforward that the assumption that is being made
here is that two or more PAAs are concurrently active and any PaC
that can be authenticated by one of the PAAs can also be
authenticated by any of the other PAAs. We are clearly in the case
where the PaCs load is shared between the multiple PAAs (b).
Do note that discovery issues are raised with allowing muliples PAAs
to authenticate the various PaCs. [PANA] solves the problem simply
stating that the chosen PAA corresponds to the first response. It is
consistent with case b).
3.1.2 PAA-EP relation issue
In a similar manner, it is crucial for identifying the various PAA-EP
protocol requirements to clearly identify the context for having
multiples PAAs with respect to the EPs provisoning.
One PAA have to communicate with several EPs once a PaC is
authenticated is a requirement for the PAA-EP protocol (see section
4.3). In the case where there is a single PAA, the assumption being
made is that the PAA will provision all the EPs. However, it remains
an issue in case we have multiple PAAs.
When multiple PAAs authenticate the PaC, a given PAA can either:
a) Redundancy:
provisions all the EPs of the underlying access network and each
EP has a single active PAA. A back-up PAA is ready to take over if
the first one fails.
b) Load sharing:
provisions all the EPs of the underlying access network and each
EP can be controlled by another active PAA.
El Mghazli Expires - December 2003 [Page 5]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
c) Distributed control:
provisions a pool of EPs within a given area. The pool can be
identified based on topological criteria for instance.
The choice between these options is motivated by PANA-specific
considerations. Typically, these can be:
. Scalability:
How many EPs are managed by the PAA(s) ?
. Symetry:
Does all the EPs need to be configured with the same rules ?
. Etc.
3.2 Inter-PAAs communication
When multiple PAAs are employed, their internal organization is
considered an implementation issue that is beyond the scope of PANA.
PAAs are wholly responsible for coordinating amongst themselves to
provide consistency and synchronization. However, PANA does not
define the implementation or protocols used between PAAs, nor does it
define how to distribute functionality among PAAs. Nevertheless, PANA
will support mechanisms for PAA redundancy or fail over, and it is
expected that vendors will provide redundancy or fail over solutions
within the PANA framework.
El Mghazli Expires - December 2003 [Page 6]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
4. PAA-EP Protocol Requirements
4.1 Push model
PAA must be able to "push" the provisioning information down to EPs,
without any of the EPs "pulling" it. Since PANA exchange takes place
between PaC and PAA, EPs are unlikely to be aware of it.
EP provisioning takes place once the PaC is authenticated and
authorized, hence the event triggering the EP configuration takes
place at the PAA. Then it's straighforward to initiate the exchange
at the PAA.
4.2 Pull model
The PUSH model (PAA-initiated configuration) should be used for the
communication between PAA and EP.
On the other hand, the PULL model (EP-initiated configuration) might
be supported also for the following purposes:
1. Initial EP registration/Recovery:
When a EP is newly connected to the network, it needs to register
itself to the PAA.
In a similar manner, when an EP crashes and comes up again, it
needs to re-connect its PAA. In general, when a failure is
detected, the EP must try to reconnect to the remote PAA or
attempt to connect to PAA.
2. (Optional) traffic-driven config (a.k.a. event-notification):
As stated in [PANA], PaC may also choose to start sending packets
before getting authenticated. In that case, the network should
detect this and send an unsolicited PANA_start message to PaC. EP
is the node that can detect such activity. If EP and PAA are co-
located, then an internal mechanism (e.g. API) between the EP
module and the PAA module on the same host can prompt PAA to start
PANA. In case they are separate, there needs an explicit message
to prompt PAA.
Upon detecting the need to authenticate a client, EP can send a
trigger message to the PAA on behalf of the PaC. This can be one
of the messages provided by the PAA-EP protocol, or, in the
absence of such a facility, PAC_discovery can be used as well.
This message MUST carry the device identifier of the PaC. So that,
El Mghazli Expires - December 2003 [Page 7]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
PAA can send the unsolicited PANA_start message directly to the
PaC.
4.3 One-to-many PAA-EP relation
One PAA have to communicate with several Eps once a PaC is
authenticated. The PAA-EP protocol must be able to handle this 1:n
communication.
4.4 Inactive peer detection
The protocol used between PAA and EP should be able to detect
inactive peer within an appropriate time period.
This can be achieved by having both the EP and remote PAA constantly
verify their connection to each other via keep-alive messages: a
heartbeat in fact.
4.5 Stateful approach
The protocol must allow to maintain some states in the PAA in order
for an EP that went down and came back up, or an EP that is being
introduced in the network to (re-)synchronize with the PAA.
In general terms, the PAA-EP protocol needs to support the stateful
model between the PAA and the EP(s) and some other mechanism for the
EP to learn the policies currently in effect on that access network.
4.6 Recovery
TBD.
If there is awareness of a connection state in the application level
and we have a keepalive and/or use a reliable transport protocol
(similar to routing protocols), all detection and synchronizing of
state will come naturally.
4.7 General Security Requirements
The PAA-EP protocol must provide for message authentication,
confidentiality, and integrity.
The PAA-EP protocol must define mechanisms to mitigate replay attacks
on the control messages.
El Mghazli Expires - December 2003 [Page 8]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
4.8 Accounting/Feedback from the EPs
The PAA must have an efficient way to to get the accounting
information of PaC from EP since the PAA may be a client of the AAA
backend infrastructure.
4.9 Re-use of an existing protocol
This work hopefully will not involve any new protocol design, it may
involve definition of new AVPs for existing protocols. The PANA
working group should try to re-use one of the many protocols around
to do this. The following protocols were mentioned for consideration:
. SNMP [SNMP]
. COPS-PR [COPS-PR]
. DIAMETER [DIAMETER]
. RADIUS [RADIUS]
. ForCES [ForCES]
Security Considerations
See section 4.7
References
[STD] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for
Network Access (PANA) Requirements and Terminology" (draft-ietf-
pana-requirements-07.txt).
[RADIUS] C. Rigney et. al, "Remote Authentication Dial In User
Service", RFC2865, June 2000.
[COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F.
Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for
Policy Provisioning,", RFC 3084, March 2001
El Mghazli Expires - December 2003 [Page 9]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
[PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin,
"Protocol for Carrying Authentication for Network Access
(PANA)"(draft-ietf-pana-pana-00.txt).
[DIAMETER] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney,
"Diameter Base Protocol" (draft-ietf-aaa-diameter-15.txt).
Author's Addresses
Yacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex
Phone: +33 (0)1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
El Mghazli Expires - December 2003 [Page 10]
Internet Draft draft-yacine-pana-paa-ep-reqs-00.txt June 2003
Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
El Mghazli Expires - December 2003 [Page 11]