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 , 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 , March 2002. [FEED-FRWK] D. Rawlins, A. Kulkarni, "Framework of COPS-PR Policy Usage Feedback", Internet Draft , March 2002. [DS-PIB] K.Chan, et al. "DiffServ Policy Information Base", Internet Draft , June 2002. [IPSEC-PIB] M.Li, D.Arneson, A.Doria, J.Jason, C.Wang, M.Stenberg, "IPsec Policy Information Base", Internet Draft , 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]