idnits 2.17.1 draft-ietf-rap-cops-07.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 (August 16, 1999) is 9013 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 888, but not defined == Unused Reference: 'INSCH' is defined on line 1622, 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: January 2000 Level 3 3 File: draft-ietf-rap-cops-07.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: August 16, 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 LDP Decision Object (LDPDecision)...........................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 and provisioned QoS 100 resource management. It is designed to be extensible so that other 101 kinds of policy clients may be supported in the future. The model 102 does not make any assumptions about the methods of the policy 103 server, but is based on the server returning decisions to policy 104 requests. 106 1. Introduction 108 This document describes a simple query and response protocol that 109 can be used to exchange policy information between a policy server 110 (Policy Decision Point or PDP) and its clients (Policy Enforcement 111 Points or PEPs). One example of a policy client is RSVP routers 112 that must exercise policy-based admission control over RSVP usage 113 [RSVP]. We assume that at least one policy server exists in each 114 controlled administrative domain. The basic model of interaction 115 between a policy server and its clients is compatible with 116 the framework document for policy based admission control [WRK]. 118 A chief objective of policy control protocol is to begin with a 119 simple but extensible design. The main characteristics of the COPS 120 protocol include: 122 1. The protocol employs a client/server model where the PEP 123 sends requests, updates, and deletes to the remote PDP and the 124 PDP returns decisions back to the PEP. 126 2. The protocol uses TCP as its transport protocol for reliable 127 exchange of messages between policy clients and a server. 128 Therefore, no additional mechanisms are necessary for reliable 129 communication between a server and its clients. 131 3. The protocol is extensible in that it is designed to leverage 132 off self-identifying objects and can support diverse client 133 specific information without requiring modifications to the COPS 134 protocol itself. The protocol was created for the general 135 administration, configuration, and enforcement of policies 136 whether signaled or provisioned. The protocol may be extended 137 for the administration of a variety of signaling protocols as 138 well as policy configuration on a device. 140 4. COPS provides message level security for authentication, 141 replay protection, and message integrity. COPS can also reuse 142 existing protocols for security such as IPSEC [IPSEC] or TLS to 143 authenticate and secure the channel between the PEP and the PDP. 145 5. The protocol is stateful in two main aspects: 146 (1) Request/Decision state is shared between client and server 147 and (2) State from various events (Request/Decision pairs) may 148 be inter-associated. By (1) we mean that requests from the 149 client PEP are installed or remembered by the remote PDP until 150 they are explicitly deleted by the PEP. At the same time, 151 Decisions from the remote PDP can be generated asynchronously at 152 any time for a currently installed request state. By (2) we mean 153 that the server may respond to new queries differently because 154 of previously installed Request/Decision state(s) that are 155 related. 157 6. Additionally, the protocol is stateful in that it allows the 158 server to push configuration information to the client, and then 159 allows the server to remove such state from the client when it 160 is no longer applicable. 162 1.1 Basic Model 164 +----------------+ 165 | | 166 | Network Node | Policy Server 167 | | 168 | +-----+ | COPS +-----+ 169 | | PEP |<-----|-------------->| PDP | 170 | +-----+ | +-----+ 171 | ^ | 172 | | | 173 | \-->+-----+ | 174 | | LDP | | 175 | +-----+ | 176 | | 177 +----------------+ 179 Figure 1: A COPS illustration. 181 Figure 1 Illustrates the layout of various policy components in a 182 typical COPS example (taken from [WRK]). Here, COPS is used to 183 communicate policy information between a Policy Enforcement Point 184 (PEP) and a remote Policy Decision Point (PDP) within the context of 185 a particular type of client. The optional Local Decision Point (LDP) 186 can be used by the device to make local policy decisions in the 187 absence of a PDP. 189 It is assumed that each participating policy client is functionally 190 consistent with a PEP [WRK]. The PEP may communicate with a policy 191 server (herein referred to as a remote PDP [WRK]) to obtain policy 192 decisions or directives. 194 The PEP is responsible for initiating a persistent TCP connection to 195 a PDP. The PEP uses this TCP connection to send requests to and 196 receive decisions from the remote PDP. Communication between the PEP 197 and remote PDP is mainly in the form of a stateful request/decision 198 exchange, though the remote PDP may occasionally send unsolicited 199 decisions to the PEP to force changes in previously approved request 200 states. The PEP also has the capacity to report to the remote PDP 201 that it has successfully completed performing the PDP's decision 202 locally, useful for accounting and monitoring purposes. The PEP is 203 responsible for notifying the PDP when a request state has changed 204 on the PEP. Finally, the PEP is responsible for the deletion of any 205 state that is no longer applicable due to events at the client or 206 decisions issued by the server. 208 When the PEP sends a configuration request, it expects the PDP to 209 continuously send named units of configuration data to the PEP via 210 decision messages as applicable for the configuration request. When 211 a unit of named configuration data is successfully installed on the 212 PEP, the PEP should send a report message to the PDP confirming the 213 installation. The server may then update or remove the named 214 configuration information via a new decision message. When the PDP 215 sends a decision to remove named configuration data from the PEP, 216 the PEP will delete the specified configuration and send a report 217 message to the PDP as confirmation. 219 The policy protocol is designed to communicate self-identifying 220 objects which contain the data necessary for identifying request 221 states, establishing the context for a request, identifying the type 222 of request, referencing previously installed requests, relaying 223 policy decisions, reporting errors, providing message integrity, and 224 transferring client specific/namespace information. 226 To distinguish between different kinds of clients, the type of 227 client is identified in each message. Different types of clients may 228 have different client specific data and may require different kinds 229 of policy decisions. It is expected that each new client-type will 230 have a corresponding usage draft specifying the specifics of its 231 interaction with this policy protocol. 233 The context of each request corresponds to the type of event that 234 triggered it. COPS identifies three types of outsourcing events: (1) 235 the arrival of an incoming message (2) allocation of local 236 resources, and (3) the forwarding of an outgoing message. Each of 237 these events may require different decisions to be made. Context sub 238 types are also available to describe the type of message that 239 triggered the policy event. The content of a COPS request/decision 240 message depends on the context. A fourth type of request is useful 241 for types of clients that wish to receive configuration information 242 from the PDP. This allows a PEP to issue a configuration request for 243 a specific named device or module that requires configuration 244 information to be installed. 246 The PEP may also have the capability to make a local policy decision 247 via its Local Decision Point (LDP) [WRK], however, the PDP remains 248 the authoritative decision point at all times. This means that the 249 relevant local decision information must be relayed to the PDP. That 250 is, the PDP must be granted access to all relevant information to 251 make a final policy decision. To facilitate this functionality, the 252 PEP must send its local decision information to the remote PDP via a 253 LDP decision object. The PEP must then abide by the PDP's decision 254 as it is absolute. 256 Finally, fault tolerance is a required capability for this protocol, 257 particularly due to the fact it is associated with the security and 258 service management of distributed network devices. Fault tolerance 259 can be achieved by having both the PEP and remote PDP constantly 260 verify their connection to each other via keep-alive messages. When 261 a failure is detected, the PEP must try to reconnect to the remote 262 PDP or attempt to connect to a backup/alternative PDP. While 263 disconnected, the PEP should revert to making local decisions. Once 264 a connection is reestablished, the PEP is expected to notify the PDP 265 of any deleted state or new events that passed local admission 266 control after the connection was lost. Additionally, the remote PDP 267 may request that all the PEP's internal state be resynchronized (all 268 previously installed requests are to be reissued). After failure and 269 before the new connection is fully functional, disruption of service 270 can be minimized if the PEP caches previously communicated decisions 271 and continues to use them for some limited amount of time. Sections 272 2.3 and 2.5 detail COPS mechanisms for achieving reliability. 274 2. The Protocol 276 This section describes the message formats and objects exchanged 277 between the PEP and remote PDP. 279 2.1 Common Header 281 Each COPS message consists of the COPS header followed by a number 282 of typed objects. 284 0 1 2 3 285 +--------------+--------------+--------------+--------------+ 286 |Version| Flags| Op Code | Client-type | 287 +--------------+--------------+--------------+--------------+ 288 | Message Length | 289 +--------------+--------------+--------------+--------------+ 291 Global note: //// implies field is reserved, set to 0. 293 The fields in the header are: 294 Version: 4 bits 295 COPS version number. Current version is 1. 297 Flags: 4 bits 298 Defined flag values (all other flags MUST be set to 0): 299 0x1 Solicited Message Flag Bit 300 This flag is set when the message is solicited by 301 another COPS message. This flag is NOT to be set 302 (value=0) unless otherwise specified in section 3. 304 Op Code: 8 bits 305 The COPS operations: 306 1 = Request (REQ) 307 2 = Decision (DEC) 308 3 = Report State (RPT) 309 4 = Delete Request State (DRQ) 310 5 = Synchronize State Req (SSQ) 311 6 = Client-Open (OPN) 312 7 = Client-Accept (CAT) 313 8 = Client-Close (CC) 314 9 = Keep-Alive (KA) 315 10= Synchronize Complete (SSC) 317 Client-type: 16 bits 319 The Client-type identifies the policy client. Interpretation of 320 all encapsulated objects is relative to the client-type. Client- 321 types that set the most significant bit in the client-type field 322 are enterprise specific (these are client-types 0x8000 - 323 0xFFFF). (See the specific client usage documents for particular 324 client-type IDs). For KA Messages, the client-type in the header 325 MUST always be set to 0 as the KA is used for connection 326 verification (not per client session verification). 328 Message Length: 32 bits 329 Size of message in octets, which includes the standard COPS 330 header and all encapsulated objects. Messages MUST be aligned on 331 4 octet intervals. 333 2.2 COPS Specific Object Formats 335 All the objects follow the same object format; each object consists 336 of one or more 32-bit words with a four-octet header, using the 337 following format: 339 0 1 2 3 340 +-------------+-------------+-------------+-------------+ 341 | Length (octets) | C-Num | C-Type | 342 +-------------+-------------+-------------+-------------+ 343 | | 344 // (Object contents) // 345 | | 346 +-------------+-------------+-------------+-------------+ 348 The length is a two-octet value that describes the number of octets 349 (including the header) that compose the object. If the length in 350 octets does not fall on a 32-bit word boundary, padding MUST be 351 added to the end of the object so that it is aligned to the next 32- 352 bit boundary before the object can be sent on the wire. On the 353 receiving side, a subsequent object boundary can be found by simply 354 rounding up the previous stated object length to the next 32-bit 355 boundary. 357 Typically, C-Num identifies the class of information contained in 358 the object, and the C-Type identifies the subtype or version of the 359 information contained in the object. 361 C-num: 8 bits 362 1 = Handle 363 2 = Context 364 3 = In Interface 365 4 = Out Interface 366 5 = Reason code 367 6 = Decision 368 7 = LDP Decision 369 8 = Error 370 9 = Client Specific Info 371 10 = Keep-Alive Timer 372 11 = PEP Identification 373 12 = Report Type 374 13 = PDP Redirect Address 375 14 = Last PDP Address 376 15 = Accounting Timer 377 16 = Message Integrity 379 C-type: 8 bits 380 Values defined per C-num. 382 2.2.1 Handle Object (Handle) 384 The Handle Object encapsulates a unique value that identifies an 385 installed state. This identification is used by most COPS 386 operations. A state corresponding to a handle MUST be explicitly 387 deleted when it is no longer applicable. See Section 2.4 for 388 details. 390 C-Num = 1 392 C-Type = 1, Client Handle. 394 Variable-length field, no implied format other than it is unique 395 from other client handles from the same PEP (a.k.a. COPS TCP 396 connection) for a particular client-type. It is always initially 397 chosen by the PEP and then deleted by the PEP when no longer 398 applicable. The client handle is used to refer to a request state 399 initiated by a particular PEP and installed at the PDP for a client- 400 type. A PEP will specify a client handle in its Request messages, 401 Report messages and Delete messages sent to the PDP. In all cases, 402 the client handle is used to uniquely identify a particular PEP's 403 request for a client-type. 405 The client handle value is set by the PEP and is opaque to the PDP. 406 The PDP simply performs a byte-wise comparison on the value in this 407 object with respect to the handle object values of other currently 408 installed requests. 410 2.2.2 Context Object (Context) 412 Specifies the type of event(s) that triggered the query. Required 413 for request messages. Admission control, resource allocation, and 414 forwarding requests are all amenable to client-types that outsource 415 their decision making facility to the PDP. For applicable client- 416 types a PEP can also make a request to receive named configuration 417 information from the PDP. This named configuration data may be in a 418 form useful for setting system attributes on a PEP, or it may be in 419 the form of policy rules that are to be directly verified by the 420 PEP. 422 Multiple flags can be set for the same request. This is only 423 allowed, however, if the set of client specific information in the 424 combined request is identical to the client specific information 425 that would be specified if individual requests were made for each 426 specified flag. 428 C-num = 2, C-Type = 1 430 0 1 2 3 431 +--------------+--------------+--------------+--------------+ 432 | R-Type | M-Type | 433 +--------------+--------------+--------------+--------------+ 435 R-Type (Request Type Flag) 437 0x01 = Incoming-Message/Admission Control request 438 0x02 = Resource-Allocation request 439 0x04 = Outgoing-Message request 440 0x08 = Configuration request 442 M-Type (Message Type) 444 Client Specific 16 bit values of protocol message types 446 2.2.3 In-Interface Object (IN-Int) 448 The In-Interface Object is used to identify the incoming interface 449 on which a particular request applies and the address where the 450 received message originated. For flows or messages generated from 451 the PEP's local host, the loop back address and ifindex are used. 453 This Interface object is also used to identify the incoming 454 (receiving) interface via its ifindex. The ifindex may be used to 455 differentiate between sub-interfaces and unnumbered interfaces (see 456 RSVP's LIH for an example). When SNMP is supported by the PEP, this 457 ifindex integer MUST correspond to the same integer value for the 458 interface in the SNMP MIB-II interface index table. 460 Note: The ifindex specified in the In-Interface is typically 461 relative to the flow of the underlying protocol messages. The 462 ifindex is the interface on which the protocol message was received. 464 C-Num = 3 466 C-Type = 1, IPv4 Address + Interface 467 0 1 2 3 468 +--------------+--------------+--------------+--------------+ 469 | IPv4 Address format | 470 +--------------+--------------+--------------+--------------+ 471 | ifindex | 472 +--------------+--------------+--------------+--------------+ 474 For this type of the interface object, the IPv4 address specifies 475 the IP address that the incoming message came from. 477 C-Type = 2, IPv6 Address + Interface 479 0 1 2 3 480 +--------------+--------------+--------------+--------------+ 481 | | 482 + + 483 | | 484 + IPv6 Address format + 485 | | 486 + + 487 | | 488 +--------------+--------------+--------------+--------------+ 489 | ifindex | 490 +--------------+--------------+--------------+--------------+ 492 For this type of the interface object, the IPv6 address specifies 493 the IP address that the incoming message came from. The ifindex is 494 used to refer to the MIB-II defined local incoming interface on the 495 PEP as described above. 497 2.2.4 Out-Interface Object (OUT-Int) 499 The Out-Interface is used to identify the outgoing interface to 500 which a specific request applies and the address for where the 501 forwarded message is to be sent. For flows or messages destined to 502 the PEP's local host, the loop back address and ifindex are used. 503 The Out-Interface has the same formats as the In-Interface Object. 505 This Interface object is also used to identify the outgoing 506 (forwarding) interface via its ifindex. The ifindex may be used to 507 differentiate between sub-interfaces and unnumbered interfaces (see 508 RSVP's LIH for an example). When SNMP is supported by the PEP, this 509 ifindex integer MUST correspond to the same integer value for the 510 interface in the SNMP MIB-II interface index table. 512 Note: The ifindex specified in the Out-Interface is typically 513 relative to the flow of the underlying protocol messages. The 514 ifindex is the one on which a protocol message is about to be 515 forwarded. 517 C-Num = 4 519 C-Type = 1, IPv4 Address + Interface 521 Same C-Type format as the In-Interface object. The IPv4 address 522 specifies the IP address to which the outgoing message is going. The 523 ifindex is used to refer to the MIB-II defined local outgoing 524 interface on the PEP. 526 C-Type = 2, IPv6 Address + Interface 528 Same C-Type format as the In-Interface object. For this type of the 529 interface object, the IPv6 address specifies the IP address to which 530 the outgoing message is going. The ifindex is used to refer to the 531 MIB-II defined local outgoing interface on the PEP. 533 2.2.5 Reason Object (Reason) 535 This object specifies the reason why the request state was deleted. 536 It appears in the delete request (DRQ) message. The Reason Sub-code 537 field is reserved for more detailed client-specific reason codes 538 defined in the corresponding documents. 540 C-Num = 5, C-Type = 1 542 0 1 2 3 543 +--------------+--------------+--------------+--------------+ 544 | Reason-Code | Reason Sub-code | 545 +--------------+--------------+--------------+--------------+ 547 Reason Code: 548 1 = Unspecified 549 2 = Management 550 3 = Preempted (Another request state takes precedence) 551 4 = Tear (Used to communicate a signaled state removal) 552 5 = Timeout (Local state has timed-out) 553 6 = Route Change (Change invalidates request state) 554 7 = Insufficient Resources (No local resource available) 555 8 = PDP's Directive (PDP decision caused the delete) 556 9 = Unsupported decision (PDP decision not supported) 557 10= Synchronize Handle Unknown 558 11= Transient Handle (stateless event) 559 12= Malformed Decision (could not recover) 560 13= Unknown COPS Object from PDP: 561 Sub-code (octet 2) contains unknown object's C-Num 562 and (octet 3) contains unknown object's C-Type. 564 2.2.6 Decision Object (Decision) 566 Decision made by the PDP. Appears in replies. The specific non- 567 mandatory decision objects required in a decision to a particular 568 request depend on the type of client. 570 C-Num = 6 571 C-Type = 1, Decision Flags (Mandatory) 573 0 1 2 3 574 +--------------+--------------+--------------+--------------+ 575 | Command-Code | Flags | 576 +--------------+--------------+--------------+--------------+ 578 Commands: 579 0 = NULL Decision (No configuration data available) 580 1 = Install (Admit request/Install configuration) 581 2 = Remove (Remove request/Remove configuration) 583 Flags: 584 0x01 = Trigger Error (Trigger error message if set) 585 Note: Trigger Error is applicable to client-types that 586 are capable of sending error notifications for signaled 587 messages. 589 Flag values not applicable to a given context's R-Type or 590 client-type MUST be ignored by the PEP. 592 C-Type = 2, Stateless Data 594 This type of decision object carries additional stateless 595 information that can be applied by the PEP locally. It is a 596 variable length object and its internal format SHOULD be 597 specified in the relevant COPS extension document for the given 598 client-type. This object is optional in Decision messages and is 599 interpreted relative to a given context. 601 It is expected that even outsourcing PEPs will be able to make 602 some simple stateless policy decisions locally in their LDP. As 603 this set is well known and implemented ubiquitously, PDPs are 604 aware of it as well (either universally, through configuration, 605 or using the Client-Open message). The PDP may also include this 606 information in its decision, and the PEP MUST apply it to the 607 resource allocation event that generated the request. 609 C-Type = 3, Replacement Data 611 This type of decision object carries replacement data that is to 612 replace existing data in a signaled message. It is a variable 613 length object and its internal format SHOULD be specified in the 614 relevant COPS extension document for the given client-type. It 615 is optional in Decision messages and is interpreted relative to 616 a given context. 618 C-Type = 4, Client Specific Decision Data 620 Additional decision types can be introduced using the Client 621 Specific Decision Data Object. It is a variable length object 622 and its internal format SHOULD be specified in the relevant COPS 623 extension document for the given client-type. It is optional in 624 Decision messages and is interpreted relative to a given 625 context. 627 C-Type = 5, Named Decision Data 629 Named configuration information is encapsulated in this version 630 of the decision object in response to configuration requests. It 631 is a variable length object and its internal format SHOULD be 632 specified in the relevant COPS extension document for the given 633 client-type. It is optional in Decision messages and is 634 interpreted relative to both a given context and decision flags. 636 2.2.7 LDP Decision Object (LDPDecision) 638 Decision made by the PEP's local decision point (LDP). May appear in 639 requests. These objects correspond to and are formatted the same as 640 the client specific decision objects defined above. 642 C-Num = 7 644 C-Type = (same C-Type as for Decision objects) 646 2.2.8 Error Object (Error) 648 This object is used to identify a particular COPS protocol error. 649 The error sub-code field contains additional detailed client 650 specific error codes. The appropriate Error Sub-codes for a 651 particular client-type SHOULD be specified in the relevant COPS 652 extensions document. 654 C-Num = 8, C-Type = 1 656 0 1 2 3 657 +--------------+--------------+--------------+--------------+ 658 | Error-Code | Error Sub-code | 659 +--------------+--------------+--------------+--------------+ 661 Error-Code: 663 1 = Bad handle 664 2 = Invalid handle reference 665 3 = Bad message format (Malformed Message) 666 4 = Unable to process (server gives up on query) 667 5 = Mandatory client-specific info missing 668 6 = Unsupported client-type 669 7 = Mandatory COPS object missing 670 8 = Client Failure 671 9 = Communication Failure 672 10= Unspecified 673 11= Shutting down 674 12= Redirect to Preferred Server 675 13= Unknown COPS Object: 676 Sub-code (octet 2) contains unknown object's C-Num 677 and (octet 3) contains unknown object's C-Type. 678 14= Authentication Failure 679 15= Authentication Required 681 2.2.9 Client Specific Information Object (ClientSI) 683 The various types of this object are required for requests, and used 684 in reports and opens when required. It contains client-type specific 685 information. 687 C-Num = 9, 688 C-Type = 1, Signaled ClientSI. 690 Variable-length field. All objects/attributes specific to a client's 691 signaling protocol or internal state are encapsulated within one or 692 more signaled Client Specific Information Objects. The format of the 693 data encapsulated in the ClientSI object is determined by the 694 client-type. 696 C-Type = 2, Named ClientSI. 698 Variable-length field. Contains named configuration information 699 useful for relaying specific information about the PEP, a request, 700 or configured state to the PDP server. 702 2.2.10 Keep-Alive Timer Object (KATimer) 704 Times are encoded as 2 octet integer values and are in units of 705 seconds. The timer value is treated as a delta. 707 C-Num = 10, 709 C-Type = 1, Keep-alive timer value 711 Timer object used to specify the maximum time interval over which a 712 COPS message MUST be sent or received. The range of finite timeouts 713 is 1 to 65535 seconds represented as an unsigned two-octet integer. 714 The value of zero implies infinity. 716 0 1 2 3 717 +--------------+--------------+--------------+--------------+ 718 | ////////////// | KA Timer Value | 719 +--------------+--------------+--------------+--------------+ 721 2.2.11 PEP Identification Object (PEPID) 723 The PEP Identification Object is used to identify the PEP client to 724 the remote PDP. It is required for Client-Open messages. 726 C-Num = 11, C-Type = 1 728 Variable-length field. It is a NULL terminated ASCII string that is 729 also zero padded to a 32-bit word boundary (so the object length is 730 a multiple of 4 octets). The PEPID MUST contain an ASCII string that 731 uniquely identifies the PEP within the policy domain in a manner 732 that is persistent across PEP reboots. For example, it may be the 733 PEP's statically assigned IP address or DNS name. This identifier 734 may safely be used by a PDP as a handle for identifying the PEP in 735 its policy rules. 737 2.2.12 Report-Type Object (Report-Type) 739 The Type of Report on the request state associated with a handle: 741 C-Num = 12, C-Type = 1 743 0 1 2 3 744 +--------------+--------------+--------------+--------------+ 745 | Report-Type | ///////////// | 746 +--------------+--------------+--------------+--------------+ 748 Report-Type: 749 1 = Success : Decision was successful at the PEP 750 2 = Failure : Decision could not be completed by PEP 751 3 = Accounting: Accounting update for an installed state 753 2.2.13 PDP Redirect Address (PDPRedirAddr) 755 A PDP when closing a PEP session for a particular client-type may 756 optionally use this object to redirect the PEP to the specified PDP 757 server address and TCP port number: 759 C-Num = 13, 761 C-Type = 1, IPv4 Address + TCP Port 762 0 1 2 3 763 +--------------+--------------+--------------+--------------+ 764 | IPv4 Address format | 765 +--------------+--------------+--------------+--------------+ 766 | ///////////////////////// | TCP Port Number | 767 +-----------------------------+-----------------------------+ 769 C-Type = 2, IPv6 Address + TCP Port 770 0 1 2 3 771 +--------------+--------------+--------------+--------------+ 772 | | 773 + + 774 | | 775 + IPv6 Address format + 776 | | 777 + + 778 | | 779 +--------------+--------------+--------------+--------------+ 780 | ///////////////////////// | TCP Port Number | 781 +-----------------------------+-----------------------------+ 783 2.2.14 Last PDP Address (LastPDPAddr) 785 When a PEP sends a Client-Open message for a particular client-type 786 the PEP SHOULD specify the last PDP it has successfully opened 787 (meaning it received a Client-Accept) since the PEP last rebooted. 788 If no PDP was used since the last reboot, the PEP will simply not 789 include this object in the Client-Open message. 791 C-Num = 14, 792 C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) 794 C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) 796 2.2.15 Accounting Timer Object (AcctTimer) 798 Times are encoded as 2 octet integer values and are in units of 799 seconds. The timer value is treated as a delta. 801 C-Num = 15, 803 C-Type = 1, Accounting timer value 805 Optional timer value used to determine the minimum interval between 806 periodic accounting type reports. It is used by the PDP to describe 807 to the PEP an acceptable interval between unsolicited accounting 808 updates via Report messages where applicable. It provides a method 809 for the PDP to control the amount of accounting traffic seen by the 810 network. The range of finite time values is 1 to 65535 seconds 811 represented as an unsigned two-octet integer. A value of zero means 812 there SHOULD be no unsolicited accounting updates. 814 0 1 2 3 815 +--------------+--------------+--------------+--------------+ 816 | ////////////// | ACCT Timer Value | 817 +--------------+--------------+--------------+--------------+ 819 2.2.16 Message Integrity Object (Integrity) 821 The integrity object includes a sequence number and a message digest 822 useful for authenticating and validating the integrity of a COPS 823 message. When used, integrity is provided at the end of a COPS 824 message as the last COPS object. The digest is then computed over 825 all of a particular COPS message up to but not including the digest 826 value itself. The sender of a COPS message will compute and fill in 827 the digest portion of the Integrity object. The receiver of a COPS 828 message will then compute a digest over the received message and 829 verify it matches the digest in the received Integrity object. 831 C-Num = 16, 833 C-Type = 1, HMAC digest 835 The HMAC integrity object employs HMAC (Keyed-Hashing for Message 836 Authentication) [HMAC] to calculate the message digest based on a 837 key shared between the PEP and its PDP. 839 This Integrity object specifies a 32-bit Key ID used to identify a 840 specific key shared between a particular PEP and its PDP and the 841 cryptographic algorithm to be used. The Key ID allows for multiple 842 simultaneous keys to exist on the PEP with corresponding keys on the 843 PDP for the given PEPID. The key identified by the Key ID was used 844 to compute the message digest in the Integrity object. All 845 implementations, at a minimum, MUST support HMAC-MD5-96, which is 846 HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 847 96-bits to calculate the message digest. 849 This object also includes a sequence number that is a 32-bit 850 unsigned integer used to avoid replay attacks. The sequence number 851 is initiated during an initial Client-Open Client-Accept message 852 exchange and is then incremented by one each time a new message is 853 sent over the TCP connection in the same direction. If the sequence 854 number reaches the value of 0xFFFFFFFF, the next increment will 855 simply rollover to a value of zero. 857 The variable length digest is calculated over a COPS message 858 starting with the COPS Header up to the Integrity Object (which MUST 859 be the last object in a COPS message) INCLUDING the Integrity 860 object's header, Key ID, and Sequence Number. The Keyed Message 861 Digest field is not included as part of the digest calculation. In 862 the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that 863 is then to be truncated to 96-bits before being stored in or 864 verified against the Keyed Message Digest field as specified in 865 [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is 866 used. 868 0 1 2 3 869 +-------------+-------------+-------------+-------------+ 870 | Key ID | 871 +-------------+-------------+-------------+-------------+ 872 | Sequence Number | 873 +-------------+-------------+-------------+-------------+ 874 | | 875 + + 876 | ...Keyed Message Digest... | 877 + + 878 | | 879 +-------------+-------------+-------------+-------------+ 881 2.3 Communication 883 The COPS protocol uses a single persistent TCP connection between 884 the PEP and a remote PDP. One PDP implementation per server MUST 885 listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP 886 is responsible for initiating the TCP connection to a PDP. The 887 location of the remote PDP can either be configured, or obtained via 888 a service location mechanism [SRVLOC]. Service discovery is outside 889 the scope of this protocol, however. 891 If a single PEP can support multiple client-types, it may send 892 multiple Client-Open messages, each specifying a particular client- 893 type to a PDP over one or more TCP connections. Likewise, a PDP 894 residing at a given address and port number may support one or more 895 client-types. Given the client-types it supports, a PDP has the 896 ability to either accept or reject each client-type independently. 897 If a client-type is rejected, the PDP can redirect the PEP to an 898 alternative PDP address and TCP port for a given client-type via 899 COPS. Different TCP port numbers can be used to redirect the PEP to 900 another PDP implementation running on the same server. Additional 901 provisions for supporting multiple client-types (perhaps from 902 independent PDP vendors) on a single remote PDP server are not 903 provided by the COPS protocol, but, rather, are left to the software 904 architecture of the given server platform. 906 It is possible a single PEP may have open connections to multiple 907 PDPs. This is the case when there are physically different PDPs 908 supporting different client-types as shown in figure 2. 910 +----------------+ 911 | | 912 | Network Node | Policy Servers 913 | | 914 | +-----+ | COPS Client Type 1 +-----+ 915 | | |<-----|-------------------->| PDP1| 916 | + PEP + | COPS Client Type 2 +-----+ 917 | | |<-----|---------\ +-----+ 918 | +-----+ | \----------| PDP2| 919 | ^ | +-----+ 920 | | | 921 | \-->+-----+ | 922 | | LDP | | 923 | +-----+ | 924 | | 925 +----------------+ 926 Figure 2: Multiple PDPs illustration. 928 When a TCP connection is torn down or is lost, the PDP is expected 929 to eventually clean up any outstanding request state related to 930 request/decision exchanges with the PEP. When the PEP detects a lost 931 connection due to a timeout condition it SHOULD explicitly send a 932 Client-Close message for each opened client-type containing an 933 object indicating the "Communication Failure" Error-Code. 934 Additionally, the PEP SHOULD continuously attempt to contact the 935 primary PDP or, if unsuccessful, any known backup PDPs. Specifically 936 the PEP SHOULD keep trying all relevant PDPs with which it has been 937 configured until it can establish a connection. If a PEP is in 938 communication with a backup PDP and the primary PDP becomes 939 available, the backup PDP is responsible for redirecting the PEP 940 back to the primary PDP (via a message containing a 941 object identifying the primary PDP to use for each 942 affected client-type). Section 2.5 details synchronization behavior 943 between PEPs and PDPs. 945 2.4 Client Handle Usage 947 The client handle is used to identify a unique request state for a 948 single PEP per client-type. Client handles are chosen by the PEP and 949 are opaque to the PDP. The PDP simply uses the request handle to 950 uniquely identify the request state for a particular Client-Type 951 over a particular TCP connection and generically tie its decisions 952 to a corresponding request. Client handles are initiated in request 953 messages and are then used by subsequent request, decision, and 954 report messages to reference the same request state. When the PEP is 955 ready to remove a local request state, it will issue a delete 956 message to the PDP for the corresponding client handle. A handle 957 MUST be explicitly deleted by the PEP before it can be used by the 958 PEP to identify a new request state. Handles referring to different 959 request states MUST be unique within the context of a particular TCP 960 connection and client-type. 962 2.5 Synchronization Behavior 964 When disconnected from a PDP, the PEP SHOULD revert to making local 965 decisions. Once a connection is reestablished, the PEP is expected 966 to notify the PDP of any events that have passed local admission 967 control. Additionally, the remote PDP may request that all the PEP's 968 internal state be resynchronized (all previously installed requests 969 are to be reissued) by sending a Synchronize State message. 971 After a failure and before a new connection is fully functional, 972 disruption of service can be minimized if the PEP caches previously 973 communicated decisions and continues to use them for some 974 appropriate length of time. Specific rules for such behavior are to 975 be defined in the appropriate COPS client-type extension 976 specifications. 978 A PEP that caches state from a previous exchange with a disconnected 979 PDP MUST communicate this fact to any PDP with which it is able to 980 later reconnect. This is accomplished by including the address and 981 TCP port of the last PDP for which the PEP is still caching state in 982 the Client-Open message. The object will only be 983 included for the last PDP with which the PEP was completely in sync. 984 If the service interruption was temporary and the PDP still contains 985 the complete state for the PEP, the PDP may choose not to 986 synchronize all states. It is still the responsibility of the PEP to 987 update the PDP of all state changes that occurred during the 988 disruption of service including any states communicated to the 989 previous PDP that had been deleted after the connection was lost. 990 These MUST be explicitly deleted after a connection is 991 reestablished. If the PDP issues a synchronize request the PEP MUST 992 pass all current states to the PDP followed by a Synchronize State 993 Complete message (thus completing the synchronization process). If 994 the PEP crashes and loses all cached state for a client-type, it 995 will simply not include a in its Client-Open message. 997 3. Message Content 999 This section describes the basic messages exchanged between a PEP 1000 and a remote PDP as well as their contents. As a convention, object 1001 ordering is expected as shown in the BNF for each COPS message 1002 unless otherwise noted. The Integrity object, if included, MUST 1003 always be the last object in a message. If security is required and 1004 a message was received without a valid Integrity object, the 1005 receiver MUST send a Client-Close message for Client-Type=0 1006 specifying the appropriate error code. 1008 3.1 Request (REQ) PEP -> PDP 1010 The PEP establishes a request state client handle for which the 1011 remote PDP may maintain state. The remote PDP then uses this handle 1012 to refer to the exchanged information and decisions communicated 1013 over the TCP connection to a particular PEP for a given client-type. 1015 Once a stateful handle is established for a new request, any 1016 subsequent modifications of the request can be made using the REQ 1017 message specifying the previously installed handle. The PEP is 1018 responsible for notifying the PDP whenever its local state changes 1019 so the PDP's state will be able to accurately mirror the PEP's 1020 state. 1022 The format of the Request message is as follows: 1024 ::= 1025 1026 1027 [] 1028 [] 1029 [] 1030 [] 1031 [] 1033 ::= | 1035 ::= | 1036 1038 The context object is used to determine the context within which all 1039 the other objects are to be interpreted. It also is used to 1040 determine the kind of decision to be returned from the policy 1041 server. This decision might be related to admission control, 1042 resource allocation, object forwarding and substitution, or 1043 configuration. 1045 The interface objects are used to determine the corresponding 1046 interface on which a signaling protocol message was received or is 1047 about to be sent. They are typically used if the client is 1048 participating along the path of a signaling protocol or if the 1049 client is requesting configuration data for a particular interface. 1051 ClientSI, the client specific information object, holds the client- 1052 type specific data for which a policy decision needs to be made. In 1053 the case of configuration, the Named ClientSI may include named 1054 information about the module, interface, or functionality to be 1055 configured. The ordering of multiple ClientSIs is not important. 1057 Finally, LDPDecision object holds information regarding the local 1058 decision made by the LDP. 1060 Malformed Request messages MUST result in the PDP specifying a 1061 Decision message with the appropriate error code. 1063 3.2 Decision (DEC) PDP -> PEP 1065 The PDP responds to the REQ with a DEC message that includes the 1066 associated client handle and one or more decision objects grouped 1067 relative to a Context object and Decision Flags object type pair. If 1068 there was a protocol error an error object is returned instead. 1070 It is required that the first decision message for a new/updated 1071 request will have the solicited message flag set (value = 1) in the 1072 COPS header. This avoids the issue of keeping track of which updated 1073 request (that is, a request reissued for the same handle) a 1074 particular decision corresponds. It is important that, for a given 1075 handle, there be at most one outstanding solicited decision per 1076 request. This essentially means that the PEP SHOULD NOT issue more 1077 than one REQ (for a given handle) before it receives a corresponding 1078 DEC with the solicited message flag set. The PDP MUST always issue 1079 decisions for requests on a particular handle in the order they 1080 arrive and all requests MUST have a corresponding decision. 1082 To avoid deadlock, the PEP can always timeout after issuing a 1083 request that does not receive a decision. It MUST then delete the 1084 timed-out handle, and may try again using a new handle. 1086 The format of the Decision message is as follows: 1088 ::= 1089 1090 | 1091 [] 1093 ::= | 1095 ::= 1096 1097 [] 1098 [] 1099 [] 1100 [] 1102 The Decision message may include either an Error object or one or 1103 more context plus associated decision objects. COPS protocol 1104 problems are reported in the Error object (e.g. an error with the 1105 format of the original request including malformed request messages, 1106 unknown COPS objects in the Request, etc.). The applicable Decision 1107 object(s) depend on the context and the type of client. The only 1108 ordering requirement for decision objects is that the required 1109 Decision Flags object type MUST precede the other Decision object 1110 types per context binding. 1112 3.3 Report State (RPT) PEP -> PDP 1114 The RPT message is used by the PEP to communicate to the PDP its 1115 success or failure in carrying out the PDP's decision, or to report 1116 an accounting related change in state. The Report-Type specifies the 1117 kind of report and the optional ClientSI can carry additional 1118 information per Client-Type. 1120 For every DEC message containing a configuration context that is 1121 received by a PEP, the PEP MUST generate a corresponding Report 1122 State message with the Solicited Message flag set describing its 1123 success or failure in applying the configuration decision. In 1124 addition, outsourcing decisions from the PDP MAY result in a 1125 corresponding solicited Report State from the PEP depending on the 1126 context and the type of client. RPT messages solicited by decisions 1127 for a given Client Handle MUST set the Solicited Message flag and 1128 MUST be sent in the same order as their corresponding Decision 1129 messages were received. There MUST never be more than one Report 1130 State message generated with the Solicited Message flag set per 1131 Decision. 1133 The Report State may also be used to provide periodic updates of 1134 client specific information for accounting and state monitoring 1135 purposes depending on the type of the client. In such cases the 1136 accounting report type should be specified utilizing the appropriate 1137 client specific information object. 1139 ::== 1140 1141 1142 [] 1143 [] 1145 3.4 Delete Request State (DRQ) PEP -> PDP 1147 When sent from the PEP this message indicates to the remote PDP that 1148 the state identified by the client handle is no longer 1149 available/relevant. This information will then be used by the remote 1150 PDP to initiate the appropriate housekeeping actions. The reason 1151 code object is interpreted with respect to the client-type and 1152 signifies the reason for the removal. 1154 The format of the Delete Request State message is as follows: 1156 ::= 1157 1158 1159 [] 1161 Given the stateful nature of COPS, it is important that when a 1162 request state is finally removed from the PEP, a DRQ message for 1163 this request state is sent to the PDP so the corresponding state may 1164 likewise be removed on the PDP. Request states not explicitly 1165 deleted by the PEP will be maintained by the PDP until either the 1166 client session is closed or the connection is terminated. 1168 Malformed Decision messages MUST trigger a DRQ specifying the 1169 appropriate erroneous reason code (Bad Message Format) and any 1170 associated state on the PEP SHOULD either be removed or re- 1171 requested. If a Decision contained an unknown COPS Decision Object, 1172 the PEP MUST delete its request specifying the Unknown COPS Object 1173 reason code because the PEP will be unable to comply with the 1174 information contained in the unknown object. In any case, after 1175 issuing a DRQ, the PEP may retry the corresponding Request again. 1177 3.5 Synchronize State Request (SSQ) PDP -> PEP 1179 The format of the Synchronize State Query message is as follows: 1181 ::= 1182 [] 1183 [] 1185 This message indicates that the remote PDP wishes the client (which 1186 appears in the common header) to re-send its state. If the optional 1187 Client Handle is present, only the state associated with this handle 1188 is synchronized. If the PEP does not recognize the requested handle, 1189 it MUST immediately send a DRQ message to the PDP for the handle 1190 that was specified in the SSQ message. If no handle is specified in 1191 the SSQ message, all the active client state MUST be synchronized 1192 with the PDP. 1194 The client performs state synchronization by re-issuing request 1195 queries of the specified client-type for the existing state in the 1196 PEP. When synchronization is complete, the PEP MUST issue a 1197 synchronize state complete message to the PDP. 1199 3.6 Client-Open (OPN) PEP -> PDP 1201 The Client-Open message can be used by the PEP to specify to the PDP 1202 the client-types the PEP can support, the last PDP to which the PEP 1203 connected for the given client-type, and/or client specific feature 1204 negotiation. A Client-Open message can be sent to the PDP at any 1205 time and multiple Client-Open messages for the same client-type are 1206 allowed (in case of global state changes). 1208 ::= 1209 1210 [] 1211 [] 1212 [] 1214 The PEPID is a symbolic, variable length name that uniquely 1215 identifies the specific client to the PDP (see Section 2.2.11). 1217 A named ClientSI object can be included for relaying additional 1218 global information about the PEP to the PDP when required (as 1219 specified in the appropriate extensions document for the client- 1220 type). 1222 The PEP may also provide a Last PDP Address object in its Client- 1223 Open message specifying the last PDP (for the given client-type) for 1224 which it is still caching decisions since its last reboot. A PDP can 1225 use this information to determine the appropriate synchronization 1226 behavior (See section 2.5). 1228 If the PDP receives a malformed Client-Open message it MUST generate 1229 a Client-Close message specifying the appropriate error code. 1231 3.7 Client-Accept (CAT) PDP -> PEP 1233 The Client-Accept message is used to positively respond to the 1234 Client-Open message. This message will return to the PEP a timer 1235 object indicating the maximum time interval between keep-alive 1236 messages. Optionally, a timer specifying the minimum allowed 1237 interval between accounting report messages may be included when 1238 applicable. 1240 ::= 1241 1242 [] 1243 [] 1245 If the PDP refuses the client, it will instead issue a Client-Close 1246 message. 1248 The KA Timer corresponds to maximum acceptable intermediate time 1249 between the generation of messages by the PDP and PEP. The timer 1250 value is determined by the PDP and is specified in seconds. A timer 1251 value of 0 implies no secondary connection verification is 1252 necessary. 1254 The optional ACCT Timer allows the PDP to indicate to the PEP that 1255 periodic accounting reports SHOULD NOT exceed the specified timer 1256 interval per client handle. This allows the PDP to control the rate 1257 at which accounting reports are sent by the PEP (when applicable). 1258 In general, accounting type Report messages are sent to the PDP when 1259 determined appropriate by the PEP. The accounting timer merely is 1260 used by the PDP to keep the rate of such updates in check (i.e. 1261 Preventing the PEP from blasting the PDP with accounting reports). 1262 Not including this object implies there are no PDP restrictions on 1263 the rate at which accounting updates are generated. 1265 If the PEP receives a malformed Client-Accept message it MUST 1266 generate a Client-Close message specifying the appropriate error 1267 code. 1269 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP 1271 The Client-Close message can be issued by either the PDP or PEP to 1272 notify the other that a particular type of client is no longer being 1273 supported. 1275 ::= 1276 1277 [] 1278 [] 1280 The Error object is included to describe the reason for the close 1281 (e.g. the requested client-type is not supported by the remote PDP 1282 or client failure). 1284 A PDP MAY optionally include a PDP Redirect Address object in order 1285 to inform the PEP of the alternate PDP it SHOULD use for the client- 1286 type specified in the common header. 1288 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 1290 The keep-alive message MUST be transmitted by the PEP within the 1291 period defined by the minimum of all KA Timer values specified in 1292 all received CAT messages for the connection. A KA message MUST be 1293 generated randomly between 1/4 and 3/4 of this minimum KA timer 1294 interval. When the PDP receives a keep-alive message from a PEP, it 1295 MUST echo a keep-alive back to the PEP. This message provides 1296 validation for each side that the connection is still functioning 1297 even when there is no other messaging. 1299 Note: The client-type in the header MUST always be set to 0 as the 1300 KA is used for connection verification (not per client session 1301 verification). 1303 ::= 1304 [] 1306 Both client and server MAY assume the TCP connection is insufficient 1307 for the client-type with the minimum time value (specified in the 1308 CAT message) if no communication activity is detected for a period 1309 exceeding the timer period. For the PEP, such detection implies the 1310 remote PDP or connection is down and the PEP SHOULD now attempt to 1311 use an alternative/backup PDP. 1313 3.10 Synchronize State Complete (SSC) PEP -> PDP 1315 The Synchronize State Complete is sent by the PEP to the PDP after 1316 the PDP sends a synchronize state request to the PEP and the PEP has 1317 finished synchronization. It is useful so that the PDP will know 1318 when all the old client state has been successfully re-requested 1319 and, thus, the PEP and PDP are completely synchronized. The Client 1320 Handle object only needs to be included if the corresponding 1321 Synchronize State Message originally referenced a specific handle. 1323 ::= 1324 [] 1325 [] 1327 4. Common Operation 1329 This section describes the typical exchanges between remote PDP 1330 servers and PEP clients. 1332 4.1 Security and Sequence Number Negotiation 1334 COPS message security is negotiated once per connection and covers 1335 all communication over a particular connection. If COPS level 1336 security is required, it MUST be negotiated during the initial 1337 Client-Open/Client-Accept message exchange specifying a Client-Type 1338 of zero (which is reserved for connection level security negotiation 1339 and connection verification). 1341 If a PEP is not configured to use COPS security with a PDP it will 1342 simply send the PDP Client-Open messages for the supported Client- 1343 Types as specified in section 4.3 and will not include the Integrity 1344 object in any COPS messages. 1346 Otherwise, security can be initiated by the PEP if it sends the PDP 1347 a Client-Open message with Client-Type=0 before opening any other 1348 Client-Type. If the PDP receives a Client-Open with a Client-Type=0 1349 after another Client-Type has already been opened successfully it 1350 MUST return a Client-Close message (for Client-Type=0) to that PEP. 1351 This first Client-Open message MUST specify a Client-Type of zero 1352 and MUST provide the PEPID and a COPS Integrity object. This 1353 Integrity object will contain the initial sequence number the PEP 1354 requires the PDP to increment during subsequent communication after 1355 the initial Client-Open/Client-Accept exchange and the Key ID 1356 identifying the algorithm and key used to compute the digest. 1358 Similarly, if the PDP accepts the PEP's security key and algorithm 1359 by validating the message digest using the identified key, the PDP 1360 MUST send a Client-Accept message with a Client-Type of zero to the 1361 PEP carrying an Integrity object. This Integrity object will contain 1362 the initial sequence number the PDP requires the PEP to increment 1363 during all subsequent communication with the PDP and the Key ID 1364 identifying the key and algorithm used to compute the digest. 1366 If the PEP, from the perspective of a PDP that requires security, 1367 fails or never performs the security negotiation by not sending an 1368 initial Client-Open message with a Client-Type=0 including a valid 1369 Integrity object, the PDP MUST send to the PEP a Client-Close 1370 message with a Client-Type=0 specifying the appropriate error code. 1371 Similarly, if the PDP, from the perspective of a PEP that requires 1372 security, fails the security negotiation by not sending back a 1373 Client-Accept message with a Client-Type=0 including a valid 1374 Integrity object, the PEP MUST send to the PDP a Client-Close 1375 message with a Client-Type=0 specifying the appropriate error code. 1376 Such a Client-Close message need not carry an integrity object (as 1377 the security negotiation did not yet complete). 1379 The security initialization can fail for one of several reasons: 1. 1380 The side receiving the message requires COPS level security but an 1381 Integrity object was not provided (Authentication Required error 1382 code). 2. A COPS Integrity object was provided, but with an 1383 unknown/unacceptable C-Type (Unknown COPS Object error code 1384 specifying the unsupported C-Num and C-Type). 3. The message digest 1385 or Key ID in the provided Integrity object was incorrect and 1386 therefore the message could not be authenticated using the 1387 identified key (Authentication Failure error code). 1389 Once the initial security negotiation is complete, the PEP will know 1390 what sequence numbers the PDP expects and the PDP will know what 1391 sequence numbers the PEP expects. ALL COPS messages must then 1392 include the negotiated Integrity object specifying the correct 1393 sequence number with the appropriate message digest (including the 1394 Client-Open/Client-Accept messages for specific Client-Types). ALL 1395 subsequent messages from the PDP to the PEP MUST result in an 1396 increment of the sequence number provided by the PEP in the 1397 Integrity object of the initial Client-Open message. Likewise, ALL 1398 subsequent messages from the PEP to the PDP MUST result in an 1399 increment of the sequence number provided by the PDP in the 1400 Integrity object of the initial Client-Accept message. Sequence 1401 numbers are incremented by one starting with the corresponding 1402 initial sequence number. For example, if the sequence number 1403 specified to the PEP by the PDP in the initial Client-Accept was 10, 1404 the next message the PEP sends to the PDP will provide an Integrity 1405 object with a sequence number of 11... Then the next message the PEP 1406 sends to the PDP will have a sequence number of 12 and so on. If any 1407 subsequent received message contains the wrong sequence number, an 1408 unknown Key ID, an invalid message digest, or is missing an 1409 Integrity object after integrity was negotiated, then a Client-Close 1410 message MUST be generated for the Client-Type zero containing a 1411 valid Integrity object and specifying the appropriate error code. 1412 The connection should then be dropped. 1414 4.2 Key Maintenance 1416 Key maintenance is outside the scope of this document, but COPS 1417 implementations MUST at least provide the ability to manually 1418 configure keys and their parameters locally. The key used to produce 1419 the Integrity object's message digest is identified by the Key ID 1420 field. Thus, a Key ID parameter is used to identify one of 1421 potentially multiple simultaneous keys shared by the PEP and PDP. A 1422 Key ID is relative to a particular PEPID on the PDP or to a 1423 particular PDP on the PEP. Each key must also be configured with 1424 lifetime parameters for the time period within which it is valid as 1425 well as an associated cryptographic algorithm parameter specifying 1426 the algorithm to be used with the key. At a minimum, all COPS 1427 implementations MUST support the HMAC-MD5-96 [HMAC][MD5] 1428 cryptographic algorithm for computing a message digest for inclusion 1429 in the Keyed Message Digest of the Integrity object which is 1430 appended to the message. 1432 It is good practice to regularly change keys. Keys MUST be 1433 configurable such that their lifetimes overlap allowing smooth 1434 transitions between keys. At the midpoint of the lifetime overlap 1435 between two keys, senders should transition from using the current 1436 key to the next/longer-lived key. Meanwhile, receivers simply accept 1437 any identified key received within its configured lifetime and 1438 reject those that are not. 1440 4.3 PEP Initialization 1442 Sometime after a connection is established between the PEP and a 1443 remote PDP and after security is negotiated (if required), the PEP 1444 will send one or more Client-Open messages to the remote PDP, one 1445 for each client-type supported by the PEP. The Client-Open message 1446 MUST contain the address of the last PDP with which the PEP is still 1447 caching a complete set of decisions. If no decisions are being 1448 cached from the previous PDP the LastPDPAddr object MUST NOT be 1449 included in the Client-Open message (see Section 2.5). Each Client- 1450 Open message MUST at least contain the common header noting one 1451 client-type supported by the PEP. The remote PDP will then respond 1452 with separate Client-Accept messages for each of the client-types 1453 requested by the PEP that the PDP can also support. 1455 If a specific client-type is not supported by the PDP, the PDP will 1456 instead respond with a Client-Close specifying the client-type is 1457 not supported and will possibly suggest an alternate PDP address and 1458 port. Otherwise, the PDP will send a Client-Accept specifying the 1459 timer interval between keep-alive messages and the PEP may begin 1460 issuing requests to the PDP. 1462 4.4 Outsourcing Operations 1464 In the outsourcing scenario, when the PEP receives an event that 1465 requires a new policy decision it sends a request message to the 1466 remote PDP. What specifically qualifies as an event for a particular 1467 client-type SHOULD be specified in the specific document for that 1468 client-type. The remote PDP then makes a decision and sends a 1469 decision message back to the PEP. Since the request is stateful, the 1470 request will be remembered, or installed, on the remote PDP. The 1471 unique handle (unique per TCP connection and client-type), specified 1472 in both the request and its corresponding decision identifies this 1473 request state. The PEP is responsible for deleting this request 1474 state once the request is no longer applicable. 1476 The PEP can update a previously installed request state by reissuing 1477 a request for the previously installed handle. The remote PDP is 1478 then expected to make new decisions and send a decision message back 1479 to the PEP. Likewise, the server MAY change a previously issued 1480 decision on any currently installed request state at any time by 1481 issuing an unsolicited decision message. At all times the PEP module 1482 is expected to abide by the PDP's decisions and notify the PDP of 1483 any state changes. 1485 4.5 Configuration Operations 1487 In the configuration scenario, as in the outsourcing scenario, the 1488 PEP will make a configuration request to the PDP for a particular 1489 interface, module, or functionality that may be specified in the 1490 named client specific information object. The PDP will then send 1491 potentially several decisions containing named units of 1492 configuration data to the PEP. The PEP is expected to install and 1493 use the configuration locally. A particular named configuration can 1494 be updated by simply sending additional decision messages for the 1495 same named configuration. When the PDP no longer wishes the PEP to 1496 use a piece of configuration information, it will send a decision 1497 message specifying the named configuration and a decision flags 1498 object with the remove configuration command. The PEP SHOULD then 1499 proceed to remove the corresponding configuration and send a report 1500 message to the PDP that specifies it has been deleted. 1502 In all cases, the PEP MAY notify the remote PDP of the local status 1503 of an installed state using the report message where appropriate. 1504 The report message is to be used to signify when billing can begin, 1505 what actions were taken, or to produce periodic updates for 1506 monitoring and accounting purposes depending on the client. This 1507 message can carry client specific information when needed. 1509 4.6 Keep-Alive Operations 1511 The Keep-Alive message is used to validate the connection between 1512 the client and server is still functioning even when there is no 1513 other messaging from the PEP to PDP. The PEP MUST generate a COPS KA 1514 message randomly within one-fourth to three-fourths the minimum KA 1515 Timer interval specified by the PDP in the Client-Accept message. On 1516 receiving a Keep-Alive message from the PEP, the PDP MUST then 1517 respond to this Keep-Alive message by echoing a Keep-Alive message 1518 back to the PEP. If either side does not receive a Keep-Alive or any 1519 other COPS message within the minimum KA Timer interval from the 1520 other, the connection SHOULD be considered lost. 1522 4.7 PEP/PDP Close 1524 Finally, Client-Close messages are used to negate the effects of the 1525 corresponding Client-Open messages, notifying the other side that 1526 the specified client-type is no longer supported/active. When the 1527 PEP detects a lost connection due to a keep-alive timeout condition 1528 it SHOULD explicitly send a Client-Close message for each opened 1529 client-type specifying a communications failure error code. Then the 1530 PEP MAY proceed to terminate the connection to the PDP and attempt 1531 to reconnect again or try a backup/alternative PDP. When the PDP is 1532 shutting down, it SHOULD also explicitly send a Client-Close to all 1533 connected PEPs for each client-type, perhaps specifying an 1534 alternative PDP to use instead. 1536 5. Security Considerations 1538 The COPS protocol provides an Integrity object that can achieve 1539 authentication, message integrity, and replay prevention. All COPS 1540 implementations MUST support the COPS Integrity object and its 1541 mechanisms as described in this document. To ensure the client (PEP) 1542 is communicating with the correct policy server (PDP) requires 1543 authentication of the PEP and PDP using a shared secret, and 1544 consistent proof that the connection remains valid. The shared 1545 secret minimally requires manual configuration of keys (identified 1546 by a Key ID) shared between the PEP and its PDP. The key is used in 1547 conjunction with the contents of a COPS message to calculate a 1548 message digest that is part of the Integrity object. The Integrity 1549 object is then used to validate all COPS messages sent over the TCP 1550 connection between a PEP and PDP. 1552 Key maintenance is outside the scope of this document beyond the 1553 specific requirements discussed in section 4.2. In general, it is 1554 good practice to regularly change keys to maintain security. 1555 Furthermore, it is good practice to use localized keys specific to a 1556 particular PEP such that a stolen PEP will not compromise the 1557 security of an entire administrative domain. 1559 The COPS Integrity object also provides sequence numbers to avoid 1560 replay attacks. The PDP chooses the initial sequence number for the 1561 PEP and the PEP chooses the initial sequence number for the PDP. 1562 These initial numbers are then incremented with each successive 1563 message sent over the connection in the corresponding direction. The 1564 initial sequence numbers SHOULD be chosen such that they are 1565 monotonically increasing and never repeat for a particular key. 1567 Security between the client (PEP) and server (PDP) MAY be provided 1568 by IP Security [IPSEC]. In this case, the IPSEC Authentication 1569 Header (AH) SHOULD be used for the validation of the connection; 1570 additionally IPSEC Encapsulation Security Payload (ESP) MAY be used 1571 to provide both validation and secrecy. 1573 Transport Layer Security [TLS] MAY be used for both connection-level 1574 validation and privacy. 1576 6. IANA Considerations 1578 The Client-type identifies the policy client application to which a 1579 message refers. Client-type values within the range 0x0001-0x3FFF 1580 are reserved Specification Required status as defined in [IANA- 1581 CONSIDERATIONS]. These values MUST be registered with IANA and their 1582 behavior and applicability MUST be described in a COPS extension 1583 document. 1585 Client-type values in the range 0x4000 - 0x7FFF are reserved for 1586 Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types 1587 are not tracked by IANA and are not to be used in standards or 1588 general-release products, as their uniqueness cannot be assured. 1590 Client-type values in the range 0x8000 - 0xFFFF are First Come First 1591 Served as defined in [IANA-CONSIDERATIONS]. These Client-types are 1592 tracked by IANA but do not require published documents describing 1593 their use. IANA merely assures their uniqueness. 1595 Objects in the COPS Protocol are identified by their C-Num and C- 1596 Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] 1597 is required to introduce new values for these numbers and, 1598 therefore, new objects into the base COPS protocol. 1600 Additional Context Object R-Types, Reason-Codes, Report-Types, 1601 Decision Object Command-Codes/Flags, and Error-Codes MAY be defined 1602 for use with future Client-types, but such additions require IETF 1603 Consensus as defined in [IANA-CONSIDERATIONS]. 1605 Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be 1606 defined relative to a particular Client-type following the same IANA 1607 considerations as their respective Client-type. 1609 7. References 1611 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 1612 Version 1 - Functional Specification", RFC 2205, September 1613 1997. 1615 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 1616 Control", Internet-Draft, draft-ietf-rap-framework-01.txt, 1617 November 1998. 1619 [SRVLOC]Guttman, E. et al., "Service Location Protocol , Version 2", 1620 Internet-Draft, RFC 2608, June 1999. 1622 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 1623 Parameters for Integrated Service Network Elements", RFC 1624 2215, September 1997. 1626 [IPSEC] Atkinson, R., "Security Architecture for the Internet 1627 Protocol", RFC 2401, August 1995. 1629 [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 1630 for Message Authentication", RFC 2104, February 1997. 1632 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1633 April 1992. 1635 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 1636 - Version 1 Message Processing Rules", RFC 2209, September 1637 1997. 1639 [TLS] Dierks T., Allen C., "The TLS Protocol Version 1.0", RFC 1640 2246, January 1999. 1642 [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers 1644 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1645 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1646 2434, October 1998. 1648 8. Author Information and Acknowledgments 1650 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 1651 Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch 1652 Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable 1653 contributions. 1655 Jim Boyle Ron Cohen 1656 Level 3 Communications Cisco Systems 1657 1450 Infinite Drive13 Hasadna St. 1658 Louisville, CO 80027 Ra'anana 43650 Israel 1659 303.926.3100 972.9.7462020 1660 email: jboyle@l3.net ronc@classdata.com 1662 David Durham Raju Rajan 1663 Intel AT&T Shannon Laboratory 1664 2111 NE 25th Avenue 180 Park Avenue 1665 Hillsboro, OR 97124 P.O. Box 971 1666 503.264.6232 Florham Park, NJ 07932-0971 1667 David.Durham@mail.intel.com rajan@research.att.com 1669 Shai Herzog Arun Sastry 1670 IPHighway Cisco Systems 1671 Parker Plaza, 16th Floor 506210 W Tasman Drive 1672 400 Kelby St. Fort-Lee NJ 07024 San Jose, CA 95134 1673 201.585.0800 408.526.7685 1674 herzog@iphighway.com asastry@cisco.com