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].
AbstractThis 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.
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
7. References.....................................................35 8. Author Information and Acknowledgments.........................36 9. Full Copyright Statement.......................................38 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
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. 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
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.
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 or attempt to connect to a backup/alternative PDP. While disconnected, the PEP should revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any deleted state or new events that passed local admission control after the connection was lost. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued). After failure and before the new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some limited amount of time. Sections 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
The fields in the header are: Version: 4 bits COPS version number. Current version is 1. Flags: 4 bits Defined flag values (all other flags MUST be set to 0): 0x1 Solicited Message Flag Bit This flag is set when the message is solicited by another COPS message. This flag is NOT to be set (value=0) unless otherwise specified in section 3. Op Code: 8 bits The COPS operations: 1 = Request (REQ) 2 = Decision (DEC) 3 = Report State (RPT) 4 = Delete Request State (DRQ) 5 = Synchronize State Req (SSQ) 6 = Client-Open (OPN) 7 = Client-Accept (CAT) 8 = Client-Close (CC) 9 = Keep-Alive (KA) 10= Synchronize Complete (SSC) Client-type: 16 bits The Client-type identifies the policy client. Interpretation of all encapsulated objects is relative to the client-type. Client- types that set the most significant bit in the client-type field are enterprise specific (these are client-types 0x8000 - 0xFFFF). (See the specific client usage documents for particular client-type IDs). For KA Messages, the client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification). Message Length: 32 bits Size of message in octets, which includes the standard COPS header and all encapsulated objects. Messages MUST be aligned on 4 octet intervals.
Section 2.4 for details. C-Num = 1 C-Type = 1, Client Handle. Variable-length field, no implied format other than it is unique from other client handles from the same PEP (a.k.a. COPS TCP connection) for a particular client-type. It is always initially chosen by the PEP and then deleted by the PEP when no longer applicable. The client handle is used to refer to a request state initiated by a particular PEP and installed at the PDP for a client-type. A PEP will specify a client handle in its Request messages, Report messages and Delete messages sent to the PDP. In all cases, the client handle is used to uniquely identify a particular PEP's request for a client-type. The client handle value is set by the PEP and is opaque to the PDP. The PDP simply performs a byte-wise comparison on the value in this object with respect to the handle object values of other currently installed requests.
0 1 2 3 +--------------+--------------+--------------+--------------+ | R-Type | M-Type | +--------------+--------------+--------------+--------------+ R-Type (Request Type Flag) 0x01 = Incoming-Message/Admission Control request 0x02 = Resource-Allocation request 0x04 = Outgoing-Message request 0x08 = Configuration request M-Type (Message Type) Client Specific 16 bit values of protocol message types
C-Type = 2, IPv6 Address + Interface 0 1 2 3 +--------------+--------------+--------------+--------------+ | | + + | | + IPv6 Address format + | | + + | | +--------------+--------------+--------------+--------------+ | ifindex | +--------------+--------------+--------------+--------------+ For this type of the interface object, the IPv6 address specifies the IP address that the incoming message came from. The ifindex is used to refer to the MIB-II defined local incoming interface on the PEP as described above.
C-Type = 2, IPv6 Address + Interface Same C-Type format as the In-Interface object. For this type of the interface object, the IPv6 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
C-Num = 6 C-Type = 1, Decision Flags (Mandatory) 0 1 2 3 +--------------+--------------+--------------+--------------+ | Command-Code | Flags | +--------------+--------------+--------------+--------------+ Commands: 0 = NULL Decision (No configuration data available) 1 = Install (Admit request/Install configuration) 2 = Remove (Remove request/Remove configuration) Flags: 0x01 = Trigger Error (Trigger error message if set) Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages. Flag values not applicable to a given context's R-Type or client-type MUST be ignored by the PEP. C-Type = 2, Stateless Data This type of decision object carries additional stateless information that can be applied by the PEP locally. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. This object is optional in Decision messages and is interpreted relative to a given context. It is expected that even outsourcing PEPs will be able to make some simple stateless policy decisions locally in their LPDP. As this set is well known and implemented ubiquitously, PDPs are aware of it as well (either universally, through configuration, or using the Client-Open message). The PDP may also include this information in its decision, and the PEP MUST apply it to the resource allocation event that generated the request. C-Type = 3, Replacement Data This type of decision object carries replacement data that is to replace existing data in a signaled message. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
C-Type = 4, Client Specific Decision Data Additional decision types can be introduced using the Client Specific Decision Data Object. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context. C-Type = 5, Named Decision Data Named configuration information is encapsulated in this version of the decision object in response to configuration requests. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to both a given context and decision flags.
5 = Mandatory client-specific info missing 6 = Unsupported client-type 7 = Mandatory COPS object missing 8 = Client Failure 9 = Communication Failure 10= Unspecified 11= Shutting down 12= Redirect to Preferred Server 13= Unknown COPS Object: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type. 14= Authentication Failure 15= Authentication Required
Timer object used to specify the maximum time interval over which a COPS message MUST be sent or received. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity. 0 1 2 3 +--------------+--------------+--------------+--------------+ | ////////////// | KA Timer Value | +--------------+--------------+--------------+--------------+
C-Num = 13, C-Type = 1, IPv4 Address + TCP Port 0 1 2 3 +--------------+--------------+--------------+--------------+ | IPv4 Address format | +--------------+--------------+--------------+--------------+ | ///////////////////////// | TCP Port Number | +-----------------------------+-----------------------------+ C-Type = 2, IPv6 Address + TCP Port 0 1 2 3 +--------------+--------------+--------------+--------------+ | | + + | | + IPv6 Address format + | | + + | | +--------------+--------------+--------------+--------------+ | ///////////////////////// | TCP Port Number | +-----------------------------+-----------------------------+
Optional timer value used to determine the minimum interval between periodic accounting type reports. It is used by the PDP to describe to the PEP an acceptable interval between unsolicited accounting updates via Report messages where applicable. It provides a method for the PDP to control the amount of accounting traffic seen by the network. The range of finite time values is 1 to 65535 seconds represented as an unsigned two-octet integer. A value of zero means there SHOULD be no unsolicited accounting updates. 0 1 2 3 +--------------+--------------+--------------+--------------+ | ////////////// | ACCT Timer Value | +--------------+--------------+--------------+--------------+ HMAC] to calculate the message digest based on a key shared between the PEP and its PDP. This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular PEP and its PDP and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the PEP with corresponding keys on the PDP for the given PEPID. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 96-bits to calculate the message digest. This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is
sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero. The variable length digest is calculated over a COPS message starting with the COPS Header up to the Integrity Object (which MUST be the last object in a COPS message) INCLUDING the Integrity object's header, Key ID, and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Key ID | +-------------+-------------+-------------+-------------+ | Sequence Number | +-------------+-------------+-------------+-------------+ | | + + | ...Keyed Message Digest... | + + | | +-------------+-------------+-------------+-------------+ IANA]). The PEP is responsible for initiating the TCP connection to a PDP. The location of the remote PDP can either be configured, or obtained via a service location mechanism [SRVLOC]. Service discovery is outside the scope of this protocol, however. If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client- type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from
independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform. It is possible a single PEP may have open connections to multiple PDPs. This is the case when there are physically different PDPs supporting different client-types as shown in figure 2. +----------------+ | | | Network Node | Policy Servers | | | +-----+ | COPS Client Type 1 +-----+ | | |<-----|-------------------->| PDP1| | + PEP + | COPS Client Type 2 +-----+ | | |<-----|---------\ +-----+ | +-----+ | \----------| PDP2| | ^ | +-----+ | | | | \-->+-----+ | | | LPDP| | | +-----+ | | | +----------------+ Figure 2: Multiple PDPs illustration. When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type containing an <Error> object indicating the "Communication Failure" Error-Code. Additionally, the PEP SHOULD continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a <Client-Close> message containing a <PDPRedirAddr> object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
completing the synchronization process). If the PEP crashes and loses all cached state for a client-type, it will simply not include a <LastPDPAddr> in its Client-Open message.
The format of the Request message is as follows: <Request Message> ::= <Common Header> <Client Handle> <Context> [<IN-Int>] [<OUT-Int>] [<ClientSI(s)>] [<LPDPDecision(s)>] [<Integrity>] <ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI> <LPDPDecision(s)> ::= <LPDPDecision> | <LPDPDecision(s)> <LPDPDecision> <LPDPDecision> ::= [<Context>] <LPDPDecision: Flags> [<LPDPDecision: Stateless Data>] [<LPDPDecision: Replacement Data>] [<LPDPDecision: ClientSI Data>] [<LPDPDecision: Named Data>] The context object is used to determine the context within which all the other objects are to be interpreted. It also is used to determine the kind of decision to be returned from the policy server. This decision might be related to admission control, resource allocation, object forwarding and substitution, or configuration. The interface objects are used to determine the corresponding interface on which a signaling protocol message was received or is about to be sent. They are typically used if the client is participating along the path of a signaling protocol or if the client is requesting configuration data for a particular interface. ClientSI, the client specific information object, holds the client- type specific data for which a policy decision needs to be made. In the case of configuration, the Named ClientSI may include named information about the module, interface, or functionality to be configured. The ordering of multiple ClientSIs is not important. Finally, LPDPDecision object holds information regarding the local decision made by the LPDP. Malformed Request messages MUST result in the PDP specifying a Decision message with the appropriate error code.
Given the stateful nature of COPS, it is important that when a request state is finally removed from the PEP, a DRQ message for this request state is sent to the PDP so the corresponding state may likewise be removed on the PDP. Request states not explicitly deleted by the PEP will be maintained by the PDP until either the client session is closed or the connection is terminated. Malformed Decision messages MUST trigger a DRQ specifying the appropriate erroneous reason code (Bad Message Format) and any associated state on the PEP SHOULD either be removed or re-requested. If a Decision contained an unknown COPS Decision Object, the PEP MUST delete its request specifying the Unknown COPS Object reason code because the PEP will be unable to comply with the information contained in the unknown object. In any case, after issuing a DRQ, the PEP may retry the corresponding Request again.
<Client-Open> ::= <Common Header> <PEPID> [<ClientSI>] [<LastPDPAddr>] [<Integrity>] The PEPID is a symbolic, variable length name that uniquely identifies the specific client to the PDP (see Section 2.2.11). A named ClientSI object can be included for relaying additional global information about the PEP to the PDP when required (as specified in the appropriate extensions document for the client- type). The PEP may also provide a Last PDP Address object in its Client-Open message specifying the last PDP (for the given client-type) for which it is still caching decisions since its last reboot. A PDP can use this information to determine the appropriate synchronization behavior (See section 2.5). If the PDP receives a malformed Client-Open message it MUST generate a Client-Close message specifying the appropriate error code.
In general, accounting type Report messages are sent to the PDP when determined appropriate by the PEP. The accounting timer merely is used by the PDP to keep the rate of such updates in check (i.e. Preventing the PEP from blasting the PDP with accounting reports). Not including this object implies there are no PDP restrictions on the rate at which accounting updates are generated. If the PEP receives a malformed Client-Accept message it MUST generate a Client-Close message specifying the appropriate error code.
Both client and server MAY assume the TCP connection is insufficient for the client-type with the minimum time value (specified in the CAT message) if no communication activity is detected for a period exceeding the timer period. For the PEP, such detection implies the remote PDP or connection is down and the PEP SHOULD now attempt to use an alternative/backup PDP. section 4.3 and will not include the Integrity object in any COPS messages. Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the
PDP to increment during subsequent communication after the initial Client-Open/Client-Accept exchange and the Key ID identifying the algorithm and key used to compute the digest. Similarly, if the PDP accepts the PEP's security key and algorithm by validating the message digest using the identified key, the PDP MUST send a Client-Accept message with a Client-Type of zero to the PEP carrying an Integrity object. This Integrity object will contain the initial sequence number the PDP requires the PEP to increment during all subsequent communication with the PDP and the Key ID identifying the key and algorithm used to compute the digest. If the PEP, from the perspective of a PDP that requires security, fails or never performs the security negotiation by not sending an initial Client-Open message with a Client-Type=0 including a valid Integrity object, the PDP MUST send to the PEP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Similarly, if the PDP, from the perspective of a PEP that requires security, fails the security negotiation by not sending back a Client-Accept message with a Client-Type=0 including a valid Integrity object, the PEP MUST send to the PDP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Such a Client-Close message need not carry an integrity object (as the security negotiation did not yet complete). The security initialization can fail for one of several reasons: 1. The side receiving the message requires COPS level security but an Integrity object was not provided (Authentication Required error code). 2. A COPS Integrity object was provided, but with an unknown/unacceptable C-Type (Unknown COPS Object error code specifying the unsupported C-Num and C-Type). 3. The message digest or Key ID in the provided Integrity object was incorrect and therefore the message could not be authenticated using the identified key (Authentication Failure error code). Once the initial security negotiation is complete, the PEP will know what sequence numbers the PDP expects and the PDP will know what sequence numbers the PEP expects. ALL COPS messages must then include the negotiated Integrity object specifying the correct sequence number with the appropriate message digest (including the Client- Open/Client-Accept messages for specific Client-Types). ALL subsequent messages from the PDP to the PEP MUST result in an increment of the sequence number provided by the PEP in the Integrity object of the initial Client-Open message. Likewise, ALL subsequent messages from the PEP to the PDP MUST result in an increment of the sequence number provided by the PDP in the Integrity object of the initial Client-Accept message. Sequence numbers are incremented by one starting with the corresponding initial sequence number. For
example, if the sequence number specified to the PEP by the PDP in the initial Client-Accept was 10, the next message the PEP sends to the PDP will provide an Integrity object with a sequence number of 11... Then the next message the PEP sends to the PDP will have a sequence number of 12 and so on. If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped. HMAC][MD5] cryptographic algorithm for computing a message digest for inclusion in the Keyed Message Digest of the Integrity object which is appended to the message. It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not. Section 2.5). Each Client-Open message MUST at least contain the common header noting one client-type
supported by the PEP. The remote PDP will then respond with separate Client-Accept messages for each of the client-types requested by the PEP that the PDP can also support. If a specific client-type is not supported by the PDP, the PDP will instead respond with a Client-Close specifying the client-type is not supported and will possibly suggest an alternate PDP address and port. Otherwise, the PDP will send a Client-Accept specifying the timer interval between keep-alive messages and the PEP may begin issuing requests to the PDP.
the remove configuration command. The PEP SHOULD then proceed to remove the corresponding configuration and send a report message to the PDP that specifies it has been deleted. In all cases, the PEP MAY notify the remote PDP of the local status of an installed state using the report message where appropriate. The report message is to be used to signify when billing can begin, what actions were taken, or to produce periodic updates for monitoring and accounting purposes depending on the client. This message can carry client specific information when needed.
ID) shared between the PEP and its PDP. The key is used in conjunction with the contents of a COPS message to calculate a message digest that is part of the Integrity object. The Integrity object is then used to validate all COPS messages sent over the TCP connection between a PEP and PDP. Key maintenance is outside the scope of this document beyond the specific requirements discussed in section 4.2. In general, it is good practice to regularly change keys to maintain security. Furthermore, it is good practice to use localized keys specific to a particular PEP such that a stolen PEP will not compromise the security of an entire administrative domain. The COPS Integrity object also provides sequence numbers to avoid replay attacks. The PDP chooses the initial sequence number for the PEP and the PEP chooses the initial sequence number for the PDP. These initial numbers are then incremented with each successive message sent over the connection in the corresponding direction. The initial sequence numbers SHOULD be chosen such that they are monotonically increasing and never repeat for a particular key. Security between the client (PEP) and server (PDP) MAY be provided by IP Security [IPSEC]. In this case, the IPSEC Authentication Header (AH) SHOULD be used for the validation of the connection; additionally IPSEC Encapsulation Security Payload (ESP) MAY be used to provide both validation and secrecy. Transport Layer Security [TLS] MAY be used for both connection-level validation and privacy. IANA- CONSIDERATIONS]. These values MUST be registered with IANA and their behavior and applicability MUST be described in a COPS extension document. Client-type values in the range 0x4000 - 0x7FFF are reserved for Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types are not tracked by IANA and are not to be used in standards or general-release products, as their uniqueness cannot be assured. Client-type values in the range 0x8000 - 0xFFFF are First Come First Served as defined in [IANA-CONSIDERATIONS]. These Client-types are tracked by IANA but do not require published documents describing their use. IANA merely assures their uniqueness.
Objects in the COPS Protocol are identified by their C-Num and C-Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is required to introduce new values for these numbers and, therefore, new objects into the base COPS protocol. Additional Context Object R-Types, Reason-Codes, Report-Types, Decision Object Command-Codes/Flags, and Error-Codes MAY be defined for use with future Client-types, but such additions require IETF Consensus as defined in [IANA-CONSIDERATIONS]. Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be defined relative to a particular Client-type following the same IANA considerations as their respective Client-type. [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997. [WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC 2753, January 2000. [SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol , Version 2", RFC 2608, June 1999. [INSCH] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, August 1995. [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [IANA] http://www.isi.edu/in- notes/iana/assignments/port-numbers [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Raju Rajan AT&T Shannon Laboratory 180 Park Avenue P.O. Box 971 Florham Park, NJ 07932-0971 EMail: firstname.lastname@example.org Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701 Phone: 508.620.1141 EMail: email@example.com Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK Phone: +44-208-756-8693 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.