One document matched: draft-yacine-pana-cops-ep-00.txt
PANA WG Yacine El Mghazli
Internet Draft Alcatel
Category: Informational
Document: draft-yacine-pana-cops-ep-00.txt
Expires: August 2003 February 2003
PANA Enforcement Point(s)
Provisioning and Accounting using COPS-PR
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 considers the use of COPS-PR as the protocol that
allows the PANA Authentication Agent to deliver the authorization
information to one or more Enforcement Points when the PAA is
separated from the Enforcement Point(s).
El Mghazli Expires - August 2003 [Page 1]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 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 Terminology Warning........................................4
3. COPS protocol..................................................4
3.1 COPS extension for provisioning (COPS-PR)..................5
3.2 Dynamic configuration considerations.......................5
4. Interaction between the EP(PEP) and PAA(PDP)...................6
5. Deployment scenarios...........................................7
5.1 single PAA separated from EPs (and ARs)....................7
5.2 multiples PAAs separated from EPs (and ARs)................7
6. Policy Data reuse..............................................8
6.1 Access Control.............................................8
6.2 Accounting.................................................9
6.3 Authorization..............................................9
IANA considerations...............................................9
Security Considerations...........................................9
References........................................................9
Acknowledgments..................................................11
Author's Addresses...............................................11
Full Copyright Statement.........................................12
El Mghazli Expires - August 2003 [Page 2]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
1. Glossary
PAA PANA Authentication Agent. See [PANA-REQ].
EP Enforcement Point. See [PANA-REQ].
PANA Protocol for Carying Authentication for Network Access.
DI Device Identifier. See [PANA-REQ].
PaC PANA Client. See [PANA-REQ].
COPS Common Open Policy Service. See [COPS].
PRC Provisioning Class. A table of a PIB.
PRI Provisioning Instance. An instance of a PRC.
PIB Policy Information Base. See [COPS-PR].
PDP Policy Decision Point. See [RAP-FRWK].
PEP Policy Enforcement Point. See [RAP-FRWK].
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.
Moreover, PANA does not assumes the PAA is co-located with the
enforcement point. 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 other transport for
client provisioning. This transport is needed to create access
control lists to allow authenticated and authorized clients on the
enforcement points.
In the context of PANA, EP configuration occurs at the edges, focuses
exclusively on atomic service deployment and requires frequent
updates. In the network access authentication field, frequent means
every time a user logs in. In such environment, configuration changes
must be performed quickly to accommodate systems or users waiting for
authorization (login, call setup delay, etc.). Further, because most
service changes are transitory (when the call completes, the
configurations should be uninstalled), a mechanism that simplifies
this process is ideal.
Given these requirements, COPS-PR is an optimal choice amongst the
available alternatives. This document considers the (re)use of [COPS-
PR] as the protocol that allows the PAA to deliver the authorization
information to one or more EPs when the PAA is separated from EPs.
El Mghazli Expires - August 2003 [Page 3]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
2.1 Terminology Warning
The present document focuses on the use of COPS-PR between the PAA
and EPs. The EP stands for the COPS client and the PAA stands for the
COPS server.
Consequently, in the whole document, PEP and EP (respectively PDP and
PAA) designate the same entity.
3. COPS protocol
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
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
El Mghazli Expires - August 2003 [Page 4]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
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.
3.1 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).
Here, policy requests describe the PEP and its configurable
parameters (capabilities description). Decisions are not necessarily
mapped directly to requests, and are issued mostly when the PDP
responds to external events or PDP events (e.g. successful client
authentication).
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.
3.2 Dynamic configuration considerations
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
Client-Type, it guarantees only one server updates a particular
El Mghazli Expires - August 2003 [Page 5]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
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.
In the context of PANA, EP configuration occurs at the edges, focuses
exclusively on atomic service deployment and requires frequent
updates. In the network access authentication field, frequent means
every time a user logs in. In such environment, configuration changes
must be performed quickly to accommodate systems or users waiting for
authorization (login, call setup delay, etc.). Further, because most
service changes are transitory (when the call completes, the
configurations should be uninstalled), a mechanism that simplifies
this process is ideal.
Given these requirements, COPS-PR is an optimal choice amongst the
available alternatives.
4. Interaction between the EP(PEP) and PAA(PDP)
When a EP boots, it opens a COPS connection to its primary PAA. When
the connection is established, the EP sends information about itself
to the PAA in the form of a configuration request.
This information includes client EP specific information (e.g.,
hardware type, software release, configuration information). In
response, the PDP downloads all provisioned policies that are
currently relevant to that EP. On receiving the provisioned policies,
the EP maps them into its local filtering rules, and installs them.
If conditions change at the PDP such that the PDP detects that
changes are required in the provisioned policies currently in effect,
then the PAA sends the changes (installs, updates, and/or deletes) in
policy to the EP, and the PAA updates its local configuration
appropriately.
If, subsequently, the configuration of the device changes (board
removed, board added, new software installed, etc.) in ways not
covered by policies already known to the PEP, then the PEP
asynchronously sends this unsolicited new information to the PDP in
an updated configuration request. On receiving this new information,
the PDP sends to the PEP any additional provisioned policies now
needed by the PEP, or removes those policies that are no longer
required.
El Mghazli Expires - August 2003 [Page 6]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
5. Deployment scenarios
5.1 single PAA separated from EPs (and ARs)
Figure 1 represents this model. In this scenario, there is only one
PAA in the edge subnet responsible for all the EPs provisioning.
Although, this PAA is neither co-located with EPs nor ARs, the PAA
could be co-located with one of the router. After successful
authentication, access control parameters will be
distributed/provisioned to respective (w.r.t the corresponding PaC)
enforcement points using COPS-PR.
PaC[DI0]-+
|
PaC[DI1]-+-EP1(PEP1)-----+- router
|
PaC[DI2]---EP2(PEP2)-----+
|
PaC[DI3]---EP3(PEP3)-----+- router
|
+- PAA (PDP) --- (AAA)optional
Figure 1. single PAA
5.2 multiples PAAs separated from EPs (and ARs)
Figure 2 represents this model. In this scenario, there are multiples
PAA in the edge subnet, each one being responsible for provisoning
distinct 'pools' of EPs. Although, this PAA is neither co-located
with EPs nor ARs, the PAA could be co-located with all or part of the
access routers. After successful authentication, each PAA controling
access for a defined domain will provision the respective (w.r.t the
corresponding PaC) enforcement points via COPS-PR with access control
information.
El Mghazli Expires - August 2003 [Page 7]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
PaC[DI0]-+ +- PAA-1 (PDP-1) --+-(AAA)optional
| | |
PaC[DI1]-+-EP1(PEP1a)----+- router |
| |
PaC[DI2]---EP2(PEP2a)----+ |
| |
PaC[DI3]---EP3(PEP2b)----+- router |
| |
+- PAA-2 (PDP-2) --+
Figure 2. multiples PAAs
6. Policy Data reuse
The data carried by COPS-PR is a set of policy data. The protocol
assumes a named data structure, known as a PIB, to identify the type
and purpose of unsolicited policy information that is "pushed" from
the PDP to the PEP for provisioning policy or sent to the PDP from
the PEP as a notification. The PIB name space is common to both the
PEP and the PDP and data instances within this space are unique
within the scope of a given Client-Type and Request-State per TCP
connection between a PEP and PDP.
6.1 Access Control
In the context of PANA, the access control information provisioned by
the PAA to the EP consists are DI-based filters. Depending on the
access technology, DIs might contain any of IP address, link-layer
address, switch port number, etc. of a device.
As described in [COPS-PR], each client supports a non-overlapping and
independent set of PIB modules. However, some PRovisioning Classes
(PRCs) are common to all subject-categories (client-types) and need
to be present in each. Hence, [FRWK-PIB] defines a set of PRCs and
textual conventions that are common to all clients that provision
policy using COPS-PR.
This framework PIB contains a classifier classes group, which defines
IP, IEEE 802 and Internal Label Classifier elements. This set of
tables consist of a Base Filter table that is extended to form the IP
Filter table, the 802 Filter table and the Internal Label table.
Filters may also be defined outside [FRWK-PIB] and used to extend the
Base Filter table.
El Mghazli Expires - August 2003 [Page 8]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
These existing filter-tables can be reused and/or extended in the
framework for PANA EP configuration, depending of the definition of
the various Device Identifiers.
6.2 Accounting
[COPS] enables the PEP(EP) to report to the PDP(PAA) the current
status of any installed request state when appropriate. This
information is sent in a Report-State (RPT) message with the
"Accounting" flag set. The request state that is being reported is
identified via the associated Client Handle in the report message.
[FEED-FRWK] focuses on the COPS Report Type of Accounting and the
necessary framework for the monitoring and reporting of usage
feedback for an installed state.
Moreover, [FEED-PIB] describes a portion of the Policy Information
Base (PIB) to control policy usage collection and reporting in a
device using COPS-PR. The provisioning classes specified in [FEED-
PIB] allow a PDP to select which policy objects should collect usage
information, what information should be collected and when it should
be reported.
All these mechanisms and tables can be reused as is.
6.3 Authorization
PANA provides only a binary authorization to indicate whether the PaC
is allowed to access full IP services on the network.
If needed, the reuse of existing PIBs enables a finer granularity
authorization, such as provisioning e.g. QoS parameters, IPSec
tunnels, using respectfully the DiffServ PIB [DS-PIB] or the IPSec
PIB [IPSEC-PIB].
Security Considerations
The information transported by the COPS protocol [COPS-PR] between
the PAA and EPs are sensitive, and its function of provisioning a EP
requires that only authorized communication take place. The use of
IPSEC between PDP and PEP, as specified in [COPS], provides the
necessary protection against these threats.
IANA considerations
PANA Client-type assigned by IANA.
El Mghazli Expires - August 2003 [Page 9]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
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
[PANA-REQ] A. Yegin, R. Penno, et al. , "Protocol for carrying
authentication for network access (PANA)requirements and
terminology," Internet Draft, Internet Engineering Task Force,
July 2002. Work in progress.
[RAP-FRWK] R. Yavatkar, D. Pendarakis, "A Framework for Policy-based
Admission Control", RFC 2753, January 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
[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.
[HEADER] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[IPSEC] S. Kent, R. Atkinson, "IP Encapsulating Security Payload",
RFC 2406, November 1998.
[SPPI] K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R.
Sahita, A. Smith, F. Reichmeyer, "Structure of Policy Provisioning
Information", RFC 3159,August 2001.
[FR-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R.
Sahita, A. Smith, F. Reichmeyer, "Framework Policy Information
Base", Internet Draft <draft-ietf-rap-frameworkpib-09.txt>, June
2002.
[RAP-FRWK] R. Yavatkar, D. Pendarakis, "A Framework for Policy-based
Admission Control", RFC 2753, January 2000.
[FEED-PIB] D. Rawlins, A. Kulkarni, K.H. Chan, M. Bokaemper, D. Dutt,
"Framework of COPS-PR Policy Information base Usage Feedback",
El Mghazli Expires - August 2003 [Page 10]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 2003
Internet Draft <draft-ietf-rap-feedback-fr-pib-02.txt>, March
2002.
[FEED-FRWK] D. Rawlins, A. Kulkarni, "Framework of COPS-PR Policy
Usage Feedback", Internet Draft <draft-ietf-rap-feedback-frwk-
02.txt>, March 2002.
[DS-PIB] K.Chan, et al. "DiffServ Policy Information Base", Internet
Draft <draft-ietf-diffserv-pib-09.txt>, June 2002.
[IPSEC-PIB] M.Li, D.Arneson, A.Doria, J.Jason, C.Wang, M.Stenberg,
"IPsec Policy Information Base", Internet Draft <draft-ietf-ipsp-
ipsecpib-07.txt>, January 2003.
Acknowledgments
Walter Weiss for an extract.
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 - August 2003 [Page 11]
Internet Draft draft-yacine-pana-cops-ep-00.txt February 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 - August 2003 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 06:32:51 |