idnits 2.17.1 draft-ietf-rap-cops-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 1999) is 8937 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 44, but not defined == Missing Reference: 'SRVLOC' is mentioned on line 887, but not defined == Unused Reference: 'INSCH' is defined on line 1621, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'WRK') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Boyle 2 Expiration: April 2000 Level 3 3 File: draft-ietf-rap-cops-08.txt Ron Cohen 4 Cisco 5 Editor: David Durham 6 Intel 7 Shai Herzog 8 IPHighway 9 Raju Rajan 10 AT&T 11 Arun Sastry 12 Cisco 14 The COPS (Common Open Policy Service) Protocol 16 Last Updated: November 6, 1999 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC-2119]. 45 Status of this Memo................................................1 46 Conventions used in this document..................................1 47 Abstract...........................................................3 48 1. Introduction....................................................3 49 1.1 Basic Model....................................................4 50 2. The Protocol....................................................7 51 2.1 Common Header..................................................7 52 2.2 COPS Specific Object Formats...................................8 53 2.2.1 Handle Object (Handle).......................................9 54 2.2.2 Context Object (Context).....................................9 55 2.2.3 In-Interface Object (IN-Int)................................10 56 2.2.4 Out-Interface Object (OUT-Int)..............................11 57 2.2.5 Reason Object (Reason)......................................12 58 2.2.6 Decision Object (Decision)..................................12 59 2.2.7 LPDP Decision Object (LPDPDecision).........................14 60 2.2.8 Error Object (Error)........................................14 61 2.2.9 Client Specific Information Object (ClientSI)...............14 62 2.2.10 Keep-Alive Timer Object (KATimer)..........................15 63 2.2.11 PEP Identification Object (PEPID)..........................15 64 2.2.12 Report-Type Object (Report-Type)...........................15 65 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 66 2.2.14 Last PDP Address (LastPDPAddr).............................16 67 2.2.15 Accounting Timer Object (AcctTimer)........................17 68 2.2.16 Message Integrity Object (Integrity).......................17 69 2.3 Communication.................................................18 70 2.4 Client Handle Usage...........................................19 71 2.5 Synchronization Behavior......................................20 72 3. Message Content................................................21 73 3.1 Request (REQ) PEP -> PDP.....................................21 74 3.2 Decision (DEC) PDP -> PEP....................................22 75 3.3 Report State (RPT) PEP -> PDP................................23 76 3.4 Delete Request State (DRQ) PEP -> PDP........................23 77 3.5 Synchronize State Request (SSQ) PDP -> PEP...................24 78 3.6 Client-Open (OPN) PEP -> PDP.................................25 79 3.7 Client-Accept (CAT) PDP -> PEP...............................25 80 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................26 81 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................26 82 3.10 Synchronize State Complete (SSC) PEP -> PDP..................27 83 4. Common Operation...............................................28 84 4.1 Security and Sequence Number Negotiation......................28 85 4.2 Key Maintenance...............................................29 86 4.3 PEP Initialization............................................30 87 4.4 Outsourcing Operations........................................30 88 4.5 Configuration Operations......................................31 89 4.6 Keep-Alive Operations.........................................31 90 4.7 PEP/PDP Close.................................................31 91 5. Security Considerations........................................32 92 6. IANA Considerations............................................33 93 7. References.....................................................34 94 8. Author Information and Acknowledgments.........................35 96 Abstract 98 This document describes a simple client/server model for supporting 99 policy control over QoS signaling protocols. The model does not make 100 any assumptions about the methods of the policy server, but is based 101 on the server returning decisions to policy requests. The model is 102 designed to be extensible so that other kinds of policy clients may 103 be supported in the future. However, this document makes no claims 104 that it is the only or the preferred approach for enforcing future 105 types of policies. 107 1. Introduction 109 This document describes a simple query and response protocol that 110 can be used to exchange policy information between a policy server 111 (Policy Decision Point or PDP) and its clients (Policy Enforcement 112 Points or PEPs). One example of a policy client is an RSVP router 113 that must exercise policy-based admission control over RSVP usage 114 [RSVP]. We assume that at least one policy server exists in each 115 controlled administrative domain. The basic model of interaction 116 between a policy server and its clients is compatible with 117 the framework document for policy based admission control [WRK]. 119 A chief objective of this policy control protocol is to begin with a 120 simple but extensible design. The main characteristics of the COPS 121 protocol include: 123 1. The protocol employs a client/server model where the PEP 124 sends requests, updates, and deletes to the remote PDP and the 125 PDP returns decisions back to the PEP. 127 2. The protocol uses TCP as its transport protocol for reliable 128 exchange of messages between policy clients and a server. 129 Therefore, no additional mechanisms are necessary for reliable 130 communication between a server and its clients. 132 3. The protocol is extensible in that it is designed to leverage 133 off self-identifying objects and can support diverse client 134 specific information without requiring modifications to the COPS 135 protocol itself. The protocol was created for the general 136 administration, configuration, and enforcement of policies. 138 4. COPS provides message level security for authentication, 139 replay protection, and message integrity. COPS can also reuse 140 existing protocols for security such as IPSEC [IPSEC] or TLS to 141 authenticate and secure the channel between the PEP and the PDP. 143 5. The protocol is stateful in two main aspects: 144 (1) Request/Decision state is shared between client and server 145 and (2) State from various events (Request/Decision pairs) may 146 be inter-associated. By (1) we mean that requests from the 147 client PEP are installed or remembered by the remote PDP until 148 they are explicitly deleted by the PEP. At the same time, 149 Decisions from the remote PDP can be generated asynchronously at 150 any time for a currently installed request state. By (2) we mean 151 that the server may respond to new queries differently because 152 of previously installed Request/Decision state(s) that are 153 related. 155 6. Additionally, the protocol is stateful in that it allows the 156 server to push configuration information to the client, and then 157 allows the server to remove such state from the client when it 158 is no longer applicable. 160 1.1 Basic Model 162 +----------------+ 163 | | 164 | Network Node | Policy Server 165 | | 166 | +-----+ | COPS +-----+ 167 | | PEP |<-----|-------------->| PDP | 168 | +-----+ | +-----+ 169 | ^ | 170 | | | 171 | \-->+-----+ | 172 | | LPDP| | 173 | +-----+ | 174 | | 175 +----------------+ 177 Figure 1: A COPS illustration. 179 Figure 1 Illustrates the layout of various policy components in a 180 typical COPS example (taken from [WRK]). Here, COPS is used to 181 communicate policy information between a Policy Enforcement Point 182 (PEP) and a remote Policy Decision Point (PDP) within the context of 183 a particular type of client. The optional Local Policy Decision 184 Point (LPDP) can be used by the device to make local policy 185 decisions in the absence of a PDP. 187 It is assumed that each participating policy client is functionally 188 consistent with a PEP [WRK]. The PEP may communicate with a policy 189 server (herein referred to as a remote PDP [WRK]) to obtain policy 190 decisions or directives. 192 The PEP is responsible for initiating a persistent TCP connection to 193 a PDP. The PEP uses this TCP connection to send requests to and 194 receive decisions from the remote PDP. Communication between the PEP 195 and remote PDP is mainly in the form of a stateful request/decision 196 exchange, though the remote PDP may occasionally send unsolicited 197 decisions to the PEP to force changes in previously approved request 198 states. The PEP also has the capacity to report to the remote PDP 199 that it has successfully completed performing the PDP's decision 200 locally, useful for accounting and monitoring purposes. The PEP is 201 responsible for notifying the PDP when a request state has changed 202 on the PEP. Finally, the PEP is responsible for the deletion of any 203 state that is no longer applicable due to events at the client or 204 decisions issued by the server. 206 When the PEP sends a configuration request, it expects the PDP to 207 continuously send named units of configuration data to the PEP via 208 decision messages as applicable for the configuration request. When 209 a unit of named configuration data is successfully installed on the 210 PEP, the PEP should send a report message to the PDP confirming the 211 installation. The server may then update or remove the named 212 configuration information via a new decision message. When the PDP 213 sends a decision to remove named configuration data from the PEP, 214 the PEP will delete the specified configuration and send a report 215 message to the PDP as confirmation. 217 The policy protocol is designed to communicate self-identifying 218 objects which contain the data necessary for identifying request 219 states, establishing the context for a request, identifying the type 220 of request, referencing previously installed requests, relaying 221 policy decisions, reporting errors, providing message integrity, and 222 transferring client specific/namespace information. 224 To distinguish between different kinds of clients, the type of 225 client is identified in each message. Different types of clients may 226 have different client specific data and may require different kinds 227 of policy decisions. It is expected that each new client-type will 228 have a corresponding usage draft specifying the specifics of its 229 interaction with this policy protocol. 231 The context of each request corresponds to the type of event that 232 triggered it. The COPS Context object identifies the type of request 233 and message (if applicable) that triggered a policy event via its 234 message type and request type fields. COPS identifies three types of 235 outsourcing events: (1) the arrival of an incoming message (2) 236 allocation of local resources, and (3) the forwarding of an outgoing 237 message. Each of these events may require different decisions to be 238 made. The content of a COPS request/decision message depends on the 239 context. A fourth type of request is useful for types of clients 240 that wish to receive configuration information from the PDP. This 241 allows a PEP to issue a configuration request for a specific named 242 device or module that requires configuration information to be 243 installed. 245 The PEP may also have the capability to make a local policy decision 246 via its Local Policy Decision Point (LPDP) [WRK], however, the PDP 247 remains the authoritative decision point at all times. This means 248 that the relevant local decision information must be relayed to the 249 PDP. That is, the PDP must be granted access to all relevant 250 information to make a final policy decision. To facilitate this 251 functionality, the PEP must send its local decision information to 252 the remote PDP via an LPDP decision object. The PEP must then abide 253 by the PDP's decision as it is absolute. 255 Finally, fault tolerance is a required capability for this protocol, 256 particularly due to the fact it is associated with the security and 257 service management of distributed network devices. Fault tolerance 258 can be achieved by having both the PEP and remote PDP constantly 259 verify their connection to each other via keep-alive messages. When 260 a failure is detected, the PEP must try to reconnect to the remote 261 PDP or attempt to connect to a backup/alternative PDP. While 262 disconnected, the PEP should revert to making local decisions. Once 263 a connection is reestablished, the PEP is expected to notify the PDP 264 of any deleted state or new events that passed local admission 265 control after the connection was lost. Additionally, the remote PDP 266 may request that all the PEP's internal state be resynchronized (all 267 previously installed requests are to be reissued). After failure and 268 before the new connection is fully functional, disruption of service 269 can be minimized if the PEP caches previously communicated decisions 270 and continues to use them for some limited amount of time. Sections 271 2.3 and 2.5 detail COPS mechanisms for achieving reliability. 273 2. The Protocol 275 This section describes the message formats and objects exchanged 276 between the PEP and remote PDP. 278 2.1 Common Header 280 Each COPS message consists of the COPS header followed by a number 281 of typed objects. 283 0 1 2 3 284 +--------------+--------------+--------------+--------------+ 285 |Version| Flags| Op Code | Client-type | 286 +--------------+--------------+--------------+--------------+ 287 | Message Length | 288 +--------------+--------------+--------------+--------------+ 290 Global note: //// implies field is reserved, set to 0. 292 The fields in the header are: 293 Version: 4 bits 294 COPS version number. Current version is 1. 296 Flags: 4 bits 297 Defined flag values (all other flags MUST be set to 0): 298 0x1 Solicited Message Flag Bit 299 This flag is set when the message is solicited by 300 another COPS message. This flag is NOT to be set 301 (value=0) unless otherwise specified in section 3. 303 Op Code: 8 bits 304 The COPS operations: 305 1 = Request (REQ) 306 2 = Decision (DEC) 307 3 = Report State (RPT) 308 4 = Delete Request State (DRQ) 309 5 = Synchronize State Req (SSQ) 310 6 = Client-Open (OPN) 311 7 = Client-Accept (CAT) 312 8 = Client-Close (CC) 313 9 = Keep-Alive (KA) 314 10= Synchronize Complete (SSC) 316 Client-type: 16 bits 318 The Client-type identifies the policy client. Interpretation of 319 all encapsulated objects is relative to the client-type. Client- 320 types that set the most significant bit in the client-type field 321 are enterprise specific (these are client-types 0x8000 - 322 0xFFFF). (See the specific client usage documents for particular 323 client-type IDs). For KA Messages, the client-type in the header 324 MUST always be set to 0 as the KA is used for connection 325 verification (not per client session verification). 327 Message Length: 32 bits 328 Size of message in octets, which includes the standard COPS 329 header and all encapsulated objects. Messages MUST be aligned on 330 4 octet intervals. 332 2.2 COPS Specific Object Formats 334 All the objects follow the same object format; each object consists 335 of one or more 32-bit words with a four-octet header, using the 336 following format: 338 0 1 2 3 339 +-------------+-------------+-------------+-------------+ 340 | Length (octets) | C-Num | C-Type | 341 +-------------+-------------+-------------+-------------+ 342 | | 343 // (Object contents) // 344 | | 345 +-------------+-------------+-------------+-------------+ 347 The length is a two-octet value that describes the number of octets 348 (including the header) that compose the object. If the length in 349 octets does not fall on a 32-bit word boundary, padding MUST be 350 added to the end of the object so that it is aligned to the next 32- 351 bit boundary before the object can be sent on the wire. On the 352 receiving side, a subsequent object boundary can be found by simply 353 rounding up the previous stated object length to the next 32-bit 354 boundary. 356 Typically, C-Num identifies the class of information contained in 357 the object, and the C-Type identifies the subtype or version of the 358 information contained in the object. 360 C-num: 8 bits 361 1 = Handle 362 2 = Context 363 3 = In Interface 364 4 = Out Interface 365 5 = Reason code 366 6 = Decision 367 7 = LPDP Decision 368 8 = Error 369 9 = Client Specific Info 370 10 = Keep-Alive Timer 371 11 = PEP Identification 372 12 = Report Type 373 13 = PDP Redirect Address 374 14 = Last PDP Address 375 15 = Accounting Timer 376 16 = Message Integrity 378 C-type: 8 bits 379 Values defined per C-num. 381 2.2.1 Handle Object (Handle) 383 The Handle Object encapsulates a unique value that identifies an 384 installed state. This identification is used by most COPS 385 operations. A state corresponding to a handle MUST be explicitly 386 deleted when it is no longer applicable. See Section 2.4 for 387 details. 389 C-Num = 1 391 C-Type = 1, Client Handle. 393 Variable-length field, no implied format other than it is unique 394 from other client handles from the same PEP (a.k.a. COPS TCP 395 connection) for a particular client-type. It is always initially 396 chosen by the PEP and then deleted by the PEP when no longer 397 applicable. The client handle is used to refer to a request state 398 initiated by a particular PEP and installed at the PDP for a client- 399 type. A PEP will specify a client handle in its Request messages, 400 Report messages and Delete messages sent to the PDP. In all cases, 401 the client handle is used to uniquely identify a particular PEP's 402 request for a client-type. 404 The client handle value is set by the PEP and is opaque to the PDP. 405 The PDP simply performs a byte-wise comparison on the value in this 406 object with respect to the handle object values of other currently 407 installed requests. 409 2.2.2 Context Object (Context) 411 Specifies the type of event(s) that triggered the query. Required 412 for request messages. Admission control, resource allocation, and 413 forwarding requests are all amenable to client-types that outsource 414 their decision making facility to the PDP. For applicable client- 415 types a PEP can also make a request to receive named configuration 416 information from the PDP. This named configuration data may be in a 417 form useful for setting system attributes on a PEP, or it may be in 418 the form of policy rules that are to be directly verified by the 419 PEP. 421 Multiple flags can be set for the same request. This is only 422 allowed, however, if the set of client specific information in the 423 combined request is identical to the client specific information 424 that would be specified if individual requests were made for each 425 specified flag. 427 C-num = 2, C-Type = 1 429 0 1 2 3 430 +--------------+--------------+--------------+--------------+ 431 | R-Type | M-Type | 432 +--------------+--------------+--------------+--------------+ 434 R-Type (Request Type Flag) 436 0x01 = Incoming-Message/Admission Control request 437 0x02 = Resource-Allocation request 438 0x04 = Outgoing-Message request 439 0x08 = Configuration request 441 M-Type (Message Type) 443 Client Specific 16 bit values of protocol message types 445 2.2.3 In-Interface Object (IN-Int) 447 The In-Interface Object is used to identify the incoming interface 448 on which a particular request applies and the address where the 449 received message originated. For flows or messages generated from 450 the PEP's local host, the loop back address and ifindex are used. 452 This Interface object is also used to identify the incoming 453 (receiving) interface via its ifindex. The ifindex may be used to 454 differentiate between sub-interfaces and unnumbered interfaces (see 455 RSVP's LIH for an example). When SNMP is supported by the PEP, this 456 ifindex integer MUST correspond to the same integer value for the 457 interface in the SNMP MIB-II interface index table. 459 Note: The ifindex specified in the In-Interface is typically 460 relative to the flow of the underlying protocol messages. The 461 ifindex is the interface on which the protocol message was received. 463 C-Num = 3 465 C-Type = 1, IPv4 Address + Interface 466 0 1 2 3 467 +--------------+--------------+--------------+--------------+ 468 | IPv4 Address format | 469 +--------------+--------------+--------------+--------------+ 470 | ifindex | 471 +--------------+--------------+--------------+--------------+ 473 For this type of the interface object, the IPv4 address specifies 474 the IP address that the incoming message came from. 476 C-Type = 2, IPv6 Address + Interface 478 0 1 2 3 479 +--------------+--------------+--------------+--------------+ 480 | | 481 + + 482 | | 483 + IPv6 Address format + 484 | | 485 + + 486 | | 487 +--------------+--------------+--------------+--------------+ 488 | ifindex | 489 +--------------+--------------+--------------+--------------+ 491 For this type of the interface object, the IPv6 address specifies 492 the IP address that the incoming message came from. The ifindex is 493 used to refer to the MIB-II defined local incoming interface on the 494 PEP as described above. 496 2.2.4 Out-Interface Object (OUT-Int) 498 The Out-Interface is used to identify the outgoing interface to 499 which a specific request applies and the address for where the 500 forwarded message is to be sent. For flows or messages destined to 501 the PEP's local host, the loop back address and ifindex are used. 502 The Out-Interface has the same formats as the In-Interface Object. 504 This Interface object is also used to identify the outgoing 505 (forwarding) interface via its ifindex. The ifindex may be used to 506 differentiate between sub-interfaces and unnumbered interfaces (see 507 RSVP's LIH for an example). When SNMP is supported by the PEP, this 508 ifindex integer MUST correspond to the same integer value for the 509 interface in the SNMP MIB-II interface index table. 511 Note: The ifindex specified in the Out-Interface is typically 512 relative to the flow of the underlying protocol messages. The 513 ifindex is the one on which a protocol message is about to be 514 forwarded. 516 C-Num = 4 518 C-Type = 1, IPv4 Address + Interface 520 Same C-Type format as the In-Interface object. The IPv4 address 521 specifies the IP address to which the outgoing message is going. The 522 ifindex is used to refer to the MIB-II defined local outgoing 523 interface on the PEP. 525 C-Type = 2, IPv6 Address + Interface 527 Same C-Type format as the In-Interface object. For this type of the 528 interface object, the IPv6 address specifies the IP address to which 529 the outgoing message is going. The ifindex is used to refer to the 530 MIB-II defined local outgoing interface on the PEP. 532 2.2.5 Reason Object (Reason) 534 This object specifies the reason why the request state was deleted. 535 It appears in the delete request (DRQ) message. The Reason Sub-code 536 field is reserved for more detailed client-specific reason codes 537 defined in the corresponding documents. 539 C-Num = 5, C-Type = 1 541 0 1 2 3 542 +--------------+--------------+--------------+--------------+ 543 | Reason-Code | Reason Sub-code | 544 +--------------+--------------+--------------+--------------+ 546 Reason Code: 547 1 = Unspecified 548 2 = Management 549 3 = Preempted (Another request state takes precedence) 550 4 = Tear (Used to communicate a signaled state removal) 551 5 = Timeout (Local state has timed-out) 552 6 = Route Change (Change invalidates request state) 553 7 = Insufficient Resources (No local resource available) 554 8 = PDP's Directive (PDP decision caused the delete) 555 9 = Unsupported decision (PDP decision not supported) 556 10= Synchronize Handle Unknown 557 11= Transient Handle (stateless event) 558 12= Malformed Decision (could not recover) 559 13= Unknown COPS Object from PDP: 560 Sub-code (octet 2) contains unknown object's C-Num 561 and (octet 3) contains unknown object's C-Type. 563 2.2.6 Decision Object (Decision) 565 Decision made by the PDP. Appears in replies. The specific non- 566 mandatory decision objects required in a decision to a particular 567 request depend on the type of client. 569 C-Num = 6 570 C-Type = 1, Decision Flags (Mandatory) 572 0 1 2 3 573 +--------------+--------------+--------------+--------------+ 574 | Command-Code | Flags | 575 +--------------+--------------+--------------+--------------+ 577 Commands: 578 0 = NULL Decision (No configuration data available) 579 1 = Install (Admit request/Install configuration) 580 2 = Remove (Remove request/Remove configuration) 582 Flags: 583 0x01 = Trigger Error (Trigger error message if set) 584 Note: Trigger Error is applicable to client-types that 585 are capable of sending error notifications for signaled 586 messages. 588 Flag values not applicable to a given context's R-Type or 589 client-type MUST be ignored by the PEP. 591 C-Type = 2, Stateless Data 593 This type of decision object carries additional stateless 594 information that can be applied by the PEP locally. It is a 595 variable length object and its internal format SHOULD be 596 specified in the relevant COPS extension document for the given 597 client-type. This object is optional in Decision messages and is 598 interpreted relative to a given context. 600 It is expected that even outsourcing PEPs will be able to make 601 some simple stateless policy decisions locally in their LPDP. As 602 this set is well known and implemented ubiquitously, PDPs are 603 aware of it as well (either universally, through configuration, 604 or using the Client-Open message). The PDP may also include this 605 information in its decision, and the PEP MUST apply it to the 606 resource allocation event that generated the request. 608 C-Type = 3, Replacement Data 610 This type of decision object carries replacement data that is to 611 replace existing data in a signaled message. It is a variable 612 length object and its internal format SHOULD be specified in the 613 relevant COPS extension document for the given client-type. It 614 is optional in Decision messages and is interpreted relative to 615 a given context. 617 C-Type = 4, Client Specific Decision Data 619 Additional decision types can be introduced using the Client 620 Specific Decision Data Object. It is a variable length object 621 and its internal format SHOULD be specified in the relevant COPS 622 extension document for the given client-type. It is optional in 623 Decision messages and is interpreted relative to a given 624 context. 626 C-Type = 5, Named Decision Data 628 Named configuration information is encapsulated in this version 629 of the decision object in response to configuration requests. It 630 is a variable length object and its internal format SHOULD be 631 specified in the relevant COPS extension document for the given 632 client-type. It is optional in Decision messages and is 633 interpreted relative to both a given context and decision flags. 635 2.2.7 LPDP Decision Object (LPDPDecision) 637 Decision made by the PEP's local policy decision point (LPDP). May 638 appear in requests. These objects correspond to and are formatted 639 the same as the client specific decision objects defined above. 641 C-Num = 7 643 C-Type = (same C-Type as for Decision objects) 645 2.2.8 Error Object (Error) 647 This object is used to identify a particular COPS protocol error. 648 The error sub-code field contains additional detailed client 649 specific error codes. The appropriate Error Sub-codes for a 650 particular client-type SHOULD be specified in the relevant COPS 651 extensions document. 653 C-Num = 8, C-Type = 1 655 0 1 2 3 656 +--------------+--------------+--------------+--------------+ 657 | Error-Code | Error Sub-code | 658 +--------------+--------------+--------------+--------------+ 660 Error-Code: 662 1 = Bad handle 663 2 = Invalid handle reference 664 3 = Bad message format (Malformed Message) 665 4 = Unable to process (server gives up on query) 666 5 = Mandatory client-specific info missing 667 6 = Unsupported client-type 668 7 = Mandatory COPS object missing 669 8 = Client Failure 670 9 = Communication Failure 671 10= Unspecified 672 11= Shutting down 673 12= Redirect to Preferred Server 674 13= Unknown COPS Object: 675 Sub-code (octet 2) contains unknown object's C-Num 676 and (octet 3) contains unknown object's C-Type. 677 14= Authentication Failure 678 15= Authentication Required 680 2.2.9 Client Specific Information Object (ClientSI) 682 The various types of this object are required for requests, and used 683 in reports and opens when required. It contains client-type specific 684 information. 686 C-Num = 9, 687 C-Type = 1, Signaled ClientSI. 689 Variable-length field. All objects/attributes specific to a client's 690 signaling protocol or internal state are encapsulated within one or 691 more signaled Client Specific Information Objects. The format of the 692 data encapsulated in the ClientSI object is determined by the 693 client-type. 695 C-Type = 2, Named ClientSI. 697 Variable-length field. Contains named configuration information 698 useful for relaying specific information about the PEP, a request, 699 or configured state to the PDP server. 701 2.2.10 Keep-Alive Timer Object (KATimer) 703 Times are encoded as 2 octet integer values and are in units of 704 seconds. The timer value is treated as a delta. 706 C-Num = 10, 708 C-Type = 1, Keep-alive timer value 710 Timer object used to specify the maximum time interval over which a 711 COPS message MUST be sent or received. The range of finite timeouts 712 is 1 to 65535 seconds represented as an unsigned two-octet integer. 713 The value of zero implies infinity. 715 0 1 2 3 716 +--------------+--------------+--------------+--------------+ 717 | ////////////// | KA Timer Value | 718 +--------------+--------------+--------------+--------------+ 720 2.2.11 PEP Identification Object (PEPID) 722 The PEP Identification Object is used to identify the PEP client to 723 the remote PDP. It is required for Client-Open messages. 725 C-Num = 11, C-Type = 1 727 Variable-length field. It is a NULL terminated ASCII string that is 728 also zero padded to a 32-bit word boundary (so the object length is 729 a multiple of 4 octets). The PEPID MUST contain an ASCII string that 730 uniquely identifies the PEP within the policy domain in a manner 731 that is persistent across PEP reboots. For example, it may be the 732 PEP's statically assigned IP address or DNS name. This identifier 733 may safely be used by a PDP as a handle for identifying the PEP in 734 its policy rules. 736 2.2.12 Report-Type Object (Report-Type) 738 The Type of Report on the request state associated with a handle: 740 C-Num = 12, C-Type = 1 742 0 1 2 3 743 +--------------+--------------+--------------+--------------+ 744 | Report-Type | ///////////// | 745 +--------------+--------------+--------------+--------------+ 747 Report-Type: 748 1 = Success : Decision was successful at the PEP 749 2 = Failure : Decision could not be completed by PEP 750 3 = Accounting: Accounting update for an installed state 752 2.2.13 PDP Redirect Address (PDPRedirAddr) 754 A PDP when closing a PEP session for a particular client-type may 755 optionally use this object to redirect the PEP to the specified PDP 756 server address and TCP port number: 758 C-Num = 13, 760 C-Type = 1, IPv4 Address + TCP Port 761 0 1 2 3 762 +--------------+--------------+--------------+--------------+ 763 | IPv4 Address format | 764 +--------------+--------------+--------------+--------------+ 765 | ///////////////////////// | TCP Port Number | 766 +-----------------------------+-----------------------------+ 768 C-Type = 2, IPv6 Address + TCP Port 769 0 1 2 3 770 +--------------+--------------+--------------+--------------+ 771 | | 772 + + 773 | | 774 + IPv6 Address format + 775 | | 776 + + 777 | | 778 +--------------+--------------+--------------+--------------+ 779 | ///////////////////////// | TCP Port Number | 780 +-----------------------------+-----------------------------+ 782 2.2.14 Last PDP Address (LastPDPAddr) 784 When a PEP sends a Client-Open message for a particular client-type 785 the PEP SHOULD specify the last PDP it has successfully opened 786 (meaning it received a Client-Accept) since the PEP last rebooted. 787 If no PDP was used since the last reboot, the PEP will simply not 788 include this object in the Client-Open message. 790 C-Num = 14, 791 C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) 793 C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) 795 2.2.15 Accounting Timer Object (AcctTimer) 797 Times are encoded as 2 octet integer values and are in units of 798 seconds. The timer value is treated as a delta. 800 C-Num = 15, 802 C-Type = 1, Accounting timer value 804 Optional timer value used to determine the minimum interval between 805 periodic accounting type reports. It is used by the PDP to describe 806 to the PEP an acceptable interval between unsolicited accounting 807 updates via Report messages where applicable. It provides a method 808 for the PDP to control the amount of accounting traffic seen by the 809 network. The range of finite time values is 1 to 65535 seconds 810 represented as an unsigned two-octet integer. A value of zero means 811 there SHOULD be no unsolicited accounting updates. 813 0 1 2 3 814 +--------------+--------------+--------------+--------------+ 815 | ////////////// | ACCT Timer Value | 816 +--------------+--------------+--------------+--------------+ 818 2.2.16 Message Integrity Object (Integrity) 820 The integrity object includes a sequence number and a message digest 821 useful for authenticating and validating the integrity of a COPS 822 message. When used, integrity is provided at the end of a COPS 823 message as the last COPS object. The digest is then computed over 824 all of a particular COPS message up to but not including the digest 825 value itself. The sender of a COPS message will compute and fill in 826 the digest portion of the Integrity object. The receiver of a COPS 827 message will then compute a digest over the received message and 828 verify it matches the digest in the received Integrity object. 830 C-Num = 16, 832 C-Type = 1, HMAC digest 834 The HMAC integrity object employs HMAC (Keyed-Hashing for Message 835 Authentication) [HMAC] to calculate the message digest based on a 836 key shared between the PEP and its PDP. 838 This Integrity object specifies a 32-bit Key ID used to identify a 839 specific key shared between a particular PEP and its PDP and the 840 cryptographic algorithm to be used. The Key ID allows for multiple 841 simultaneous keys to exist on the PEP with corresponding keys on the 842 PDP for the given PEPID. The key identified by the Key ID was used 843 to compute the message digest in the Integrity object. All 844 implementations, at a minimum, MUST support HMAC-MD5-96, which is 845 HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 846 96-bits to calculate the message digest. 848 This object also includes a sequence number that is a 32-bit 849 unsigned integer used to avoid replay attacks. The sequence number 850 is initiated during an initial Client-Open Client-Accept message 851 exchange and is then incremented by one each time a new message is 852 sent over the TCP connection in the same direction. If the sequence 853 number reaches the value of 0xFFFFFFFF, the next increment will 854 simply rollover to a value of zero. 856 The variable length digest is calculated over a COPS message 857 starting with the COPS Header up to the Integrity Object (which MUST 858 be the last object in a COPS message) INCLUDING the Integrity 859 object's header, Key ID, and Sequence Number. The Keyed Message 860 Digest field is not included as part of the digest calculation. In 861 the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that 862 is then to be truncated to 96-bits before being stored in or 863 verified against the Keyed Message Digest field as specified in 864 [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is 865 used. 867 0 1 2 3 868 +-------------+-------------+-------------+-------------+ 869 | Key ID | 870 +-------------+-------------+-------------+-------------+ 871 | Sequence Number | 872 +-------------+-------------+-------------+-------------+ 873 | | 874 + + 875 | ...Keyed Message Digest... | 876 + + 877 | | 878 +-------------+-------------+-------------+-------------+ 880 2.3 Communication 882 The COPS protocol uses a single persistent TCP connection between 883 the PEP and a remote PDP. One PDP implementation per server MUST 884 listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP 885 is responsible for initiating the TCP connection to a PDP. The 886 location of the remote PDP can either be configured, or obtained via 887 a service location mechanism [SRVLOC]. Service discovery is outside 888 the scope of this protocol, however. 890 If a single PEP can support multiple client-types, it may send 891 multiple Client-Open messages, each specifying a particular client- 892 type to a PDP over one or more TCP connections. Likewise, a PDP 893 residing at a given address and port number may support one or more 894 client-types. Given the client-types it supports, a PDP has the 895 ability to either accept or reject each client-type independently. 896 If a client-type is rejected, the PDP can redirect the PEP to an 897 alternative PDP address and TCP port for a given client-type via 898 COPS. Different TCP port numbers can be used to redirect the PEP to 899 another PDP implementation running on the same server. Additional 900 provisions for supporting multiple client-types (perhaps from 901 independent PDP vendors) on a single remote PDP server are not 902 provided by the COPS protocol, but, rather, are left to the software 903 architecture of the given server platform. 905 It is possible a single PEP may have open connections to multiple 906 PDPs. This is the case when there are physically different PDPs 907 supporting different client-types as shown in figure 2. 909 +----------------+ 910 | | 911 | Network Node | Policy Servers 912 | | 913 | +-----+ | COPS Client Type 1 +-----+ 914 | | |<-----|-------------------->| PDP1| 915 | + PEP + | COPS Client Type 2 +-----+ 916 | | |<-----|---------\ +-----+ 917 | +-----+ | \----------| PDP2| 918 | ^ | +-----+ 919 | | | 920 | \-->+-----+ | 921 | | LPDP| | 922 | +-----+ | 923 | | 924 +----------------+ 925 Figure 2: Multiple PDPs illustration. 927 When a TCP connection is torn down or is lost, the PDP is expected 928 to eventually clean up any outstanding request state related to 929 request/decision exchanges with the PEP. When the PEP detects a lost 930 connection due to a timeout condition it SHOULD explicitly send a 931 Client-Close message for each opened client-type containing an 932 object indicating the "Communication Failure" Error-Code. 933 Additionally, the PEP SHOULD continuously attempt to contact the 934 primary PDP or, if unsuccessful, any known backup PDPs. Specifically 935 the PEP SHOULD keep trying all relevant PDPs with which it has been 936 configured until it can establish a connection. If a PEP is in 937 communication with a backup PDP and the primary PDP becomes 938 available, the backup PDP is responsible for redirecting the PEP 939 back to the primary PDP (via a message containing a 940 object identifying the primary PDP to use for each 941 affected client-type). Section 2.5 details synchronization behavior 942 between PEPs and PDPs. 944 2.4 Client Handle Usage 946 The client handle is used to identify a unique request state for a 947 single PEP per client-type. Client handles are chosen by the PEP and 948 are opaque to the PDP. The PDP simply uses the request handle to 949 uniquely identify the request state for a particular Client-Type 950 over a particular TCP connection and generically tie its decisions 951 to a corresponding request. Client handles are initiated in request 952 messages and are then used by subsequent request, decision, and 953 report messages to reference the same request state. When the PEP is 954 ready to remove a local request state, it will issue a delete 955 message to the PDP for the corresponding client handle. A handle 956 MUST be explicitly deleted by the PEP before it can be used by the 957 PEP to identify a new request state. Handles referring to different 958 request states MUST be unique within the context of a particular TCP 959 connection and client-type. 961 2.5 Synchronization Behavior 963 When disconnected from a PDP, the PEP SHOULD revert to making local 964 decisions. Once a connection is reestablished, the PEP is expected 965 to notify the PDP of any events that have passed local admission 966 control. Additionally, the remote PDP may request that all the PEP's 967 internal state be resynchronized (all previously installed requests 968 are to be reissued) by sending a Synchronize State message. 970 After a failure and before a new connection is fully functional, 971 disruption of service can be minimized if the PEP caches previously 972 communicated decisions and continues to use them for some 973 appropriate length of time. Specific rules for such behavior are to 974 be defined in the appropriate COPS client-type extension 975 specifications. 977 A PEP that caches state from a previous exchange with a disconnected 978 PDP MUST communicate this fact to any PDP with which it is able to 979 later reconnect. This is accomplished by including the address and 980 TCP port of the last PDP for which the PEP is still caching state in 981 the Client-Open message. The object will only be 982 included for the last PDP with which the PEP was completely in sync. 983 If the service interruption was temporary and the PDP still contains 984 the complete state for the PEP, the PDP may choose not to 985 synchronize all states. It is still the responsibility of the PEP to 986 update the PDP of all state changes that occurred during the 987 disruption of service including any states communicated to the 988 previous PDP that had been deleted after the connection was lost. 989 These MUST be explicitly deleted after a connection is 990 reestablished. If the PDP issues a synchronize request the PEP MUST 991 pass all current states to the PDP followed by a Synchronize State 992 Complete message (thus completing the synchronization process). If 993 the PEP crashes and loses all cached state for a client-type, it 994 will simply not include a in its Client-Open message. 996 3. Message Content 998 This section describes the basic messages exchanged between a PEP 999 and a remote PDP as well as their contents. As a convention, object 1000 ordering is expected as shown in the BNF for each COPS message 1001 unless otherwise noted. The Integrity object, if included, MUST 1002 always be the last object in a message. If security is required and 1003 a message was received without a valid Integrity object, the 1004 receiver MUST send a Client-Close message for Client-Type=0 1005 specifying the appropriate error code. 1007 3.1 Request (REQ) PEP -> PDP 1009 The PEP establishes a request state client handle for which the 1010 remote PDP may maintain state. The remote PDP then uses this handle 1011 to refer to the exchanged information and decisions communicated 1012 over the TCP connection to a particular PEP for a given client-type. 1014 Once a stateful handle is established for a new request, any 1015 subsequent modifications of the request can be made using the REQ 1016 message specifying the previously installed handle. The PEP is 1017 responsible for notifying the PDP whenever its local state changes 1018 so the PDP's state will be able to accurately mirror the PEP's 1019 state. 1021 The format of the Request message is as follows: 1023 ::= 1024 1025 1026 [] 1027 [] 1028 [] 1029 [] 1030 [] 1032 ::= | 1034 ::= | 1035 1037 The context object is used to determine the context within which all 1038 the other objects are to be interpreted. It also is used to 1039 determine the kind of decision to be returned from the policy 1040 server. This decision might be related to admission control, 1041 resource allocation, object forwarding and substitution, or 1042 configuration. 1044 The interface objects are used to determine the corresponding 1045 interface on which a signaling protocol message was received or is 1046 about to be sent. They are typically used if the client is 1047 participating along the path of a signaling protocol or if the 1048 client is requesting configuration data for a particular interface. 1050 ClientSI, the client specific information object, holds the client- 1051 type specific data for which a policy decision needs to be made. In 1052 the case of configuration, the Named ClientSI may include named 1053 information about the module, interface, or functionality to be 1054 configured. The ordering of multiple ClientSIs is not important. 1056 Finally, LPDPDecision object holds information regarding the local 1057 decision made by the LPDP. 1059 Malformed Request messages MUST result in the PDP specifying a 1060 Decision message with the appropriate error code. 1062 3.2 Decision (DEC) PDP -> PEP 1064 The PDP responds to the REQ with a DEC message that includes the 1065 associated client handle and one or more decision objects grouped 1066 relative to a Context object and Decision Flags object type pair. If 1067 there was a protocol error an error object is returned instead. 1069 It is required that the first decision message for a new/updated 1070 request will have the solicited message flag set (value = 1) in the 1071 COPS header. This avoids the issue of keeping track of which updated 1072 request (that is, a request reissued for the same handle) a 1073 particular decision corresponds. It is important that, for a given 1074 handle, there be at most one outstanding solicited decision per 1075 request. This essentially means that the PEP SHOULD NOT issue more 1076 than one REQ (for a given handle) before it receives a corresponding 1077 DEC with the solicited message flag set. The PDP MUST always issue 1078 decisions for requests on a particular handle in the order they 1079 arrive and all requests MUST have a corresponding decision. 1081 To avoid deadlock, the PEP can always timeout after issuing a 1082 request that does not receive a decision. It MUST then delete the 1083 timed-out handle, and may try again using a new handle. 1085 The format of the Decision message is as follows: 1087 ::= 1088 1089 | 1090 [] 1092 ::= | 1094 ::= 1095 1096 [] 1097 [] 1098 [] 1099 [] 1101 The Decision message may include either an Error object or one or 1102 more context plus associated decision objects. COPS protocol 1103 problems are reported in the Error object (e.g. an error with the 1104 format of the original request including malformed request messages, 1105 unknown COPS objects in the Request, etc.). The applicable Decision 1106 object(s) depend on the context and the type of client. The only 1107 ordering requirement for decision objects is that the required 1108 Decision Flags object type MUST precede the other Decision object 1109 types per context binding. 1111 3.3 Report State (RPT) PEP -> PDP 1113 The RPT message is used by the PEP to communicate to the PDP its 1114 success or failure in carrying out the PDP's decision, or to report 1115 an accounting related change in state. The Report-Type specifies the 1116 kind of report and the optional ClientSI can carry additional 1117 information per Client-Type. 1119 For every DEC message containing a configuration context that is 1120 received by a PEP, the PEP MUST generate a corresponding Report 1121 State message with the Solicited Message flag set describing its 1122 success or failure in applying the configuration decision. In 1123 addition, outsourcing decisions from the PDP MAY result in a 1124 corresponding solicited Report State from the PEP depending on the 1125 context and the type of client. RPT messages solicited by decisions 1126 for a given Client Handle MUST set the Solicited Message flag and 1127 MUST be sent in the same order as their corresponding Decision 1128 messages were received. There MUST never be more than one Report 1129 State message generated with the Solicited Message flag set per 1130 Decision. 1132 The Report State may also be used to provide periodic updates of 1133 client specific information for accounting and state monitoring 1134 purposes depending on the type of the client. In such cases the 1135 accounting report type should be specified utilizing the appropriate 1136 client specific information object. 1138 ::== 1139 1140 1141 [] 1142 [] 1144 3.4 Delete Request State (DRQ) PEP -> PDP 1146 When sent from the PEP this message indicates to the remote PDP that 1147 the state identified by the client handle is no longer 1148 available/relevant. This information will then be used by the remote 1149 PDP to initiate the appropriate housekeeping actions. The reason 1150 code object is interpreted with respect to the client-type and 1151 signifies the reason for the removal. 1153 The format of the Delete Request State message is as follows: 1155 ::= 1156 1157 1158 [] 1160 Given the stateful nature of COPS, it is important that when a 1161 request state is finally removed from the PEP, a DRQ message for 1162 this request state is sent to the PDP so the corresponding state may 1163 likewise be removed on the PDP. Request states not explicitly 1164 deleted by the PEP will be maintained by the PDP until either the 1165 client session is closed or the connection is terminated. 1167 Malformed Decision messages MUST trigger a DRQ specifying the 1168 appropriate erroneous reason code (Bad Message Format) and any 1169 associated state on the PEP SHOULD either be removed or re- 1170 requested. If a Decision contained an unknown COPS Decision Object, 1171 the PEP MUST delete its request specifying the Unknown COPS Object 1172 reason code because the PEP will be unable to comply with the 1173 information contained in the unknown object. In any case, after 1174 issuing a DRQ, the PEP may retry the corresponding Request again. 1176 3.5 Synchronize State Request (SSQ) PDP -> PEP 1178 The format of the Synchronize State Query message is as follows: 1180 ::= 1181 [] 1182 [] 1184 This message indicates that the remote PDP wishes the client (which 1185 appears in the common header) to re-send its state. If the optional 1186 Client Handle is present, only the state associated with this handle 1187 is synchronized. If the PEP does not recognize the requested handle, 1188 it MUST immediately send a DRQ message to the PDP for the handle 1189 that was specified in the SSQ message. If no handle is specified in 1190 the SSQ message, all the active client state MUST be synchronized 1191 with the PDP. 1193 The client performs state synchronization by re-issuing request 1194 queries of the specified client-type for the existing state in the 1195 PEP. When synchronization is complete, the PEP MUST issue a 1196 synchronize state complete message to the PDP. 1198 3.6 Client-Open (OPN) PEP -> PDP 1200 The Client-Open message can be used by the PEP to specify to the PDP 1201 the client-types the PEP can support, the last PDP to which the PEP 1202 connected for the given client-type, and/or client specific feature 1203 negotiation. A Client-Open message can be sent to the PDP at any 1204 time and multiple Client-Open messages for the same client-type are 1205 allowed (in case of global state changes). 1207 ::= 1208 1209 [] 1210 [] 1211 [] 1213 The PEPID is a symbolic, variable length name that uniquely 1214 identifies the specific client to the PDP (see Section 2.2.11). 1216 A named ClientSI object can be included for relaying additional 1217 global information about the PEP to the PDP when required (as 1218 specified in the appropriate extensions document for the client- 1219 type). 1221 The PEP may also provide a Last PDP Address object in its Client- 1222 Open message specifying the last PDP (for the given client-type) for 1223 which it is still caching decisions since its last reboot. A PDP can 1224 use this information to determine the appropriate synchronization 1225 behavior (See section 2.5). 1227 If the PDP receives a malformed Client-Open message it MUST generate 1228 a Client-Close message specifying the appropriate error code. 1230 3.7 Client-Accept (CAT) PDP -> PEP 1232 The Client-Accept message is used to positively respond to the 1233 Client-Open message. This message will return to the PEP a timer 1234 object indicating the maximum time interval between keep-alive 1235 messages. Optionally, a timer specifying the minimum allowed 1236 interval between accounting report messages may be included when 1237 applicable. 1239 ::= 1240 1241 [] 1242 [] 1244 If the PDP refuses the client, it will instead issue a Client-Close 1245 message. 1247 The KA Timer corresponds to maximum acceptable intermediate time 1248 between the generation of messages by the PDP and PEP. The timer 1249 value is determined by the PDP and is specified in seconds. A timer 1250 value of 0 implies no secondary connection verification is 1251 necessary. 1253 The optional ACCT Timer allows the PDP to indicate to the PEP that 1254 periodic accounting reports SHOULD NOT exceed the specified timer 1255 interval per client handle. This allows the PDP to control the rate 1256 at which accounting reports are sent by the PEP (when applicable). 1257 In general, accounting type Report messages are sent to the PDP when 1258 determined appropriate by the PEP. The accounting timer merely is 1259 used by the PDP to keep the rate of such updates in check (i.e. 1260 Preventing the PEP from blasting the PDP with accounting reports). 1261 Not including this object implies there are no PDP restrictions on 1262 the rate at which accounting updates are generated. 1264 If the PEP receives a malformed Client-Accept message it MUST 1265 generate a Client-Close message specifying the appropriate error 1266 code. 1268 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP 1270 The Client-Close message can be issued by either the PDP or PEP to 1271 notify the other that a particular type of client is no longer being 1272 supported. 1274 ::= 1275 1276 [] 1277 [] 1279 The Error object is included to describe the reason for the close 1280 (e.g. the requested client-type is not supported by the remote PDP 1281 or client failure). 1283 A PDP MAY optionally include a PDP Redirect Address object in order 1284 to inform the PEP of the alternate PDP it SHOULD use for the client- 1285 type specified in the common header. 1287 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 1289 The keep-alive message MUST be transmitted by the PEP within the 1290 period defined by the minimum of all KA Timer values specified in 1291 all received CAT messages for the connection. A KA message MUST be 1292 generated randomly between 1/4 and 3/4 of this minimum KA timer 1293 interval. When the PDP receives a keep-alive message from a PEP, it 1294 MUST echo a keep-alive back to the PEP. This message provides 1295 validation for each side that the connection is still functioning 1296 even when there is no other messaging. 1298 Note: The client-type in the header MUST always be set to 0 as the 1299 KA is used for connection verification (not per client session 1300 verification). 1302 ::= 1303 [] 1305 Both client and server MAY assume the TCP connection is insufficient 1306 for the client-type with the minimum time value (specified in the 1307 CAT message) if no communication activity is detected for a period 1308 exceeding the timer period. For the PEP, such detection implies the 1309 remote PDP or connection is down and the PEP SHOULD now attempt to 1310 use an alternative/backup PDP. 1312 3.10 Synchronize State Complete (SSC) PEP -> PDP 1314 The Synchronize State Complete is sent by the PEP to the PDP after 1315 the PDP sends a synchronize state request to the PEP and the PEP has 1316 finished synchronization. It is useful so that the PDP will know 1317 when all the old client state has been successfully re-requested 1318 and, thus, the PEP and PDP are completely synchronized. The Client 1319 Handle object only needs to be included if the corresponding 1320 Synchronize State Message originally referenced a specific handle. 1322 ::= 1323 [] 1324 [] 1326 4. Common Operation 1328 This section describes the typical exchanges between remote PDP 1329 servers and PEP clients. 1331 4.1 Security and Sequence Number Negotiation 1333 COPS message security is negotiated once per connection and covers 1334 all communication over a particular connection. If COPS level 1335 security is required, it MUST be negotiated during the initial 1336 Client-Open/Client-Accept message exchange specifying a Client-Type 1337 of zero (which is reserved for connection level security negotiation 1338 and connection verification). 1340 If a PEP is not configured to use COPS security with a PDP it will 1341 simply send the PDP Client-Open messages for the supported Client- 1342 Types as specified in section 4.3 and will not include the Integrity 1343 object in any COPS messages. 1345 Otherwise, security can be initiated by the PEP if it sends the PDP 1346 a Client-Open message with Client-Type=0 before opening any other 1347 Client-Type. If the PDP receives a Client-Open with a Client-Type=0 1348 after another Client-Type has already been opened successfully it 1349 MUST return a Client-Close message (for Client-Type=0) to that PEP. 1350 This first Client-Open message MUST specify a Client-Type of zero 1351 and MUST provide the PEPID and a COPS Integrity object. This 1352 Integrity object will contain the initial sequence number the PEP 1353 requires the PDP to increment during subsequent communication after 1354 the initial Client-Open/Client-Accept exchange and the Key ID 1355 identifying the algorithm and key used to compute the digest. 1357 Similarly, if the PDP accepts the PEP's security key and algorithm 1358 by validating the message digest using the identified key, the PDP 1359 MUST send a Client-Accept message with a Client-Type of zero to the 1360 PEP carrying an Integrity object. This Integrity object will contain 1361 the initial sequence number the PDP requires the PEP to increment 1362 during all subsequent communication with the PDP and the Key ID 1363 identifying the key and algorithm used to compute the digest. 1365 If the PEP, from the perspective of a PDP that requires security, 1366 fails or never performs the security negotiation by not sending an 1367 initial Client-Open message with a Client-Type=0 including a valid 1368 Integrity object, the PDP MUST send to the PEP a Client-Close 1369 message with a Client-Type=0 specifying the appropriate error code. 1370 Similarly, if the PDP, from the perspective of a PEP that requires 1371 security, fails the security negotiation by not sending back a 1372 Client-Accept message with a Client-Type=0 including a valid 1373 Integrity object, the PEP MUST send to the PDP a Client-Close 1374 message with a Client-Type=0 specifying the appropriate error code. 1375 Such a Client-Close message need not carry an integrity object (as 1376 the security negotiation did not yet complete). 1378 The security initialization can fail for one of several reasons: 1. 1379 The side receiving the message requires COPS level security but an 1380 Integrity object was not provided (Authentication Required error 1381 code). 2. A COPS Integrity object was provided, but with an 1382 unknown/unacceptable C-Type (Unknown COPS Object error code 1383 specifying the unsupported C-Num and C-Type). 3. The message digest 1384 or Key ID in the provided Integrity object was incorrect and 1385 therefore the message could not be authenticated using the 1386 identified key (Authentication Failure error code). 1388 Once the initial security negotiation is complete, the PEP will know 1389 what sequence numbers the PDP expects and the PDP will know what 1390 sequence numbers the PEP expects. ALL COPS messages must then 1391 include the negotiated Integrity object specifying the correct 1392 sequence number with the appropriate message digest (including the 1393 Client-Open/Client-Accept messages for specific Client-Types). ALL 1394 subsequent messages from the PDP to the PEP MUST result in an 1395 increment of the sequence number provided by the PEP in the 1396 Integrity object of the initial Client-Open message. Likewise, ALL 1397 subsequent messages from the PEP to the PDP MUST result in an 1398 increment of the sequence number provided by the PDP in the 1399 Integrity object of the initial Client-Accept message. Sequence 1400 numbers are incremented by one starting with the corresponding 1401 initial sequence number. For example, if the sequence number 1402 specified to the PEP by the PDP in the initial Client-Accept was 10, 1403 the next message the PEP sends to the PDP will provide an Integrity 1404 object with a sequence number of 11... Then the next message the PEP 1405 sends to the PDP will have a sequence number of 12 and so on. If any 1406 subsequent received message contains the wrong sequence number, an 1407 unknown Key ID, an invalid message digest, or is missing an 1408 Integrity object after integrity was negotiated, then a Client-Close 1409 message MUST be generated for the Client-Type zero containing a 1410 valid Integrity object and specifying the appropriate error code. 1411 The connection should then be dropped. 1413 4.2 Key Maintenance 1415 Key maintenance is outside the scope of this document, but COPS 1416 implementations MUST at least provide the ability to manually 1417 configure keys and their parameters locally. The key used to produce 1418 the Integrity object's message digest is identified by the Key ID 1419 field. Thus, a Key ID parameter is used to identify one of 1420 potentially multiple simultaneous keys shared by the PEP and PDP. A 1421 Key ID is relative to a particular PEPID on the PDP or to a 1422 particular PDP on the PEP. Each key must also be configured with 1423 lifetime parameters for the time period within which it is valid as 1424 well as an associated cryptographic algorithm parameter specifying 1425 the algorithm to be used with the key. At a minimum, all COPS 1426 implementations MUST support the HMAC-MD5-96 [HMAC][MD5] 1427 cryptographic algorithm for computing a message digest for inclusion 1428 in the Keyed Message Digest of the Integrity object which is 1429 appended to the message. 1431 It is good practice to regularly change keys. Keys MUST be 1432 configurable such that their lifetimes overlap allowing smooth 1433 transitions between keys. At the midpoint of the lifetime overlap 1434 between two keys, senders should transition from using the current 1435 key to the next/longer-lived key. Meanwhile, receivers simply accept 1436 any identified key received within its configured lifetime and 1437 reject those that are not. 1439 4.3 PEP Initialization 1441 Sometime after a connection is established between the PEP and a 1442 remote PDP and after security is negotiated (if required), the PEP 1443 will send one or more Client-Open messages to the remote PDP, one 1444 for each client-type supported by the PEP. The Client-Open message 1445 MUST contain the address of the last PDP with which the PEP is still 1446 caching a complete set of decisions. If no decisions are being 1447 cached from the previous PDP the LastPDPAddr object MUST NOT be 1448 included in the Client-Open message (see Section 2.5). Each Client- 1449 Open message MUST at least contain the common header noting one 1450 client-type supported by the PEP. The remote PDP will then respond 1451 with separate Client-Accept messages for each of the client-types 1452 requested by the PEP that the PDP can also support. 1454 If a specific client-type is not supported by the PDP, the PDP will 1455 instead respond with a Client-Close specifying the client-type is 1456 not supported and will possibly suggest an alternate PDP address and 1457 port. Otherwise, the PDP will send a Client-Accept specifying the 1458 timer interval between keep-alive messages and the PEP may begin 1459 issuing requests to the PDP. 1461 4.4 Outsourcing Operations 1463 In the outsourcing scenario, when the PEP receives an event that 1464 requires a new policy decision it sends a request message to the 1465 remote PDP. What specifically qualifies as an event for a particular 1466 client-type SHOULD be specified in the specific document for that 1467 client-type. The remote PDP then makes a decision and sends a 1468 decision message back to the PEP. Since the request is stateful, the 1469 request will be remembered, or installed, on the remote PDP. The 1470 unique handle (unique per TCP connection and client-type), specified 1471 in both the request and its corresponding decision identifies this 1472 request state. The PEP is responsible for deleting this request 1473 state once the request is no longer applicable. 1475 The PEP can update a previously installed request state by reissuing 1476 a request for the previously installed handle. The remote PDP is 1477 then expected to make new decisions and send a decision message back 1478 to the PEP. Likewise, the server MAY change a previously issued 1479 decision on any currently installed request state at any time by 1480 issuing an unsolicited decision message. At all times the PEP module 1481 is expected to abide by the PDP's decisions and notify the PDP of 1482 any state changes. 1484 4.5 Configuration Operations 1486 In the configuration scenario, as in the outsourcing scenario, the 1487 PEP will make a configuration request to the PDP for a particular 1488 interface, module, or functionality that may be specified in the 1489 named client specific information object. The PDP will then send 1490 potentially several decisions containing named units of 1491 configuration data to the PEP. The PEP is expected to install and 1492 use the configuration locally. A particular named configuration can 1493 be updated by simply sending additional decision messages for the 1494 same named configuration. When the PDP no longer wishes the PEP to 1495 use a piece of configuration information, it will send a decision 1496 message specifying the named configuration and a decision flags 1497 object with the remove configuration command. The PEP SHOULD then 1498 proceed to remove the corresponding configuration and send a report 1499 message to the PDP that specifies it has been deleted. 1501 In all cases, the PEP MAY notify the remote PDP of the local status 1502 of an installed state using the report message where appropriate. 1503 The report message is to be used to signify when billing can begin, 1504 what actions were taken, or to produce periodic updates for 1505 monitoring and accounting purposes depending on the client. This 1506 message can carry client specific information when needed. 1508 4.6 Keep-Alive Operations 1510 The Keep-Alive message is used to validate the connection between 1511 the client and server is still functioning even when there is no 1512 other messaging from the PEP to PDP. The PEP MUST generate a COPS KA 1513 message randomly within one-fourth to three-fourths the minimum KA 1514 Timer interval specified by the PDP in the Client-Accept message. On 1515 receiving a Keep-Alive message from the PEP, the PDP MUST then 1516 respond to this Keep-Alive message by echoing a Keep-Alive message 1517 back to the PEP. If either side does not receive a Keep-Alive or any 1518 other COPS message within the minimum KA Timer interval from the 1519 other, the connection SHOULD be considered lost. 1521 4.7 PEP/PDP Close 1523 Finally, Client-Close messages are used to negate the effects of the 1524 corresponding Client-Open messages, notifying the other side that 1525 the specified client-type is no longer supported/active. When the 1526 PEP detects a lost connection due to a keep-alive timeout condition 1527 it SHOULD explicitly send a Client-Close message for each opened 1528 client-type specifying a communications failure error code. Then the 1529 PEP MAY proceed to terminate the connection to the PDP and attempt 1530 to reconnect again or try a backup/alternative PDP. When the PDP is 1531 shutting down, it SHOULD also explicitly send a Client-Close to all 1532 connected PEPs for each client-type, perhaps specifying an 1533 alternative PDP to use instead. 1535 5. Security Considerations 1537 The COPS protocol provides an Integrity object that can achieve 1538 authentication, message integrity, and replay prevention. All COPS 1539 implementations MUST support the COPS Integrity object and its 1540 mechanisms as described in this document. To ensure the client (PEP) 1541 is communicating with the correct policy server (PDP) requires 1542 authentication of the PEP and PDP using a shared secret, and 1543 consistent proof that the connection remains valid. The shared 1544 secret minimally requires manual configuration of keys (identified 1545 by a Key ID) shared between the PEP and its PDP. The key is used in 1546 conjunction with the contents of a COPS message to calculate a 1547 message digest that is part of the Integrity object. The Integrity 1548 object is then used to validate all COPS messages sent over the TCP 1549 connection between a PEP and PDP. 1551 Key maintenance is outside the scope of this document beyond the 1552 specific requirements discussed in section 4.2. In general, it is 1553 good practice to regularly change keys to maintain security. 1554 Furthermore, it is good practice to use localized keys specific to a 1555 particular PEP such that a stolen PEP will not compromise the 1556 security of an entire administrative domain. 1558 The COPS Integrity object also provides sequence numbers to avoid 1559 replay attacks. The PDP chooses the initial sequence number for the 1560 PEP and the PEP chooses the initial sequence number for the PDP. 1561 These initial numbers are then incremented with each successive 1562 message sent over the connection in the corresponding direction. The 1563 initial sequence numbers SHOULD be chosen such that they are 1564 monotonically increasing and never repeat for a particular key. 1566 Security between the client (PEP) and server (PDP) MAY be provided 1567 by IP Security [IPSEC]. In this case, the IPSEC Authentication 1568 Header (AH) SHOULD be used for the validation of the connection; 1569 additionally IPSEC Encapsulation Security Payload (ESP) MAY be used 1570 to provide both validation and secrecy. 1572 Transport Layer Security [TLS] MAY be used for both connection-level 1573 validation and privacy. 1575 6. IANA Considerations 1577 The Client-type identifies the policy client application to which a 1578 message refers. Client-type values within the range 0x0001-0x3FFF 1579 are reserved Specification Required status as defined in [IANA- 1580 CONSIDERATIONS]. These values MUST be registered with IANA and their 1581 behavior and applicability MUST be described in a COPS extension 1582 document. 1584 Client-type values in the range 0x4000 - 0x7FFF are reserved for 1585 Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types 1586 are not tracked by IANA and are not to be used in standards or 1587 general-release products, as their uniqueness cannot be assured. 1589 Client-type values in the range 0x8000 - 0xFFFF are First Come First 1590 Served as defined in [IANA-CONSIDERATIONS]. These Client-types are 1591 tracked by IANA but do not require published documents describing 1592 their use. IANA merely assures their uniqueness. 1594 Objects in the COPS Protocol are identified by their C-Num and C- 1595 Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] 1596 is required to introduce new values for these numbers and, 1597 therefore, new objects into the base COPS protocol. 1599 Additional Context Object R-Types, Reason-Codes, Report-Types, 1600 Decision Object Command-Codes/Flags, and Error-Codes MAY be defined 1601 for use with future Client-types, but such additions require IETF 1602 Consensus as defined in [IANA-CONSIDERATIONS]. 1604 Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be 1605 defined relative to a particular Client-type following the same IANA 1606 considerations as their respective Client-type. 1608 7. References 1610 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 1611 Version 1 - Functional Specification", RFC 2205, September 1612 1997. 1614 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 1615 Control", Internet-Draft, draft-ietf-rap-framework-01.txt, 1616 November 1998. 1618 [SRVLOC]Guttman, E. et al., "Service Location Protocol , Version 2", 1619 RFC 2608, June 1999. 1621 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 1622 Parameters for Integrated Service Network Elements", RFC 1623 2215, September 1997. 1625 [IPSEC] Atkinson, R., "Security Architecture for the Internet 1626 Protocol", RFC 2401, August 1995. 1628 [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 1629 for Message Authentication", RFC 2104, February 1997. 1631 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1632 April 1992. 1634 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 1635 - Version 1 Message Processing Rules", RFC 2209, September 1636 1997. 1638 [TLS] Dierks T., Allen C., "The TLS Protocol Version 1.0", RFC 1639 2246, January 1999. 1641 [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers 1643 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1644 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1645 2434, October 1998. 1647 8. Author Information and Acknowledgments 1649 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 1650 Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch 1651 Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable 1652 contributions. 1654 Jim Boyle Ron Cohen 1655 Level 3 Communications Cisco Systems 1656 1450 Infinite Drive13 Hasadna St. 1657 Louisville, CO 80027 Ra'anana 43650 Israel 1658 303.926.3100 972.9.7462020 1659 email: jboyle@l3.net ronc@classdata.com 1661 David Durham Raju Rajan 1662 Intel AT&T Shannon Laboratory 1663 2111 NE 25th Avenue 180 Park Avenue 1664 Hillsboro, OR 97124 P.O. Box 971 1665 503.264.6232 Florham Park, NJ 07932-0971 1666 David.Durham@intel.com rajan@research.att.com 1668 Shai Herzog Arun Sastry 1669 IPHighway Cisco Systems 1670 Parker Plaza, 16th Floor 506210 W Tasman Drive 1671 400 Kelby St. Fort-Lee NJ 07024 San Jose, CA 95134 1672 201.585.0800 408.526.7685 1673 herzog@iphighway.com asastry@cisco.com