One document matched: draft-yacine-pana-paa2ep-prot-eval-00.txt
PANA WG Yacine El Mghazli
Internet Draft Alcatel
Category: Informational
Document:
draft-yacine-pana-paa2ep-prot-eval-00.txt
Expires: April 2004 October 2003
PANA
PAA-EP protocol considerations
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
The PANA Authentication Agent (PAA) does not necessarily act as an
Enforcement Point (EP) to prevent unauthorized access or usage of the
network. When a PANA Client (PaC) successfully authenticates itself
to the PAA, EP(s) (e.g., access routers) will need to be suitably
notified. The PANA working group will identify a (preferably
existing) protocol solution that allows the PAA to deliver the
authorization information to one or more EPs when the PAA is
separated from EPs.
The present document aims at discussing the various protocol
solutions available and identifying one, which better fits the whole
PANA picture.
El Mghazli Expires - April 2004 [Page 1]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 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. Document History..........................................4
2.2. Scope.....................................................4
3. PAA-EP Protocol Requirements...................................5
3.1. Push model................................................5
3.2. One-to-many PAA-EP relation...............................5
3.3. Provisioned Data..........................................5
3.4. Re-use of an existing protocol............................5
3.5. General Security Requirements.............................5
4. Nice-to-have functions.........................................6
4.1. Pull model................................................6
4.2. Inactive peer detection...................................6
4.3. Stateful approach.........................................7
4.4. Accounting/Feedback from the EPs..........................7
5. PANA framework Assumptions/Issues..............................8
5.1. Multiple PAAs.............................................8
5.1.1. PAA-PaC relation assumption............................8
5.1.2. PAA-EP relation issue..................................9
5.2. Inter-PAAs communication.................................12
6. PAA-EP Protocol Evaluation....................................13
6.1. SNMP.....................................................13
6.1.1. SNMP General Applicability............................13
6.1.2. Compliancy of SNMP against the PAA-EP reqs............14
6.1.3. Compliancy of SNMP against the PANA framework.........15
6.2. COPS-PR..................................................15
6.2.1. COPS General Applicability............................15
6.2.2. COPS extension for provisioning (COPS-PR).............16
6.2.3. Compliancy of COPS-PR against the PAA-EP reqs.........17
6.2.4. Compliancy of COPS-PR against the PANA framework......17
6.3. IAB notice on COPS-PR and PIBs...........................18
7. Conclusion....................................................19
Security Considerations..........................................19
Acknowledgements.................................................19
References.......................................................19
Author's Addresses...............................................20
Full Copyright Statement.........................................21
El Mghazli Expires - April 2004 [Page 2]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
1. Glossary
PANA Protocol for Carrying 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 - April 2004 [Page 3]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 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. Document History
This document is based on an individual submission [PAA-EP-REQ],
which was used as a work basis for discussions around the PAA-EP
interface issues within the PANA working group.
2.2. Scope
First, section 3 details 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). These are specified in [PANAREQ].
The following section 4 presents some functions the PAA-EP protocol
should offer, which have already been discussed on the mailing list.
These are not mandatory at all, but one can consider them as "nice-
to-have".
Then, section 5 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).
Finally, the last section 6 introduces and compares the various
protocol solutions available against the identified requirements for
the PAA-EP interface.
A compliancy summary of each of the proposed solutions is provided.
El Mghazli Expires - April 2004 [Page 4]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
3. PAA-EP Protocol Requirements
3.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 straightforward to initiate the exchange
at the PAA.
3.2. 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.
3.3. Provisioned Data
The protocol must carry DI-based filters and cryptographic keys.
3.4. 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.
3.5. General Security Requirements
The PAA-EP protocol must provide for message authentication,
confidentiality, and integrity.
The PAA-EP protocol must define mechanisms to mitigate attacks on the
control messages.
El Mghazli Expires - April 2004 [Page 5]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
4. Nice-to-have functions
4.1. Pull model
The PUSH model (PAA-initiated configuration) should be used for the
communication between PAA and EP.
However, the PULL model (EP-initiated configuration) might be
supported for the following purposes:
1. 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. Traffic-driven configuration (a.k.a. new PAC 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,
PAA can send the unsolicited PANA_start message directly to the
PaC.
4.2. 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.
El Mghazli Expires - April 2004 [Page 6]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
4.3. 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.4. 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.
El Mghazli Expires - April 2004 [Page 7]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
5. PANA framework Assumptions/Issues
5.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 PAA.
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.
. Etc.
Clearly stating the motivation for having multiples PAAs
authenticating PaCs and provisioning EPs in an access network has
direct consequences on both PAA-PaC and PAA-EP relations.
5.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 straightforward 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).
El Mghazli Expires - April 2004 [Page 8]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
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).
From the PaC perspective, multiple 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 PAA.
5.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 provisioning.
One PAA have to communicate with several EPs once a PaC is
authenticated is a requirement for the PAA-EP protocol (see section
3.2). 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 authenticates the PaCs, a given PAA can either:
a) Redundancy:
provision 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.
+----------------+
+-|---------+ |
v v | |
+----+ +-+----+ | +-----+
PaC -----| EPa| | PAA1 +-|---------+(AAA)|
[D1] +----+ |active|-+-+ +-+---+
+-+----+ | |
| | PAA2 +---------+
| +----+-+
+----+ | |
PaC -----| EPb| | |
[D2] +----+ | |
^ ^ | |
+-|---------+ |
+----------------+
Figure 1. One single active PAA provisioning all the EPs
El Mghazli Expires - April 2004 [Page 9]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
b) Load sharing:
provision all the EPs of the underlying access network and each EP
can be controlled by another active PAA.
+---------------+
+-|---------+ |
v v | |
+----+ +-+----+|
PaC -----| EPa| | PAA1 +------------+
[D1] +----+ | || |
+-+----+| +--+--+
| | |(AAA)|
|+----+-+ +--+--+
+----+ || PAA2 | |
PaC -----| EPb| || +---------+
[D2] +----+ |+----+-+
^ ^ | |
+-|---------+ |
+---------------+
Figure 2. Multiple active PAAs provisioning all the EPs
Such a deployment option can prove to be very well adapted to
situations where there are multiple PAAs belonging to multiple
ISPs. A given PAA belonging to a certain ISP can configure all the
EPs of the Access Network.
+---------------+
+-|---------+ |
v v | | +------+
+----+ +-+----+| | AAA1 |
PaC -----| EPa| | PAA1 +---------+(ISP1)|
[D1] +----+ |(ISP1)|| +------+
+-+----+|
| |
|+----+-+
+----+ || PAA2 | +------+
PaC -----| EPb| ||(ISP2)+------+ AAA2 |
[D2] +----+ |+----+-+ |(ISP2)|
^ ^ | | +------+
+-|---------+ |
+---------------+
Figure 3. Multiple PAAs belonging to multiple ISPs
El Mghazli Expires - April 2004 [Page 10]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
c) Distributed control:
provision a pool of EPs within a given area. The pool can be
identified based on topological criteria for instance.
+-----------+
v |
+----+ +-+----+
PaC -----| EPa| | PAA1 +-------------+
[D1] +----+ | | |
+------+ +--+--+
^ |(AAA)|
| +--+--+
v |
+------+ |
+----+ | PAA2 | |
PaC -----| EPb| | +----------+
[D2] +----+ +----+-+
^ |
+---------------+
Figure 4. Distributed control of the EPs
Such a deployment option can prove to be very well adapted to
Access Network with a large number of EP nodes. In such a
situation, a single PAA cannot deal with so many EPs, then the NAP
can use a given PAA for a given pool of EPs. Do note that this
certainly imply inter-PAA communication for synchronization
purposes (see next section).
Another reason for using this deployment scheme would be to
configure only the EPs concerned by the traffic of the
authenticated PaC. But this brings up other issues (e.g. mobility
case) and it's out of the scope of the present document.
The choice between these various deployment options is motivated by
PANA-specific considerations. Typically, these can be:
. Scalability: How many EPs are managed by the PAA(s)?
. Symmetry: Does all the EPs need to be configured with the same
rules?
. Dynamicity: How often does the EP configuration has to be
refreshed?
El Mghazli Expires - April 2004 [Page 11]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
5.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 - April 2004 [Page 12]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
6. PAA-EP Protocol Evaluation
The previous sections described the functions required or simply
wished for the PAA-to-EP communication. Do note that the so-called
requirements are general enough to allow a large amount of possible
solutions for this interface, namely: SNMP, COPS-PR, Diameter,
Radius, ForCES, NetConf, directory-based solutions, etc.
However, the PANA working group does not wish to choose a disruptive
solution for this PAA-EP management interface. In a similar manner,
the PANA working group does not wish to bet on premature solutions,
whose design is on-going. Hence, the working group will consider the
classical configuration protocols available and consequently, only
the following protocols were mentioned for final consideration:
. SNMP [SNMP]
. COPS-PR [COPS-PR]
The following sections provide an overview of each of these protocols
and its applicability to the PAA-EP interface.
6.1. SNMP
This section provides a general statement with regards to the
applicability of SNMP as the PAA-EP protocol. This evaluation of SNMP
is specific to SNMPv3, which provides the security required for PANA
usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they
have been declared Historic, and because their messages have only
trivial security.
6.1.1.
SNMP General Applicability
The primary advantages of SNMPv3 are that it is a mature, well
understood protocol, currently deployed in various scenarios, with
mature toolsets available for SNMP managers and agents.
Application intelligence is captured in MIB modules, rather than in
the messaging protocol. MIB modules define a data model of the
information that can be collected and configured for a managed
functionality. The SNMP messaging protocol transports the data in a
standardized format without needing to understand the semantics of
the data being transferred. The endpoints of the communication
understand the semantics of the data.
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly
due to variations in configuration requirements across vendors, few
MIB modules have been developed that enable standardized
El Mghazli Expires - April 2004 [Page 13]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
configuration of managed devices across vendors. Since monitoring can
be done using only a least-common-denominator subset of information
across vendors, many MIB modules have been developed to provide
standardized monitoring of managed devices. As a result, SNMP has
been used primarily for monitoring rather than for configuring
network nodes.
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c
versions. Specifically, SNMPv3 shares the separation of data modeling
(MIBs) from the protocol to transfer data, so all existing MIBs can
be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it
shares operations and transport with SNMPv2c. The major difference
between SNMPv3 and earlier versions is the addition of strong message
security and controlled access to data.
SNMPv3 uses the architecture detailed in RFC2571, where all SNMP
entities are capable of performing certain functions, such as the
generation of requests, response to requests, the generation of
asynchronous notifications, the receipt of notifications, and the
proxy-forwarding of SNMP messages. SNMP is used to read and
manipulate virtual databases of managed-application-specific
operational parameters and statistics, which are defined in MIB
modules.
6.1.2.
Compliancy of SNMP against the PAA-EP reqs
All the requirements as described in section 3 are fully supported by
SNMP:
a) The protocol must carry DI and keys
Already defined MIBs (for filters, IPSec policy, etc.) can
be re-used. if not sufficient, PANA-specific MIBs can be
designed.
b) There might be multiple EPs per PAA.
An SNMP manager (PAA) can communicate simultaneously with
several agents (EPs).
c) The protocol must be secured
SNMPv3 includes the User-based Security Model (USM,
[RFC2574]), which defines three standardized methods for
providing authentication, confidentiality, and integrity.
Additionally, USM has specific built-in mechanisms for
preventing replay attacks including unique protocol engine
IDs, timers and counters per engine and time windows for the
validity of messages.
d) The protocol may allow the EP to notify a new PaC
El Mghazli Expires - April 2004 [Page 14]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
Using SMI notifications
6.1.3.
Compliancy of SNMP against the PANA framework
When multiple PAAs, since SNMP allow multiple managers (PAAs) per
agent (EP), it fits better deployments where the multiple PAAs are
configuring all the access network EPs (section 5.1.2, option b, load
sharing). SNMP is the very usual Internet Management protocol.
SNMP does not provide heartbeat mechanisms, nor a stateful model (see
section 2), but this is not required by PANA.
6.2. COPS-PR
The Common Open Policy Service (COPS) [RFC2748] protocol has been
extended to provision configuration information on devices (COPS-PR)
[RFC3084]. Work is underway to define data definitions for specific
services such as Differentiated Services (DiffServ).
6.2.1.
COPS General Applicability
IETF has defined the COPS protocol [COPS] as a scalable protocol that
allows policy servers (PDPs) to communicate policy decisions to
network devices (PEPs). COPS was designed to support multiple types
of policy clients.
The main characteristics of the COPS base protocol include the
following:
1. The protocol employs a client/server model. The PEP sends
requests, updates, and deletions to the remote PDP and the PDP
returns decisions back to the PEP.
2. The protocol uses TCP as its transport protocol for reliable
exchange of messages between policy clients and a server.
3. The protocol is extensible in that it is designed to leverage
self-identifying objects and can support diverse client
specific information without requiring modification of the COPS
protocol.
4. The protocol was created for the general administration,
configuration, and enforcement of policies.
5. COPS provides message level security for authentication, replay
protection, and message integrity. COPS can make use of
El Mghazli Expires - April 2004 [Page 15]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
existing protocols for security such as IPSEC or TLS to
authenticate and secure the channel between the PEP and the
PDP.
6. The protocol is stateful in two main aspects:
a. Request/Decision state is shared and kept synchronized in a
transactional manner between client and server. Requests
from the client PEP are installed or remembered by the
remote PDP until they are explicitly deleted by the PEP. At
the same time, Decisions from the remote PDP can be
generated asynchronously at any time for a currently
installed request state.
b. State from various events (Request/Decision pairs) may be
inter-associated. The server may respond to new queries
differently because of previously installed, related
Request/Decision state(s).
7. The protocol is also stateful in that it allows the server to
push configuration information to the client, and then allows
the server to remove such state from the client when it is no
longer applicable.
6.2.2.
COPS extension for provisioning (COPS-PR)
In COPS-PR, the PDP may proactively provision the PEP reacting to
external events, such as successful client authentication. This model
is also known as the push/configuration model. Provisioning may be
performed in bulk (e.g., entire EP configuration) or in portions
(e.g., updating a filter).
The COPS-PR specification [COPS-PR] is independent of the type of
policy being provisioned (QoS, Security, etc.). Rather, it focuses on
the mechanisms and conventions used to communicate provisioned
information between the PDP and its PEPs. The data model assumed in
[COPS-PR] is based on the concept of Policy Information Bases (PIBs)
that define the policy data. There may be one or more PIBs for given
area of policy and different areas of policy may have different sets
of PIBs.
COPS-PR has been designed within a framework that is optimized for
efficiently provisioning policies across devices:
. First, COPS-PR allows for efficient transport of attributes,
large atomic transactions of data, and efficient and flexible
error reporting.
. Second, as it has a single connection between the policy client
and server per area of policy control identified by a COPS
El Mghazli Expires - April 2004 [Page 16]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
Client-Type, it guarantees only one server updates a particular
policy configuration at any given time. Such a policy
configuration is effectively locked, even from local console
configuration, while the PEP is connected to a PDP via COPS.
COPS uses reliable TCP transport and, thus, uses a state
sharing/synchronization mechanism and exchanges differential
updates only. If either the server or client are rebooted (or
restarted) the other would know about it quickly.
. Last, it is defined as a real-time event-driven communications
mechanism, never requiring polling between the PEP and PDP.
6.2.3.
Compliancy of COPS-PR against the PAA-EP reqs
All the requirements as described in section 3 are fully supported by
COPS-PR:
a) The protocol must carry DI-based filters and keys:
Already defined PIBs (for filters, IPSec policy, etc.) can
be re-used. if not sufficient, PANA-specific PIBs can be
designed.
b) There might be multiple EPs per PAA:
COPS-PR PDPs (PAAs) are designed to communicate with several
PEPs (EPs).
c) The protocol must be secured:
COPS-PR has built-in message level security for
authentication, replay protection, and message integrity.
COPS-PR can also use TLS or IPSec, thus reusing existing
security mechanisms that have interoperated in the markets.
d) The protocol may allow the EP to notify a new PaC:
COPS-PR outsourcing allowed (3GPP-like)
6.2.4.
Compliancy of COPS-PR against the PANA framework
When multiple PAAs, since the COPS-PR framework allow only a single
PDP (PAA) to configure a given PEP (EP), it fits better deployments
where the multiple PAAs are configuring pools of EPs (section 5.1.2,
option c, distributed control).
COPS-PR naturally provides heartbeat mechanisms, a stateful model,
accounting facilities and nicely supports dynamic configuration (see
section 2), but this is not required by PANA.
A little more detailed information can be found in [COPS-PANA].
El Mghazli Expires - April 2004 [Page 17]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
6.3. IAB notice on COPS-PR and PIBs
On the one hand, purely technically speaking, when compared to both
the whished (section 4) and required (section 3) functions, COPS-PR
seems to offer a slightly better solution for the EP configuration.
On the other hand, [RFC3535] provides an overview of a workshop held
recently by the IAB on Network Management. In the recommendations
section, one can read the following:
"2. The workshop had rough consensus from the protocol developers
that the IETF should not spend resources on COPS-PR development. So
far, the operators have only very limited experience with COPS-PR. In
general, however, they felt that further development of COPS-PR might
be a waste of resources as they assume that COPS-PR does not really
address their requirements.
3. The workshop had rough consensus from the protocol developers that
the IETF should not spend resources on SPPI PIB definitions. The
operators had rough consensus that they do not care about SPPI PIBs."
El Mghazli Expires - April 2004 [Page 18]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
7. Conclusion
The main output of this evaluation paper is that the PANA
requirements for the PAA-EP interface are soft enough to allow almost
any of the protocol solutions available. Nevertheless, the PANA
working group restrict its choice to the 'classical' and available
device configuration protocols, namely SNMP and COPS-PR.
Moreover and according the operators will (via the IAB
recommendations), today COPS-PR is not promised to a nice future. It
could prove to be hazardous to bet on this protocol, however
efficient it is. In addition, COPS-PR is maybe too heavy for small
configuration sets like those needed in PANA.
Hence, since the PAA-EP requirements are well validated by SNMP, it
seems better for the PANA working group to mandate this latest
solution and take advantage of its widely deployed framework.
Security Considerations
See section 3.5
Acknowledgements
This evaluation draft leverages on similar works done in the MIDCOM
working group. Thanks to the authors of those IDs.
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.
El Mghazli Expires - April 2004 [Page 19]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 2003
[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
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and
A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC
2748, January 2000.
[PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin,
"Protocol for Carrying Authentication for Network Access
(PANA)"(draft-ietf-pana-pana-01.txt).
[DIAMETER] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney,
"Diameter Base Protocol" (draft-ietf-aaa-diameter-15.txt).
[PAA-EP-REQ] Y. El Mghazli , "PANA PAA-EP Protocol Requirements"
(draft-yacine-pana-paa-ep-reqs-00.txt).
[COPS-PANA] Y. El Mghazli, " Enforcement Point(s) Provisioning and
Accounting using COPS-PR" (draft-yacine-pana-cops-ep-00.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 - April 2004 [Page 20]
Internet Draft draft-yacine-pana-paa2ep-prot-eval-00.txt October 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 - April 2004 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-21 18:39:18 |