[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/