[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
   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]