rfc2748.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     D. Durham, Ed.
Request for Comments: 2748                                         Intel
Category: Standards Track                                       J. Boyle
                                                                 Level 3
                                                                R. Cohen
                                                                   Cisco
                                                               S. Herzog
                                                               IPHighway
                                                                R. Rajan
                                                                    AT&T
                                                               A. Sastry
                                                                   Cisco
                                                            January 2000


             The COPS (Common Open Policy Service) Protocol


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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 [RFC-2119].

Abstract

   This document describes a simple client/server model for supporting
   policy control over QoS signaling protocols. The model does not make
   any assumptions about the methods of the policy server, but is based
   on the server returning decisions to policy requests. The model is
   designed to be extensible so that other kinds of policy clients may
   be supported in the future. However, this document makes no claims
   that it is the only or the preferred approach for enforcing future
   types of policies.





Durham, et al.              Standards Track                     [Page 1]

RFC 2748                          COPS                      January 2000


Table Of Contents

   1. Introduction....................................................3
   1.1 Basic Model....................................................4
   2. The Protocol....................................................6
   2.1 Common Header..................................................6
   2.2 COPS Specific Object Formats...................................8
   2.2.1 Handle Object (Handle).......................................9
   2.2.2 Context Object (Context).....................................9
   2.2.3 In-Interface Object (IN-Int)................................10
   2.2.4 Out-Interface Object (OUT-Int)..............................11
   2.2.5 Reason Object (Reason)......................................12
   2.2.6 Decision Object (Decision)..................................12
   2.2.7 LPDP Decision Object (LPDPDecision).........................14
   2.2.8 Error Object (Error)........................................14
   2.2.9 Client Specific Information Object (ClientSI)...............15
   2.2.10 Keep-Alive Timer Object (KATimer)..........................15
   2.2.11 PEP Identification Object (PEPID)..........................16
   2.2.12 Report-Type Object (Report-Type)...........................16
   2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
   2.2.14 Last PDP Address (LastPDPAddr).............................17
   2.2.15 Accounting Timer Object (AcctTimer)........................17
   2.2.16 Message Integrity Object (Integrity).......................18
   2.3 Communication.................................................19
   2.4 Client Handle Usage...........................................21
   2.5 Synchronization Behavior......................................21
   3. Message Content................................................22
   3.1 Request (REQ)  PEP -> PDP.....................................22
   3.2 Decision (DEC)  PDP -> PEP....................................24
   3.3 Report State (RPT)  PEP -> PDP................................25
   3.4 Delete Request State (DRQ)  PEP -> PDP........................25
   3.5 Synchronize State Request (SSQ)  PDP -> PEP...................26
   3.6 Client-Open (OPN)  PEP -> PDP.................................26
   3.7 Client-Accept (CAT)  PDP -> PEP...............................27
   3.8 Client-Close (CC)  PEP -> PDP, PDP -> PEP.....................28
   3.9 Keep-Alive (KA)  PEP -> PDP, PDP -> PEP.......................28
   3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
   4. Common Operation...............................................29
   4.1 Security and Sequence Number Negotiation......................29
   4.2 Key Maintenance...............................................31
   4.3 PEP Initialization............................................31
   4.4 Outsourcing Operations........................................32
   4.5 Configuration Operations......................................32
   4.6 Keep-Alive Operations.........................................33
   4.7 PEP/PDP Close.................................................33
   5. Security Considerations........................................33
   6. IANA Considerations............................................34




Durham, et al.              Standards Track                     [Page 2]

RFC 2748                          COPS                      January 2000


   7. References.....................................................35
   8. Author Information and Acknowledgments.........................36
   9. Full Copyright Statement.......................................38

1. Introduction

   This document describes a simple query and response protocol that can
   be used to exchange policy information between a policy server
   (Policy Decision Point or PDP) and its clients (Policy Enforcement
   Points or PEPs).  One example of a policy client is an RSVP router
   that must exercise policy-based admission control over RSVP usage
   [RSVP].  We assume that at least one policy server exists in each
   controlled administrative domain. The basic model of interaction
   between a policy server and its clients is compatible with the
   framework document for policy based admission control [WRK].

   A chief objective of this policy control protocol is to begin with a
   simple but extensible design. The main characteristics of the COPS
   protocol include:

      1. The protocol employs a client/server model where the PEP sends
         requests, updates, and deletes 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.
         Therefore, no additional mechanisms are necessary for reliable
         communication between a server and its clients.

      3. The protocol is extensible in that it is designed to leverage
         off self-identifying objects and can support diverse client
         specific information without requiring modifications to the
         COPS protocol itself. The protocol was created for the general
         administration, configuration, and enforcement of policies.

      4. COPS provides message level security for authentication, replay
         protection, and message integrity. COPS can also reuse existing
         protocols for security such as IPSEC [IPSEC] or TLS to
         authenticate and secure the channel between the PEP and the
         PDP.

      5. The protocol is stateful in two main aspects:  (1)
         Request/Decision state is shared between client and server and
         (2) State from various events (Request/Decision pairs) may be
         inter-associated. By (1) we mean that 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



Durham, et al.              Standards Track                     [Page 3]

RFC 2748                          COPS                      January 2000


         for a currently installed request state. By (2) we mean that
         the server may respond to new queries differently because of
         previously installed Request/Decision state(s) that are
         related.

      6. Additionally, the protocol is 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.

1.1 Basic Model

          +----------------+
          |                |
          |  Network Node  |            Policy Server
          |                |
          |   +-----+      |   COPS        +-----+
          |   | PEP |<-----|-------------->| PDP |
          |   +-----+      |               +-----+
          |    ^           |
          |    |           |
          |    \-->+-----+ |
          |        | LPDP| |
          |        +-----+ |
          |                |
          +----------------+

          Figure 1: A COPS illustration.


   Figure 1 Illustrates the layout of various policy components in a
   typical COPS example (taken from [WRK]). Here, COPS is used to
   communicate policy information between a Policy Enforcement Point
   (PEP) and a remote Policy Decision Point (PDP) within the context of
   a particular type of client. The optional Local Policy Decision Point
   (LPDP) can be used by the device to make local policy decisions in
   the absence of a PDP.

   It is assumed that each participating policy client is functionally
   consistent with a PEP [WRK]. The PEP may communicate with a policy
   server (herein referred to as a remote PDP [WRK]) to obtain policy
   decisions or directives.

   The PEP is responsible for initiating a persistent TCP connection to
   a PDP. The PEP uses this TCP connection to send requests to and
   receive decisions from the remote PDP. Communication between the PEP
   and remote PDP is mainly in the form of a stateful request/decision
   exchange, though the remote PDP may occasionally send unsolicited



Durham, et al.              Standards Track                     [Page 4]

RFC 2748                          COPS                      January 2000


   decisions to the PEP to force changes in previously approved request
   states. The PEP also has the capacity to report to the remote PDP
   that it has successfully completed performing the PDP's decision
   locally, useful for accounting and monitoring purposes. The PEP is
   responsible for notifying the PDP when a request state has changed on
   the PEP. Finally, the PEP is responsible for the deletion of any
   state that is no longer applicable due to events at the client or
   decisions issued by the server.

   When the PEP sends a configuration request, it expects the PDP to
   continuously send named units of configuration data to the PEP via
   decision messages as applicable for the configuration request. When a
   unit of named configuration data is successfully installed on the
   PEP, the PEP should send a report message to the PDP confirming the
   installation. The server may then update or remove the named
   configuration information via a new decision message. When the PDP
   sends a decision to remove named configuration data from the PEP, the
   PEP will delete the specified configuration and send a report message
   to the PDP as confirmation.

   The policy protocol is designed to communicate self-identifying
   objects which contain the data necessary for identifying request
   states, establishing the context for a request, identifying the type
   of request, referencing previously installed requests, relaying
   policy decisions, reporting errors, providing message integrity, and
   transferring client specific/namespace information.

   To distinguish between different kinds of clients, the type of client
   is identified in each message. Different types of clients may have
   different client specific data and may require different kinds of
   policy decisions. It is expected that each new client-type will have
   a corresponding usage draft specifying the specifics of its
   interaction with this policy protocol.

   The context of each request corresponds to the type of event that
   triggered it. The COPS Context object identifies the type of request
   and message (if applicable) that triggered a policy event via its
   message type and request type fields. COPS identifies three types of
   outsourcing events: (1) the arrival of an incoming message (2)
   allocation of local resources, and (3) the forwarding of an outgoing
   message. Each of these events may require different decisions to be
   made. The content of a COPS request/decision message depends on the
   context. A fourth type of request is useful for types of clients that
   wish to receive configuration information from the PDP. This allows a
   PEP to issue a configuration request for a specific named device or
   module that requires configuration information to be installed.





Durham, et al.              Standards Track                     [Page 5]

RFC 2748                          COPS                      January 2000


   The PEP may also have the capability to make a local policy decision
   via its Local Policy Decision Point (LPDP) [WRK], however, the PDP
   remains the authoritative decision point at all times. This means
   that the relevant local decision information must be relayed to the
   PDP. That is, the PDP must be granted access to all relevant
   information to make a final policy decision. To facilitate this
   functionality, the PEP must send its local decision information to
   the remote PDP via an LPDP decision object. The PEP must then abide
   by the PDP's decision as it is absolute.

   Finally, fault tolerance is a required capability for this protocol,
   particularly due to the fact it is associated with the security and
   service management of distributed network devices. Fault tolerance
   can be achieved by having both the PEP and remote PDP constantly
   verify their connection to each other via keep-alive messages. When a
   failure is detected, the PEP must try to reconnect to the remote PDP