RFC 3084
COPS Usage for Policy Provisioning (COPS-PR)
COPS Usage for Policy Provisioning (COPS-PR) 💖
okay bestie, the header facts first 🎀 This is RFC 3084 from the Network Working Group, dated March 2001. It's a Standards Track doc, so it's a real Internet standards track protocol spec 👑 It was written by nine people:
- K. Chan (Nortel Networks)
- J. Seligson (Nortel Networks)
- D. Durham (Intel)
- S. Gai (Cisco)
- K. McCloghrie (Cisco)
- S. Herzog (IPHighway)
- F. Reichmeyer (PFN)
- R. Yavatkar (Intel)
- A. Smith (Allegro Networks)
The title block doesn't list anything it obsoletes or updates, so there's nothing to flag there ✨
Status of this Memo 📜
this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Copyright Notice ©
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🌸
this doc describes how to use the Common Open Policy Service (COPS) protocol to support policy provisioning (COPS-PR) 🧚 It doesn't care what kind of policy is being provisioned (QoS, Security, etc.). Instead, it focuses on the mechanisms and conventions used to pass provisioned information between PDPs and PEPs. The protocol extensions here don't assume anything about the policy data model being communicated. They just describe the message formats and objects that carry the modeled policy data 💜
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] 🫶
Table of Contents 🗂️
Glossary........................................................... 3
1. Introduction.................................................... 3
1.1. Why COPS for Provisioning?.................................... 5
1.2. Interaction between the PEP and PDP........................... 5
2. Policy Information Base (PIB)................................... 6
2.1. Rules for Modifying and Extending PIBs........................ 7
2.2. Adding PRCs to, or deprecating from, a PIB.................... 7
2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC....... 8
2.3. COPS Operations Supported for a Provisioning Instance......... 8
3. Message Content................................................. 9
3.1. Request (REQ) PEP -> PDP..................................... 9
3.2. Decision (DEC) PDP -> PEP....................................10
3.3. Report State (RPT) PEP -> PDP................................12
4. COPS-PR Protocol Objects........................................13
4.1. Complete Provisioning Instance Identifier (PRID)..............14
4.2. Prefix PRID (PPRID)...........................................15
4.3. Encoded Provisioning Instance Data (EPD)......................16
4.4. Global Provisioning Error Object (GPERR)......................21
4.5. PRC Class Provisioning Error Object (CPERR)...................22
4.6. Error PRID Object (ErrorPRID).................................23
5. COPS-PR Client-Specific Data Formats............................23
5.1. Named Decision Data...........................................23
5.2. ClientSI Request Data.........................................24
5.3. Policy Provisioning Report Data...............................24
5.3.1. Success and Failure Report-Type Data Format.................24
5.3.2. Accounting Report-Type Data Format..........................25
6. Common Operation................................................26
7. Fault Tolerance.................................................28
8. Security Considerations.........................................29
9. IANA Considerations.............................................29
10. Acknowledgements...............................................30
11. References.....................................................30
12. Authors' Addresses.............................................32
13. Full Copyright Statement.......................................34Glossary 📖
PRC Provisioning Class. A type of policy data.
PRI Provisioning Instance. An instance of a PRC.
PIB Policy Information Base. The database of policy
information.
PDP Policy Decision Point. See [RAP].
PEP Policy Enforcement Point. See [RAP].
PRID Provisioning Instance Identifier. Uniquely identifies an
instance of a PRC.1. Introduction ✨
the IETF Resource Allocation Protocol (RAP) WG defined COPS (Common Open Policy Service) [COPS] as a scalable protocol. It lets policy servers (PDPs) send policy decisions to network devices (PEPs) 🍓 COPS was designed to support multiple types of policy clients, so it's pretty versatile 💅
COPS is a query/response protocol, and it supports two common models for policy control: Outsourcing and Configuration 🌈
the Outsourcing model is for the kind of events at the PEP that need an instant policy decision (authorization) ⚡ In this setup, the PEP hands responsibility over to an external policy server (PDP), which makes decisions on its behalf. For example, in COPS Usage for RSVP [COPRSVP], when an RSVP reservation message shows up, the PEP has to decide whether to admit or reject the request. It can outsource that decision by sending a specific query to its PDP and waiting for the answer before it admits the pending reservation 🫠
the COPS Configuration model (called the Provisioning model in this doc) is a totally different vibe 🎀 It doesn't assume any direct 1:1 link between PEP events and PDP decisions. The PDP can proactively provision the PEP in reaction to external events (like user input), PEP events, or any combination of those (N:M correlation) 🔥 Provisioning can happen in bulk (for example, an entire router QoS configuration) or in portions (for example, updating a DiffServ marking filter) 🧁
network resources are often provisioned based on relatively static SLAs (Service Level Agreements) at network boundaries 📐 The Outsourcing model is paced dynamically by the PEP in real time. The Provisioning model is paced by the PDP, with somewhat flexible timing, across a wide range of configurable aspects of the PEP 🕰️
Edge Device Policy Server
+--------------+ +-----------+ +-----------+
| | | | | External |
| | COPS | | | Events |
| +-----+ | REQ() | +-----+ | +---+-------+
| | |----|----------|->| | | |
| | PEP | | | | PDP |<-|---------+
| | |<---|----------|--| | |
| +-----+ | COPS | +-----+ |
| | DEC() | |
+--------------+ +-----------+
Figure 1: COPS Provisioning Modelin COPS-PR, policy requests describe the PEP and its configurable parameters, not an operational event 🦋 If a change happens in those basic parameters, an updated request gets sent. So requests go out pretty infrequently 🌙 Decisions aren't necessarily mapped directly to requests. They're mostly issued when the PDP responds to external events or PDP events (policy/SLA updates) ✨
this doc describes how to use the COPS protocol [COPS] for policy provisioning 💖 The spec doesn't depend on the type of policy being provisioned (QoS, Security, etc.). It focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The data model assumed here is built on the concept of Policy Information Bases (PIBs), which define the policy data. There may be one or more PIBs for a given area of policy, and different areas of policy may have different sets of PIBs 🧚
to support a model where multiple PDPs control non-overlapping areas of policy on a single PEP, the client-type the PEP specifies to the PDP is unique for the area of policy being managed 🎀 A single client-type for a given area of policy (e.g., QoS) gets used for all PIBs in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping, independent namespaces, where instances MUST NOT be shared 🙈
the examples in this doc are biased toward QoS Policy Provisioning in a Differentiated Services (DiffServ) environment 💜 But COPS-PR can be used for other types of provisioning policies under the same framework 🌈
1.1. Why COPS for Provisioning? 🫶
COPS-PR was designed within a framework that's optimized for efficiently provisioning policies across devices, based on the requirements defined in [RAP] 😭 First, COPS-PR allows for efficient transport of attributes, large atomic transactions of data, and efficient and flexible error reporting 👑 Second, it has a single connection between the policy client and server for each area of policy control identified by a COPS Client-Type. That 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, so it uses a state sharing/synchronization mechanism and exchanges differential updates only. If either the server or the client gets rebooted (or restarted), the other one knows about it quickly ⚡ Last, it's a real-time, event-driven communications mechanism that never requires polling between the PEP and PDP 💅
1.2. Interaction between the PEP and PDP ✨
okay so bestie, here's the boot-up story 🥹🎀 when a device powers on, it opens a COPS connection to its Primary PDP. Once that connection is up, the PEP sends a configuration request that describes itself: hardware type, software release, configuration info, all the good stuff 💅. The client can also tell the PDP the maximum COPS-PR message size it supports 📏.
Then the PDP sends down every provisioned policy that's currently relevant to that device 📥. The device maps those policies into its local QoS mechanisms and installs them 🔧. If things change on the PDP side so that the policies already in effect need to change, the PDP sends the changes (installs, updates, and/or deletes) to the PEP, and the PEP updates its local configuration to match 🔄✨
It's also giving reactive. If the device changes on its own (board removed, board added, new software installed, etc.) in a way the PEP's known policies don't cover, the PEP asynchronously sends that unsolicited news to the PDP in an updated configuration request 📨 The PDP then sends any extra provisioned policies the PEP now needs, and removes the ones that are no longer required 🧹💖
2. Policy Information Base (PIB) 🧠
okay the data COPS-PR carries is a set of policy data 📦 The protocol assumes a named data structure called a Policy Information Base (PIB). The PIB tells everyone the type and purpose of the unsolicited policy info that gets "pushed" from the PDP to the PEP for provisioning, or sent from the PEP to the PDP as a notification 💌
The PIB name space is shared by the PEP and the PDP. Data instances in that space are unique within a given Client-Type and Request-State, per TCP connection between a PEP and PDP 🔐 Also, a device might implement multiple COPS Client-Types, so each one gets its own unique instance space 🌈 There's no sharing of instance data across the Client-Types a PEP implements, even if the classes are the same type and share the same instance identifier 🙅♀️
Picture the PIB as a conceptual tree namespace 🌳 The branches are data structures, called Provisioning Classes (PRCs), and the leaves are the instantiations, called Provisioning Instances (PRIs). A PRC can have multiple PRIs 💫 For example, if you want several access control filters installed, the PRC could be a generic access control filter type, and each PRI is one specific filter being applied 🛡️ Here's the tree:
-------+-------+----------+---PRC--+--PRI
| | | +--PRI
| | |
| | +---PRC-----PRI
| |
| +---PRC--+--PRI
| +--PRI
| +--PRI
| +--PRI
| +--PRI
|
+---PRC---PRIFigure 2: The PIB Tree
Every PRI gets identified by a Provisioning Instance Identifier (PRID) 🪪 A PRID is a name, carried in a COPS <Named ClientSI> or <Named Decision Data> object, that points to one particular instance of a class 🎯
2.1. Rules for Modifying and Extending PIBs 🔧
As everyone gets more experienced with policy-based management, and new requirements show up, PIBs will need changes 📈 There are a few ways to change an existing PIB 👇
- Additional PRCs can be added to a PIB, or an existing one can be deprecated.
- Attributes can be added to, or deprecated from, an existing PRC.
- An existing PRC can be extended or augmented with a new PRC defined in another (perhaps enterprise specific) PIB.
The rules for each of these extension mechanisms are in this sub-section 📖 All of these ways of modifying a PIB allow PDPs and PEPs to stay interoperable, even when one side is on a new version of the PIB and the other is still on an old one 🤝
Note that the SPPI [SPPI] is the authority on updating BER encoded PIBs 👑 The next section explains how these changes affect the senders and receivers of COPS messages 💬
2.2. Adding PRCs to, or deprecating from, a PIB 🎀
A published PIB can be extended with new PRCs just by revising the document and adding more PRCs ✨ These new PRCs are easy to spot because they get new PRIDs under the module's PRID Prefix 🔖
Now the tricky bits 🙈 If a PEP running the new PIB is being configured by a PDP running the old PIB, the PEP will simply not receive any instances of the new PRC 🤷♀️ If it's the other way around, where the PEP runs the old PIB and the PDP runs the new one, the PEP may receive PRIs for the new PRC. In that case the PEP MUST return an error to the PDP, and roll back to its previous (good) state 🚨
Existing PRCs can also be deprecated from a PIB 🪦 When that happens, the PEP ignores any PRIs sent to it by a PDP running the old (non-deprecated) version of the PIB 🙃 A PDP running the new version simply doesn't send any instances of the deprecated class 🫶
2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC 💅
A PIB can be modified to deprecate existing attributes of a PRC, or to add new ones 🧩
Deprecating attributes needs a little extra care, bestie 🥺 With COPS-PR, the attributes of a PRC are identified by their order in the sequence, not by an explicit label (or attribute OID). So an ASN.1 value MUST be sent even for deprecated attributes, so that a PDP and PEP running different versions of the PIB can still interoperate 💖
For a deprecated attribute, if the PDP is using a BER encoded PIB, the PDP MUST send either an ASN.1 value of the correct type, or it may send an ASN.1 NULL value 🫧 A PEP that receives an ASN.1 NULL for an attribute that is not deprecated SHOULD substitute a default value 🪄 If it has no default value to substitute, it MUST return an error to the PDP 🙅♀️
When adding new attributes to a PIB, they must be added in sequence after the existing ones 📚 A PEP that receives a PRI with more attributes than it's expecting MUST ignore the additional attributes and send a warning back to the PDP ⚠️
A PEP that receives a PRI with fewer attributes than it's expecting SHOULD assume default values for the missing attributes 🧁 It MAY send a warning back to the PDP as well. If the missing attributes are required and there's no suitable default, the PEP MUST send an error back to the PDP 💀 In every case, the missing attributes are assumed to correspond to the last attributes of the PRC 🏁
2.3. COPS Operations Supported for a Provisioning Instance 🛠️
A Provisioning Instance (PRI) typically holds a value for each attribute defined for the PRC it's an instance of 📦 Within a given COPS Client-Type and Request-State on a PEP, it's identified uniquely by a Provisioning Instance Identifier (PRID) 🆔 These COPS operations are supported on a PRI 👇
- Install - This operation creates or updates a named instance of a PRC 🌸 It takes two parameters: a PRID object to name the PRI, and an Encoded Provisioning Instance Data (EPD) object with the new or updated values. The PRID value MUST uniquely identify a single PRI (i.e., PRID prefix or PRC values are illegal) 🚫 To update an existing PRI, you just reinstall the same PRID with the updated EPD data 🔁
- Remove - This operation deletes an instance of a PRC 🗑️ It takes one parameter, a PRID object, which names either the individual PRI to delete or a PRID prefix naming one or more complete classes of PRIs 🌧️ Prefix-based deletion supports efficient bulk policy removal, which is so iconic 👑 Removing an unknown or non-existent PRID SHOULD result in a warning to the PDP (no error) ⚠️
3. Message Content 💌
COPS lets different clients define their own "named" (client-specific) information for various messages 🎨 This section covers the messages exchanged between a COPS server (PDP) and COPS Policy Provisioning clients (PEP) that carry that client-specific data 💜 All the COPS messages used by COPS-PR conform to the message specifications defined in the COPS base protocol [COPS] 📜
Note: The use of the '*' character represented throughout this document is consistent with the ABNF [RFC2234] and means 0 or more of the following entities. 🧠
3.1. Request (REQ) PEP -> PDP ✨
okay so the REQ message is how policy provisioning clients send a 'configuration request' to the PDP, as set out in the COPS Context Object 💅 The Client Handle on a REQ that a provisioning client starts MUST be unique for that client 🎀 The handle is how the PDP tells one request state from another. One client can open a bunch of configuration request states, each with its own handle 🦋 Different request states keep similarly named configuration info in separate, non-overlapping namespaces. So an instance of named info is unique for a given client-type and for a given request state of that client-type, even if the same PRID shows up in another request state. That means the Client Handle is also part of how the configuration info gets identified 🧚
The configuration request is basically the PEP asking the PDP, "hey, what provisioning policy data do you have for me?" Think access control lists and stuff like that 🌸 It covers whatever policy the PDP has when the REQ shows up, plus any future policy data or updates to it 🔥
The configuration request should include provisioning client info so the PDP knows the client-specific configuration or capabilities of the PEP 🫶 That info should cover client resources (like queuing capabilities), default policy configuration (like default role combinations), and incarnation data on existing policy. It usually doesn't re-send everything the PDP already installed. Instead it carries checksums or shortened references to that old info, so the two sides can stay in sync 💜 This info helps the server decide what kinds of policy the PEP can install and enforce. The format of the info inside one or more COPS Named ClientSI objects is described in section 5 ✨ The configuration request gets generated and sent to the PDP as a response to a Synchronize State Request (SSQ) message from the PDP. An updated configuration request (using the same Client Handle as the original request it's updating) can also be generated and sent by the PEP at any time, because of local changes to its internal state 🦋 That way the PDP stays synchronized with the PEP's relevant internal state at all times 💖
The policy information the PDP sends back MUST be consistent with the named decision data defined for the policy provisioning client 🍓 The PDP answers the configuration request with a DEC message that holds any available provisioning policy data ✨
The REQ message looks like this 👑
<Request> ::= <Common Header>
<Client Handle>
<Context = config request>
*(<Named ClientSI>)
[<Integrity>]Quick note: the COPS objects IN-Int, OUT-Int and LPDPDecisions are NOT included in a COPS-PR Request 🙈
3.2. Decision (DEC) PDP -> PEP 💜
the DEC message is what the PDP sends to a policy provisioning client as a response to the REQ it got from the PEP 🌈 The Client Handle MUST be the same Handle that came in the matching REQ message 🫶
A DEC sent as an immediate answer to a configuration request has the solicited message flag set in the COPS message header 🔥 After that original DEC, more DEC messages can be sent whenever the PDP wants, to hand the PEP extra or updated policy info. Those ones don't have the solicited message flag set, since they're unsolicited decisions 💅
Each DEC can hold multiple decisions, so one message can install some policies and delete others at the same time 🎀 A single COPS-PR DEC message MUST contain any required remove decisions first, then any required install decisions 🍓 The ordering is there to fix a precedence issue, not a timing issue. The remove decision deletes what it names, except for items that get installed in that same message 🧚
The PDP can also use the DEC message to tell the PEP to open a new Request State or delete an existing one, identified by the Client-Handle 🦋 For this, COPS-PR adds a new flag to the COPS Decision Flags object. The flag 0x02 is for COPS-PR client-types and we'll call it the "Request-State" flag from here on ✨ An Install decision (Decision Flags: Command-Code=Install) with the Request-State flag set makes the PEP issue a new Request with a new Client Handle, or else report the right error in a COPS Report message 🌸 A Remove decision (Decision Flags: Command-Code=Remove) with the Request-State flag set makes the PEP send a COPS Delete Request State (DRQ) message for the Request-State named by the Client Handle in the DEC message 👑 Whenever the Request-State flag is set in the COPS Decision Flags object of a DEC, no COPS Named Decision Data object can be included in that decision, because it wouldn't do anything for this flag 🙈 Only one decision with the Request-State flag can be in a DEC message, and if it's there it MUST be the only decision in that message ⭐ As explained below, the PEP MUST respond to each and every DEC with a corresponding solicited RPT 💖
A COPS-PR DEC message MUST be treated as a single "transaction" 🔥 That means either every decision in the DEC succeeds or every one fails. If it fails, the PEP rolls back to its previous good state, which is the last successful DEC transaction (if there is one) 💅 That lets the PDP delete some policies only when other policies can be installed in their place 🦋
The DEC message looks like this 🎀
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
<Decision> ::= <Context>
<Decision: Flags>
[<Named Decision Data: Provisioning >]The Named Decision Data (Provisioning) object goes in a COPS-PR Decision when it's an Install or Remove decision with no Decision Flags set 🌸 Other kinds of COPS decision data objects (like Stateless or Replacement) aren't supported by COPS-PR client-types 🙈 The Named Decision Data object MUST NOT be included in the decision if the Decision Flags object's Command-Code is NULL (meaning there's no configuration info to install right now), or if the Request-State flag is set in the Decision Flags object 🚫
For each decision in the DEC message, the PEP does whatever the Command-Code and Flags field in the Decision Flags object says, using the Named Decision Data 🧚 For policy provisioning clients, the format of this data is defined in the context of the Policy Information Base (see section 5) ✨ In response to a DEC message, the policy provisioning client MUST send an RPT message back to the PDP, with the solicited message flag set, to tell the PDP what action was taken 👑
3.3. Report State (RPT) PEP -> PDP 🦋
the RPT message is how policy provisioning clients tell the PDP about accounting info tied to provisioned policy, or let it know about changes at the PEP (Report-Type = 'Accounting') related to the provisioning client 💅
RPT is also how the PEP tells the PDP what it did in response to a DEC message 🫶 For example, after an 'Install' decision, the PEP says whether the policy data was installed (Report-Type = 'Success') or not (Report-Type = 'Failure') 🌈 Reports that answer a DEC message MUST set the solicited message flag in their COPS message header 🔥 Each solicited RTP MUST be sent for its matching DEC, in the order the DEC messages came in 🍓 If a solicited failure happens, the PEP is expected to roll back to its previous (good) state, as if the bad DEC transaction never happened 💜 The PEP MUST always respond to a DEC with a solicited RPT, even for a NULL DEC, and in that case the Report-Type will be 'Success' ✨
Reports can also be unsolicited, and all unsolicited Reports MUST NOT set the solicited message flag in their COPS message header 🙈 Examples of unsolicited reports are 'Accounting' Report-Types (not triggered by any specific DEC message) and 'Failure' Report-Types, which flag a failure in a configuration that was installed successfully before 🧚 With unsolicited failures, the PEP can't roll back to a previous "good" state, because under these asynchronous conditions it becomes ambiguous what the correct state even is 😭
The RPT message can carry provisioning client info such as accounting parameters, or errors and warnings related to a decision 🌸 The format of that info is defined in the context of the policy information base (see section 5). The RPT message looks like this 👑
<Report State> ::= <Common Header>
<Client Handle>
<Report Type>
*(<Named ClientSI>)
[<Integrity>]4. COPS-PR Protocol Objects ✨
okay so bestie, this is where the COPS-PR clients get to show off 💅 They tuck a few brand-new objects inside the existing COPS Named Client-specific information object and Named Decision Data object. This section is the official blueprint for what those new objects look like 🎀
COPS-PR sorts policy data into "bindings" 🦋 A binding is a Provisioning Instance Identifier paired with the Provisioning Instance data, and that data gets encoded inside the provisioning policy information base (see section 5). Iconic organization, honestly 😭
Every new object follows this exact layout:
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num | S-Type |
+---------------+---------------+---------------+---------------+
| 32 bit unsigned integer |
+---------------+---------------+---------------+---------------+S-Num and S-Type are cousins of the C-Num and C-Type from the base COPS objects 👯♀️ The big difference is that they only belong to COPS-PR clients, and they ride inside the existing COPS Named ClientSI or Named Decision Data objects. S-Num tells you the general purpose of the object, and S-Type tells you the specific encoding it uses. Every object description and example in this document uses the Basic Encoding Rules, so that's S-Type = 1 🌸 Other encodings can be added for the remaining S-Types later. For instance, an S-Type could carry XML string based encodings [XML] as an EPD of PRI instance data, where URNs identify PRCs [URN] and XPointers would be used for PRIDs. The possibilities are literally wild 🧚
Length is a two-octet value that counts every octet in the object, header included 💖 If the length isn't a multiple of 32 bits, padding MUST be added to the end of the object so it lines up with the next 32-bit boundary before it goes out on the wire. On the receiving side, you find the next object boundary by rounding the current object's stated length up to the next 32-bit boundary. Easy peasy 🫶 And the padding values MUST be all zeros, no exceptions, no cap 🙈
4.1. Complete Provisioning Instance Identifier (PRID)
S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable.
This object carries the identifier, aka the PRID, of a Provisioning Instance ✨ The identifier gets encoded using the same rules defined for encoding SNMP Object Identifier (OID) values. Specifically, PRID values use the Type/Length/Value (TLV) format and the initial sub-identifier packing from the binary encoding rules [BER] that SNMP PDUs use for Object Identifiers. It's giving consistency 💅
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Instance Identifier |
+---------------+---------------+---------------+---------------+Here's a (fictitious) PRID equal to 1.3.6.1.2.2.8.1, encoded in hex:
06 07 2B 06 01 02 02 08 01And here's the whole PRID object, byte by byte 🦋
00 0D - Length
01 - S-Num
01 - S-Type (Complete PRID)
06 07 2B 06 01 02 02 08 01 - Encoded PRID
00 00 00 - PaddingNOTE: When encoding an xxxTable's xxxEntry Object-Type as defined by the SMI [V2SMI] and SPPI [SPPI], the OID will contain all the sub-identifiers up to and including the xxxEntry OID, but not the columnar identifiers for the attributes within the xxxEntry's SEQUENCE. The last (suffix) identifier is the INDEX of an instance of an entire xxxEntry, including its SEQUENCE of attributes encoded in the EPD (defined below). This constitutes an instance (PRI) of a class (PRC) in terms of the SMI. 🧠
For a scalar (non-columnar) value, the OID gets encoded directly as the PRC. The instance identifier suffix is always zero, because there's only ever one instance of a scalar value. The EPD then carries the scalar value itself 🌈
4.2. Prefix PRID (PPRID)
Some operations, like decision removal, can get optimized by specifying a PRID prefix. The idea is that the operation hits every PRI matching that prefix, like all instances of the same PRC 🍓 PRID prefix objects MUST only be used in the COPS protocol <Remove Decision> operation, where bulk removal with class prefixes can beat sending a whole pile of individual <Remove Decision> operations. Other COPS operations, e.g., <Install Decision> operations, always need individual PRID specification. Don't try to be sneaky with them, bestie 🙅♀️
S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable.
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PPRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
... ...
| Prefix PRID |
... ...
+---------------+---------------+---------------+---------------+Continuing our previous example, a prefix PRID equal to 1.3.6.1.2.2 encodes in hex like this:
06 05 2B 06 01 02 02And the entire PPRID object:
00 0B - Length
02 - S-Num = Prefix PRID
01 - S-Type = BER
06 05 2B 06 01 02 02 - Encoded Prefix PRID
00 - Padding4.3. Encoded Provisioning Instance Data (EPD) 💖
S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable.
okay so this one is the EPD, the Encoded Provisioning Instance Data 🎀 It carries the encoded value of a Provisioning Instance. The PRI value holds all of the individual attribute values that make up the class. That class corresponds to the SMI's xxxEntry Object-Type, which defines the SEQUENCE of attributes forming a table [V2SMI][SPPI]. Each attribute's value becomes its own TLV sub-component, encoded following the BER ✨ Also, the order of non-scalar (multiple) attributes inside the EPD is decided by their columnar OID suffix when they're defined in [V2SMI]. So the attribute with the smallest columnar OID suffix goes first, and the one with the highest columnar OID suffix goes last 🌈
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = EPD | S-Type = BER |
+---------------+---------------+---------------+---------------+
| BER Encoded PRI Value |
+---------------+---------------+---------------+---------------+Now for an example 🧚 Imagine a fictional definition of an IPv4 packet filter class, described with the SMI like this:
ipv4FilterIpFilter OBJECT IDENTIFIER ::= { someExampleOID 1 }
-- The IP Filter Table
ipv4FilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ipv4FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Filter definitions. A packet has to match all fields in
a filter. Wildcards may be specified for those fields
that are not relevant."
::= { ipv4FilterIpFilter 1 }
ipv4FilterEntry OBJECT-TYPE
SYNTAX Ipv4FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An instance of the filter class."
INDEX { ipv4FilterIndex }
::= { ipv4FilterTable 1 }
Ipv4FilterEntry ::= SEQUENCE {
ipv4FilterIndex Unsigned32,
ipv4FilterDstAddr IpAddress,
ipv4FilterDstAddrMask IpAddress,
ipv4FilterSrcAddr IpAddress,
ipv4FilterSrcAddrMask IpAddress,
ipv4FilterDscp Integer32,
ipv4FilterProtocol Integer32,
ipv4FilterDstL4PortMin Integer32,
ipv4FilterDstL4PortMax Integer32,
ipv4FilterSrcL4PortMin Integer32,
ipv4FilterSrcL4PortMax Integer32,
ipv4FilterPermit TruthValue
}
ipv4FilterIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An integer index to uniquely identify this filter among all
the filters."
::= { ipv4FilterEntry 1 }
ipv4FilterDstAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address to match against the packet's destination IP
address."
::= { ipv4FilterEntry 2 }
ipv4FilterDstAddrMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A mask for the matching of the destination IP address.
A zero bit in the mask means that the corresponding bit in
the address always matches."
::= { ipv4FilterEntry 3 }
ipv4FilterSrcAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address to match against the packet's source IP
address."
::= { ipv4FilterEntry 4 }
ipv4FilterSrcAddrMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A mask for the matching of the source IP address."
::= { ipv4FilterEntry 5 }
ipv4FilterDscp OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value that the DSCP in the packet can have and
match. A value of -1 indicates that a specific
DSCP value has not been defined and thus all DSCP values
are considered a match."
::= { ipv4FilterEntry 6 }
ipv4FilterProtocol OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP protocol to match against the packet's protocol.
A value of zero means match all."
::= { ipv4FilterEntry 7 }
ipv4FilterDstL4PortMin OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 destination
port number can have and match this filter."
::= { ipv4FilterEntry 8 }
ipv4FilterDstL4PortMax OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum value that the packet's layer 4 destination
port number can have and match this filter."
::= { ipv4FilterEntry 9 }
ipv4FilterSrcL4PortMin OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 source port
number can have and match this filter."
::= { ipv4FilterEntry 10 }
ipv4FilterSrcL4PortMax OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum value that the packet's layer 4 source port
number can have and match this filter."
::= { ipv4FilterEntry 11 }
ipv4FilterPermit OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If false, the evaluation is negated. That is, a
valid match will be evaluated as not a match and vice
versa."
::= { ipv4FilterEntry 12 }A fictional instance of that filter class could then be encoded like this 🦋
02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8
40 04 C0 39 01 05 :ipv4FilterDstAddr/IpAddress/Value = 192.57.1.5
40 04 FF FF FF FF :ipv4FilterDstMask/IpAddress/Value=255.255.255.255
40 04 00 00 00 00 :ipv4FilterSrcAddr/IpAddress/Value = 0.0.0.0
40 04 00 00 00 00 :ipv4FilterSrcMask/IpAddress/Value = 0.0.0.0
02 01 FF :ipv4FilterDscp/Integer32/Value = -1 (not used)
02 01 06 :ipv4FilterProtocol/Integer32/Value = 6 (TCP)
05 00 :ipv4FilterDstL4PortMin/NULL/not supported
05 00 :ipv4FilterDstL4PortMax/NULL/not supported
05 00 :ipv4FilterSrcL4PortMin/NULL/not supported
05 00 :ipv4FilterSrcL4PortMax/NULL/not supported
02 01 01 :ipv4FilterPermit/TruthValue/Value = 1 (true)And the whole EPD object for that instance would be encoded like this 💅
00 30 - Length
03 - S-Num = EPD
01 - S-Type = BER
02 01 08 - ipv4FilterIndex
40 04 C0 39 01 05 - ipv4FilterDstAddr
40 04 FF FF FF FF - ipv4FilterDstMask
40 04 00 00 00 00 - ipv4FilterSrcAddr
40 04 00 00 00 00 - ipv4FilterSrcMask
02 01 FF - ipv4FilterDscp
02 01 06 - ipv4FilterProtocol
05 00 - ipv4FilterDstL4PortMin
05 00 - ipv4FilterDstL4PortMax
05 00 - ipv4FilterSrcL4PortMin
05 00 - ipv4FilterSrcL4PortMax
02 01 01 - ipv4FilterPermitAttributes that aren't supported inside a class still show up in the EPD for a PRI 🙈 By convention, they come back as a NULL value. In the example above, the source and destination port number attributes are the unsupported ones, which is why they're NULL.
4.4. Global Provisioning Error Object (GPERR) 🚨
S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8.
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = GPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+Okay this one is the GPERR, the global provisioning error object 😭 It has the same format as the Error object in COPS [COPS], except the C-Num and C-Type are swapped out for the S-Num and S-Type values shown above. It's the object you use to report general errors that don't map to a specific PRC ✨
Here are the global error codes that are defined:
availMemLow(1)
availMemExhausted(2)
unknownASN.1Tag(3) - The erroneous tag type SHOULD be
specified in the Error Sub-Code field.
maxMsgSizeExceeded(4) - COPS message (transaction) was too big.
unknownError(5)
maxRequestStatesOpen(6)- No more Request-States can be created
by the PEP (in response to a DEC
message attempting to open a new
Request-State).
invalidASN.1Length(7) - An ASN.1 object length was incorrect.
invalidObjectPad(8) - Object was not properly padded.
unknownPIBData(9) - Some of the data supplied by the PDP is
unknown/unsupported by the PEP (but
otherwise formatted correctly). PRC
specific error codes are to be used to
provide more information.
unknownCOPSPRObject(10)- Sub-code (octet 2) contains unknown
object's S-Num and (octet 3) contains
unknown object's S-Type.
malformedDecision(11) - Decision could not be parsed.4.5. PRC Class Provisioning Error Object (CPERR) 🚨
okay so this one is the class-specific error object, bestie 🎀 it's giving "the error that knows exactly which PRC messed up" ✨ Its layout is the same as the Error object in COPS [COPS], except the C-Num and C-Type fields get swapped out for the S-Num and S-Type values shown here.
S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8.
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = CPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+This object is used to communicate errors about specific PRCs, and it MUST have an associated Error PRID Object 💖
Here are the Generic Class-Specific errors, all defined and ready to slay 💅
priSpaceExhausted(1) - no more instances may currently be
installed in the given class.
priInstanceInvalid(2) - the specified class instance is
currently invalid prohibiting
installation or removal.
attrValueInvalid(3) - the specified value for identified
attribute is illegal.
attrValueSupLimited(4) - the specified value for the identified
attribute is legal but not currently
supported by the device.
attrEnumSupLimited(5) - the specified enumeration for the
identified attribute is legal but not
currently supported by the device.
attrMaxLengthExceeded(6) - the overall length of the specified
value for the identified attribute
exceeds device limitations.
attrReferenceUnknown(7) - the class instance specified by the
policy instance identifier does not
exist.
priNotifyOnly(8) - the class is currently only supported
for use by request or report messages
prohibiting decision installation.
unknownPrc(9) - attempt to install a PRI of a class not
supported by PEP.
tooFewAttrs(10) - recvd PRI has fewer attributes than
required.
invalidAttrType(11) - recvd PRI has an attribute of the wrong
type.
deletedInRef(12) - deleted PRI is still referenced by
other (non) deleted PRIs
priSpecificError(13) - the Error Sub-code field contains the
PRC specific error codeWhere it makes sense (errors 3, 4, 5, 6, and 7 above), the error sub-code SHOULD identify the OID sub-identifier of the attribute tied to the error 🔥 That's the detail that makes it so easy to pinpoint the culprit.
4.6. Error PRID Object (ErrorPRID) 🦋
S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable.
This object carries the identifier, or PRID, of a Provisioning Instance that caused an installation error or couldn't be installed or removed 🥺 It's encoded and formatted exactly like the PRID object described in section 4.1, so no new tricks to learn, iykyk ✨
5. COPS-PR Client-Specific Data Formats 🌈
This section describes the format of the named client specific information for the COPS policy provisioning client. ClientSI formats are defined for the Decision message's Named Decision Data object, the Request message's Named ClientSI object, and the Report message's Named ClientSI object. The actual content of the data is defined by the policy information base for a specific provisioning client-type (see below) 🧚
5.1. Named Decision Data 💜
The formats wrapped by the Named Decision Data object depend on the type of decision, bestie. Install and Remove are the two decision types that dictate the internal format of the COPS Named Decision Data object, and they require its presence. Install and Remove refer to the 'Install' and 'Remove' Command-Code, respectively, specified in the COPS Decision Flags Object when no Decision Flags are set. The data is generally made up of one or more bindings, and each binding pairs a PRID object with an EPD object. The PRID object is always present in both install and remove decisions. The EPD object MUST be present for an install decision and MUST NOT be present for a remove decision 😭
The format for this data is wrapped inside the COPS Named Decision Data object like this:
<Named Decision Data> ::= <<Install Decision> |
<Remove Decision>>
<Install Decision> ::= *(<PRID> <EPD>)
<Remove Decision> ::= *(<PRID>|<PPRID>)Note that PRID objects in a Remove Decision may specify PRID prefix values. Explicit and implicit deletion of installed policies is supported by a client 👑 Install Decision data MUST be explicit, though. PRID prefix values are illegal there, and a client MUST reject them 🙅♀️
5.2. ClientSI Request Data 🎀
The provisioning client request data uses the same bindings we just covered. The format for this data is wrapped inside the COPS Named ClientSI object like so:
<Named ClientSI: Request> ::= <*(<PRID> <EPD>)>5.3. Policy Provisioning Report Data 🍓
The COPS Named ClientSI object gets used in the RPT message, together with the accompanying COPS Report Type object, to carry COPS-PR report information from the PEP to the PDP. Report types can be 'Success' or 'Failure', which tells the PDP that a set of provisioning policies was either installed or removed successfully or unsuccessfully on the PEP. There's also 'Accounting' 📊
5.3.1. Success and Failure Report-Type Data Format ✨
Success and Failure report types tell the PDP whether a particular set of provisioning policies was installed or removed successfully or unsuccessfully on the PEP. The report data is made of the bindings from above, plus global and specific error and warning info. Specific errors are tied to a particular instance. For a 'Success' Report-Type, a specific error is a warning about a policy that got installed but isn't fully implemented (for example, its parameters were approximated), and it's identified by the ErrorPRID object. For a 'Failure' Report-Type, it's an error code specific to a binding, again identified by the ErrorPRID object. Specific errors can also include regular <PRID><EPD> bindings to describe the warnings or errors more verbosely and tie them to the ErrorPRID object they belong to 💅
Global errors aren't tied to any specific ErrorPRID. In a 'Success' RPT message, a global error is a general warning at the PEP level (for example, memory low). In a 'Failure' RPT message, it's a general error at the PEP level (for example, memory exhausted) 😬
For a 'Failure' Report-Type, the PEP MUST report at least the first error and SHOULD report as many errors as possible. The PEP MUST also roll back its configuration to the last good transaction, which came before the erroneous Decision message was received 🫶
The format for this data is wrapped inside the COPS Named ClientSI object like this:
<Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
<report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)5.3.2. Accounting Report-Type Data Format 📈
Reports can also carry accounting info when they use the 'Accounting' Report-Type. This accounting report usually carries statistical or event information about the installed configuration, for use at the PDP. The info is encoded as one or more <PRID><EPD> bindings that generally describe what's being reported from the PEP to the PDP 🧁
The format for this data is wrapped inside the COPS Named ClientSI object like this:
<Named ClientSI: Report> ::= <*(<PRID><EPD>)>NOTE: RFC 2748 defines an optional Accounting-Timer (AcctTimer) object for use in the COPS Client-Accept message. Periodic accounting reports for COPS-PR clients are also obligated to be paced by this timer. Periodic accounting reports SHOULD NOT be generated by the PEP more frequently than the period specified by the COPS AcctTimer. Thus, the period between new accounting reports SHOULD be greater-than or equal-to the period specified (if specified) in the AcctTimer. If no AcctTimer object is specified by the PDP, then there are no constraints imposed on the PEP's accounting interval 🌸
6. Common Operation ✨
okay so this section is the typical back-and-forth between a PDP and a Policy Provisioning COPS client 🫶
first, a TCP connection gets set up between the client and server, and the PEP sends a Client-Open message naming a COPS-PR client-type (using the ClientSI object inside Client-Open is currently undefined for COPS-PR clients 🙈). if the PDP supports that client-type, it replies with a Client-Accept (CAT) message 💖. if it doesn't, the PDP sends a Client-Close (CC) message back to the PEP, and it might name an alternate server that's known to support the policy for that client-type 🦋
once the PEP gets the CAT, it can start sending requests 💅 the REQ from a policy provisioning client carries a COPS Configuration Request context object and, optionally, any relevant named client-specific info from the PEP ✨ that info should cover available client resources (like supported classes/attributes), default policy configuration, and incarnation data on existing policy. the config request has two jobs. first, it asks the PDP for any provisioning config it already has that suits the PEP (like access control filters, etc.), based on what the PEP put in its REQ. second, it opens a channel so the PDP can asynchronously push policy data to the PEP whenever the PDP decides it's needed, as long as the PEP keeps its request state open (aka as long as the PEP doesn't send a DRQ with that request state's Client Handle) 😭 that async data can be brand new policy or an update to something sent before. if the PEP's internal state changes, it lets the PDP know with an updated REQ 🌸 the PEP is free to send those updated REQs any time after a CAT.
after the PEP sends a REQ, if the PDP has Policy Provisioning config for the client, it comes back in a DEC message. that message holds the Policy Provisioning client policy data inside the COPS Named Decision Data object, with an "Install" Command-Code in the Decision Flags object ✨ if no filters are defined, the DEC just says there are none, using the "NULL Decision" Command-Code in the Decision Flags object. the PEP MUST specify a Client Handle in the request message, so the PDP MUST process the Client Handle and copy it into the matching decision message 🎀 a DEC MUST be issued by the PDP with the Solicited Message Flag set in the COPS message header, regardless of whether the PDP has any config for the PEP at that moment 💀 this is so the PEP doesn't time out the REQ and delete the Client Handle.
then the PDP can add new policy or update/delete existing configs by sending later unsolicited DEC messages to the PEP with the same Client Handle 🧚 updating older config works by re-installing the same instance of config again, which overwrites the old data 🍓 the PEP is responsible for removing the Client Handle when it's no longer needed (like when an interface goes down), and it tells the PDP that the Client Handle is to be deleted through the COPS DRQ message 💜
For Policy Provisioning purposes, access state and access requests to the policy server can be started by other sources besides the PEP 🌈 examples include attached users requesting network services through a web interface into a central management application, or H.323 servers requesting resources for a user in a video conferencing application. when a request like that gets accepted, the edge device affected by the decision (the point where the flow enters the network) needs to be told. since the PEP didn't start the request, the specifics (flowspec, packet filter, and PHB to apply) have to be sent to the PEP by the PDP 🔥 that info goes in a Decision message containing Policy Provisioning Named Decision Data objects in the COPS Decision object. any updates to the state info, like a policy change or a call tear down, get sent to the PEP in later unsolicited DEC messages with the same Client Handle and the updated Policy Provisioning request state. updates can say policy data is to be installed, deleted, or updated (re-installed) ✨
PDPs may also command the PEP to open a new Request State or delete an existing one by issuing a decision with the Decision Flags object's Request-State flag set 👑 if the command-code is "install", the PDP is telling the PEP to create a new Request State. the PEP then either issues a new REQ specifying a new Client Handle, or sends a "Failure" RPT with the appropriate error condition 😭 each request state is its own independent, logically non-overlapping namespace, identified by the Client Handle, where transactions (aka config installations, deletions, and updates) can be performed. other existing Request States are unaffected by the new one, since they're independent. no config inside one Request State can be affected by DECs for another Request State, as identified by the Client Handle 🦋 if the command-code is "Remove", the PDP is telling the PEP to delete the existing Request-State specified by the DEC message's Client Handle, which makes the PEP issue a DRQ for that Handle.
The PEP MUST acknowledge a DEC message and say what action was taken by sending a RPT message with a "Success" or "Failure" Report-Type object, with the Solicited Message Flag set in the COPS message header 🫶 this tells the PDP whether the requestor (e.g., an H.323 server) can be notified that the request was accepted by the network or not. if the PEP needs to reject the DEC for any reason, it sends a RPT with the Report-Type value "Failure", and optionally a Client Specific Information object specifying the policy data that got rejected 🙈 in those solicited report failure conditions, the PEP MUST always rollback to its previously installed (good) state, as if the DEC never happened. then the PDP is free to change its decision and try again 💅
The PEP can report the current status of any installed request state when it makes sense 📊 that info goes in a Report-State (RPT) message with the "Accounting" flag set, and the request state being reported is identified by its Client Handle in the report message.
Finally, Client-Close (CC) messages are used to cancel the matching Client-Open message 🥀 the CC tells the other side that the client-type specified is no longer supported 💔
7. Fault Tolerance 🛡️
so, when communication drops between the PEP and PDP, the PEP tries to re-establish the TCP connection with the PDP it was last connected to 🔄 if that server can't be reached, the PEP tries a secondary PDP, which is assumed to be manually configured (or otherwise known) at the PEP 🧭
once a connection is finally re-established with a PDP, the PEP sends an OPN message with a <LastPDPAddr> object giving the address of the most recent PDP it's still caching decisions for ✨ if no decisions are being cached on the PEP (because of a reboot or a TTL timeout of state), the PEP MUST NOT include the last PDP address info 🙅 based on this object, the PDP may ask the PEP to re-synch its current state info (by issuing a COPS SSQ message). if, after reconnecting, the PDP doesn't ask for synchronization, the client can assume the server recognizes it and the current state at the PEP is correct, so a REQ doesn't need to be sent 💅 still, any state changes that happened at the PEP and couldn't be communicated to the PDP (because communication was lost) MUST be reported to the PDP by the PEP sending an updated REQ message 🎀 whenever re-synchronization is requested, the PEP MUST reissue any REQ messages for all known Request-States, and the PDP MUST issue DEC messages to delete either individual PRIDs or prefixes, as appropriate, so the PEP ends up in a consistent known state 🧹
while the PEP is disconnected from the PDP, the active request-state at the PEP is what gets used for policy decisions 🫡 if the PEP can't re-connect within some pre-specified period of time, all installed Request-States get deleted and their associated Handles removed 💀 the same goes for the PDP: when it detects a failed TCP connection, a time-out timer starts for all Request-States associated with that PEP, and those states are removed after the administratively specified period without a connection ⏳
8. Security Considerations 🚨
okay this part is super important, so pay attention 👀 the COPS protocol [COPS], which this document derives from, describes the mandatory security mechanisms that MUST be supported by all COPS implementations 🔐 those mandatory mechanisms are what COPS uses to transfer opaque info from PEP to PDP and back again in an authenticated and secure way. COPS for Policy Provisioning just defines a structure for that opaque info, which COPS already carries ✨ so the security mechanisms described for COPS will also be deployed in a COPS-PR environment, which keeps the integrity of the COPS-PR info being communicated safe 💖
⚠️ bestie, here's the main catch: to fully describe a practical set of structured data for use with COPS-PR, a PIB (Policy Information Base) will likely be written in a separate document. the authors of that PIB document need to be aware of the security concerns tied to the specific data they've defined 😱
these concerns MUST be fully specified in the security considerations section of the PIB document, along with the required security mechanisms for transporting this newly defined data 🫣 no skipping this step, periodt 💅
9. IANA Considerations 💅
okay so COPS for Policy Provisioning follows the exact same IANA rules for COPS objects as the base COPS protocol [COPS] 🎀 COPS-PR adds one new Decision Flag value, 0x02, and that's the only thing it extends in the base protocol 🦋 No new COPS Client-Types are defined by this document, so nothing new there ✨
COPS-PR also gets its own object number space, where each object is identified by its S-Num and S-Type value pair 🧚 These objects ride inside the existing COPS Named ClientSI or Named Decision Data objects [COPS], which means they can't collide with any numbers already assigned in the COPS base protocol 🫶 New S-Num and S-Type pairs can only be added to COPS-PR through the IETF Consensus rule defined in [IANA] 💜 Also, these two numbers are always treated as a pair, with one or more S-Types for each S-Num 🌈 This document defines S-Num values 1-6, and S-Type 1 for each of those six values. Note that S-Type 2 is reserved for transporting XML encoded data 📚 You can find a full list of every S-Num and S-Type pair defined here in sections 4.1-4.6 🍓
Same deal for the error codes! New Global Provisioning error codes and Class-Specific Provisioning error codes can only be added with IETF Consensus 🔥 This document defines Global Provisioning error code values 1-11 in section 4.4 for the Global Provisioning Error Object (GPERR) 💖 It also defines Class-Specific error code values 1-13 in section 4.5 for the Class Provisioning Error Object (CPERR) ⭐
10. Acknowledgements 🫶
this doc came together with a LOT of help from a bunch of people 🥹 The authors want to give a special shout-out to Michael Fine, Scott Hahn, and Carol Bell for their super valuable input 💜 They're literally the reason this is as good as it is 👑
11. References 📚
okay bestie, here's the full reading list. I'm keeping every citation exactly as it's written 🎀
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy Based Admission Control", RFC 2753, January
2000.
[COPRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[ASN1] Information processing systems - Open Systems
Interconnection, "Specification of Abstract Syntax Notation
One (ASN.1)", International Organization for
Standardization, International Standard 8824, December
1987.
[BER] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Service," RFC
2475, December 1998.
[SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
Policy Provisioning Information SPPI", Work in Progress.
[V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2(SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[IANA] Alvestrand, H. and T. Narten, "Guidelines for writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[URN] Moats, R., "Uniform Resource Names (URN) Syntax", RFC 2141,
May 1997.
[XML] World Wide Web Consortium (W3C), "Extensible Markup
Language (XML)," W3C Recommendation, February, 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.12. Authors' Addresses 🌸
these are the brilliant people who wrote it, with all their contact details, exactly as they appear 💅
Kwok Ho Chan
Nortel Networks, Inc.
600 Technology Park Drive
Billerica, MA 01821
Phone: (978) 288-8175
EMail: khchan@nortelnetworks.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: (503) 264-6232
Email: david.durham@intel.com
Silvano Gai
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: (408) 527-2690
EMail: sgai@cisco.com
Shai Herzog
IPHighway Inc.
69 Milk Street, Suite 304
Westborough, MA 01581
Phone: (914) 654-4810
EMail: Herzog@iphighway.com
Keith McCloghrie
Phone: (408) 526-5260
EMail: kzm@cisco.com
Francis Reichmeyer
PFN, Inc.
University Park at MIT
26 Landsdowne Street
Cambridge, MA 02139
Phone: (617) 494 9980
EMail: franr@pfn.com
John Seligson
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95054
Phone: (408) 495-2992
Email: jseligso@nortelnetworks.com
Raj Yavatkar
Phone: (503) 264-9077
EMail: raj.yavatkar@intel.com
Andrew Smith
Allegro Networks
6399 San Ignacio Ave.
San Jose, CA 95119, USA
EMail: andrew@allegronetworks.com13. Full Copyright Statement 🎀
okay, legal bit, but I'm keeping every word of it because it matters 🙈 Here's the whole thing, verbatim:
Copyright (C) The Internet Society (2001). 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.Acknowledgement 💜
last but not least: funding for the RFC Editor function is currently provided by the Internet Society 🌈 ✨
📦 where this page comes from
- ietf: rfc3084 2001-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms