idnits 2.17.1 draft-ietf-rap-rsvp-ext-06.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references (COPS-RSVP], [RSVP], [RAP,COPS,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (April 8, 1999) is 9122 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-RSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MD5' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Shai Herzog 2 Expiration: October 1999 IPHighway 3 File: draft-ietf-rap-rsvp-ext-06.txt 4 Updates RFC 2205 6 RSVP Extensions for Policy Control 8 April 8, 1999 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo presents a set of extensions for supporting generic policy 34 based admission control in RSVP. It should be perceived as an 35 extension to the RSVP functional specifications [RSVP] 37 These extensions include the standard format of POLICY_DATA objects, 38 and a description of RSVP's handling of policy events. 40 This document does not advocate particular policy control 41 mechanisms; 42 however, a Router/Server Policy Protocol description for these 43 extensions can be found in [RAP, COPS, COPS-RSVP]. 45 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 47 Table of Contents 49 Abstract.............................................................1 50 Table of Contents....................................................2 51 1 Introduction.......................................................3 52 2 A Simple Scenario..................................................3 53 3 Policy Data Objects................................................4 54 3.1 Base Format.....................................................4 55 3.2 Options.........................................................5 56 3.3 Policy Elements.................................................7 57 3.4 Purging Policy State............................................7 58 4 Processing Rules...................................................8 59 4.1 Basic Signaling.................................................8 60 4.2 Default Handling for PIN nodes..................................8 61 4.3 Error Signaling.................................................8 62 5 IANA Considerations................................................9 63 6 Security Considerations............................................9 64 7 References........................................................10 65 8 Acknowledgments...................................................10 66 9 Author Information................................................10 67 Appendix A : Policy Error Codes.....................................11 68 Appendix B : INTEGRITY computation for POLICY_DATA objects..........12 69 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 71 1 Introduction 73 RSVP, by definition, discriminates between users, by providing some 74 users with better service at the expense of others. Therefore, it is 75 reasonable to expect that RSVP be accompanied by mechanisms for 76 controlling and enforcing access and usage policies. Ver. 1 of the 77 RSVP Functional Specifications [RSVP] left a placeholder for policy 78 support in the form of POLICY_DATA object. 80 The current RSVP Functional Specification describes the interface to 81 admission (traffic) control that is based "only" on resource 82 availability. In this document we describe a set of extensions to 83 RSVP for supporting policy based admission control as well. The 84 scope of this document is limited to these extensions and does not 85 advocate specific architectures for policy based controls. 87 For the purpose of this document we do not differentiate between 88 Policy Decision Point (PDP) and Local Decision Point (LDPs) as 89 described in [RAP]. The term PDP should be assumed to include LDP as 90 well. 92 2 A Simple Scenario 94 It is generally assumed that policy enforcement (at least in its 95 initial stages) is likely to concentrate on border nodes between 96 autonomous systems. 98 Figure 1 illustrates a simple autonomous domain with two boundary 99 nodes (A, C) which represent PEPs controlled by PDPs. A core node 100 (B) represents an RSVP capable policy ignorant node (PIN) with 101 capabilities limited to default policy handling (Section 4.2). 103 PDP1 PDP2 104 | | 105 | | 106 +---+ +---+ +---+ 107 | A +---------+ B +---------+ C | 108 +---+ +---+ +---+ 109 PEP2 PIN PEP2 111 Figure 1: Autonomous Domain scenario 113 Here, policy objects transmitted across the domain traverse an 114 intermediate PIN node (B) that is allowed to process RSVP message 115 but considered non-trusted for handling policy information. 117 This document describes processing rules for both PEP as well as PIN 118 nodes. 120 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 122 3 Policy Data Objects 124 POLICY_DATA objects are carried by RSVP messages and contain policy 125 information. All policy-capable nodes (at any location in the 126 network) can generate, modify, or remove policy objects, even when 127 senders or receivers do not provide, and may not even be aware of 128 policy data objects. 130 The exchange of POLICY_DATA objects between policy-capable nodes 131 along the data path, supports the generation of consistent end-to- 132 end policies. Furthermore, such policies can be successfully 133 deployed across multiple administrative domains when border nodes 134 manipulate and translate POLICY_DATA objects according to 135 established sets of bilateral agreements. 137 The following extends section A.13 in [RSVP]. 139 3.1 Base Format 141 POLICY_DATA class=14 143 o Type 1 POLICY_DATA object: Class=14, C-Type=1 145 +-------------+-------------+-------------+-------------+ 146 | Length | POLICY_DATA | 1 | 147 +---------------------------+-------------+-------------+ 148 | Data Offset | 0 (reserved) | 149 +---------------------------+-------------+-------------+ 150 | | 151 // Option List // 152 | | 153 +-------------------------------------------------------+ 154 | | 155 // Policy Element List // 156 | | 157 +-------------------------------------------------------+ 159 Data Offset: 16 bits 161 The offset in bytes of the data portion (from the first 162 byte of the object header). 164 Reserved: 16 bits 166 Always 0. 168 Option List: Variable length 170 The list of options and their usage is defined in Section 171 3.2. 173 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 175 Policy Element List: Variable length 177 The contents of policy elements is opaque to RSVP. See more 178 details in Section 3.3. 180 3.2 Options 182 This section describes a set of options that may appear in 183 POLICY_DATA objects. All policy options appear as RSVP objects but 184 their semantic is modified when used as policy data options. 186 FILTER_SPEC object (list) or SCOPE object 188 These objects describe the set of senders associated with the 189 POLICY_DATA object. If none is provided, the policy information is 190 assumed to be associated with all the flows of the session. These 191 two types of objects are mutually exclusive, and cannot be mixed. 193 In Packed FF Resv messages, this FILTER_SPEC option provides 194 association between a reserved flow and its POLICY_DATA objects. 196 In WF or SE styles, this option preserves the original 197 flow/POLICY_DATA association as formed by PDPs, even across RSVP 198 capable PINs. Such preservation is required since PIN nodes may 199 change the list of reserved flows on a per-hop basis, irrespective 200 of legitimate Edge-to-Edge PDP policy considerations. 202 Last, the SCOPE object should be used to prevent "policy loops" in a 203 manner similar to the one described in [RSVP], Section 3.4. When PIN 204 nodes are part of a WF reservation path, the RSVP SCOPE object is 205 unable to prevent policy loops and the separate policy SCOPE object 206 is required. 208 Note: using the SCOPE option may have significant impact on scaling 209 and size of POLICY_DATA objects. 211 Originating RSVP_HOP 213 The RSVP_HOP object identifies the neighbor/peer policy-capable node 214 that constructed the policy object. When policy is enforced at 215 border nodes, peer policy nodes may be several RSVP hops away from 216 each other and the originating RSVP_HOP is the basis for the 217 mechanism that allows them to recognize each other and communicate 218 safely and directly. 220 If no RSVP_HOP object is present, the policy data is implicitly 221 assumed to have been constructed by the RSVP_HOP indicated in the 222 RSVP message itself (i.e., the neighboring RSVP node is policy- 223 capable). 225 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 227 Destination RSVP_HOP 229 A second RSVP_HOP object may follow the originating RSVP_HOP object. 230 This second RSVP_HOP identifies the destination policy node. This is 231 used to ensure the POLICY_DATA object is delivered to targeted 232 policy nodes. It may be used to emulate unicast delivery in 233 multicast Path messages. It may also help prevent using a policy 234 object in other parts of the network (replay attack). 236 On the receiving side, a policy node should ignore any POLICY_DATA 237 that includes a destination RSVP_HOP that doesn't match its own IP 238 address. 240 INTEGRITY Object 242 Figure 1 (Section 2) provides an example where POLICY_DATA objects 243 are transmitted between boundary nodes while traversing non-secure 244 PIN nodes. In this scenario, the RSVP integrity mechanism becomes 245 ineffective since it places policy trust with intermediate PIN nodes 246 (which are trusted to perform RSVP signaling but not to perform 247 policy decisions or manipulations). 249 The INTEGRITY object option inside POLICY_DATA object creates direct 250 secure communications between non-neighboring PEPs (and their 251 controlling PDPs) without involving PIN nodes. 253 This option can be used at the discretion of PDPs, and is computed 254 in a manner described in Appendix B. 256 Policy Refresh TIME_VALUES (PRT) 258 The Policy Refresh TIME_VALUES (PRT) option is used to slow policy 259 refresh frequency for policies that have looser timing constraints 260 relative to RSVP. If the PRT option is present, policy refreshes can 261 be withheld as long as at least one refresh is sent before the 262 policy refresh timer expires. A minimal value for PRT is R; lower 263 values are assumed to be R (neither error nor warning should be 264 triggered). 266 To simplify RSVP processing, time values are not based directly on 267 the PRT value, but on a Policy Refresh Multiplier N computed as 268 N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP] 269 Section 3.7 assuming the refresh period for PRT POLICY DATA is R' 270 computed as R'=N*R. In effect, both the refresh and the state 271 cleanup are slowed by a factor of N). 273 The refresh multiplier applies to no-change periodic refreshes only 274 (rather than updates). For example, a policy being refreshed at time 275 T, T+N, T+2N,... may encounter a route change detected at T+X. In 276 this case, the event would force an immediate policy update and 277 would reset refresh times to T+X, T+X+N, T+X+2N,... 279 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 281 When network nodes restart, RSVP messages between PRT policy 282 refreshes may be rejected since they arrive without necessary 283 POLICY_DATA objects. This error situation would clear with the next 284 periodic policy refresh or with a policy update triggered by ResvErr 285 or PathErr messages. 287 This option is especially useful to combine strong (high overhead) 288 and weak (low overhead) authentication certificates as policy data. 289 In such schemes the weak certificate can support admitting a 290 reservation only for a limited time, after which the strong 291 certificate is required. 293 This approach may reduce the overhead of POLICY_DATA processing. 294 Strong certificates could be transmitted less frequently, while weak 295 certificates are included in every RSVP refresh. 297 3.3 Policy Elements 299 The content of policy elements is opaque to RSVP; their internal 300 format is understood by policy peers e.g. an RSVP Local Decision 301 Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of 302 policy element codepoints and their meaning is maintained by [IANA- 303 CONSIDERATIONS] (also see Section 5). 305 Policy Elements have the following format: 307 +-------------+-------------+-------------+-------------+ 308 | Length | P-Type | 309 +---------------------------+---------------------------+ 310 | | 311 // Policy information (Opaque to RSVP) // 312 | | 313 +-------------------------------------------------------+ 315 3.4 Purging Policy State 317 Policy state expires in the granularity of Policy Elements 318 (POLICY_DATA objects are mere containers and do not expire as such). 320 Policy elements expire in the exact manner and time as the RSVP 321 state received in the same message (see [RSVP] Section 3.7). PRT 322 controlled state expires N times slower (see Section 3.2). 324 Only one policy element of a certain P-Type can be active at any 325 given time. Therefore, policy elements are instantaneously replaced 326 when another policy element of the same P-Type is received from the 327 same PDP (previous or next policy RSVP_HOP). An empty policy element 328 of a certain P-Type is used to delete (rather than a replace) all 329 policy state of the same P-Type. 331 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 333 4 Processing Rules 335 These sections describe the minimal required policy processing rules 336 for RSVP. 338 4.1 Basic Signaling 340 This draft mandates enforcing policy control for Path, Resv, 341 PathErr, and ResvErr messages only. PathTear and ResvTear are 342 assumed not to require policy control based on two main 343 presumptions. First, that Integrity verification [MD5] guarantee 344 that the Tear is received from the same node that sent the installed 345 reservation, and second, that it is functionally equivalent to that 346 node holding-off refreshes for this reservation. 348 4.2 Default Handling for PIN nodes 350 Figure 1 illustrates an example of where policy data objects 351 traverse PIN nodes in transit from one PEP to another. 353 A PIN node is required at a minimum to forward the received 354 POLICY_DATA objects in the appropriate outgoing messages according 355 to the following rules: 357 o POLICY_DATA objects are to be forwarded as is, without any 358 modifications. 360 o Multicast merging (splitting) nodes: 362 In the upstream direction: 364 When multiple POLICY_DATA objects arrive from downstream, the 365 RSVP node should concatenate all of them (as a list of the 366 original POLICY_DATA objects) and forward them with the 367 outgoing (upstream) message. 369 On the downstream direction: 371 When a single incoming POLICY_DATA object arrives from 372 upstream, it should be forwarded (copied) to all downstream 373 branches of the multicast tree. 375 The same rules apply to unrecognized policies (sub-objects) within 376 the POLICY_DATA object. However, since this can only occur in a 377 policy-capable node, it is the responsibility of the PDP and not 378 RSVP. 380 4.3 Error Signaling 382 Policy errors are reported by either ResvErr or PathErr messages 383 with a policy failure error code in the ERROR_SPEC object. Policy 384 error message must include a POLICY_DATA object; the object contains 386 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 388 details of the error type and reason in a P-Type specific format 389 (See Section 3.3). 391 If a multicast reservation fails due to policy reasons, RSVP should 392 not attempt to discover which reservation caused the failure (as it 393 would do for Blockade State). Instead, it should attempt to deliver 394 the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) 395 decide where messages should be sent. This mechanism allows the PDP 396 to limit the error distribution by deciding which "culprit" next- 397 hops should be informed. It also allows the PDP to prevent further 398 distribution of ResvErr or PathErr messages by performing local 399 repair (e.g. substituting the failed POLICY_DATA object with a 400 different one). 402 Error codes are described in Appendix Appendix A. 404 5 IANA Considerations 406 RSVP Policy Elements (P-Types) 408 Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- 409 49151 are allocated as standard policy elements by IETF Consensus 410 action, numbers in the range 49152-53247 are allocated as vendor 411 specific (one per vendor) by First Come First Serve, and numbers 412 53248-65535 are reserved for private use and are not assigned by 413 IANA. 415 6 Security Considerations 417 This draft describes the use of POLICY_DATA objects to carry policy- 418 related information between RSVP nodes. Two security mechanisms can 419 be optionally used to ensure the integrity of the carried 420 information. The first mechanism relies on RSVP integrity [MD5] to 421 provide a chain of trust when all RSVP nodes are policy capable. The 422 second mechanism relies on the INTEGRITY object within the 423 POLICY_DATA object to guarantee integrity between non-neighboring 424 RSVP PEPs (see Sections 2 and 3.2). 426 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 428 7 References 430 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 431 Control",IETF , Jan., 1999. 433 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 434 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 435 IETF , Jan. 1999. 437 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 438 Sastry, A., "COPS Usage for RSVP", IETF , Feb. 1999. 441 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 442 Functional Specification.", IETF RFC 2205, Proposed Standard, 443 Sep. 1997. 445 [MD5] Baker, F., Lindell B., Talwar, M. "RSVP Cryptographic 446 Authentication" Internet-Draft, , 447 Feb. 1999. 449 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 450 Writing an IANA Considerations Section in RFCs", RFC 2434, 451 October 1998. 453 8 Acknowledgments 455 This document incorporates inputs from Lou Berger, Bob Braden, 456 Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, 457 Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many 458 others. 460 9 Author Information 462 Shai Herzog, IPHighway 463 Parker Plaza, 16th Floor 464 400 Kelby St. 465 Fort-Lee, NJ 07024 466 (201) 585-0800 467 herzog@iphighway.com 469 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 471 Appendix A : Policy Error Codes 473 This Appendix extends the list of error codes described in Appendix 474 B of [RSVP]. 476 Note that Policy Element specific errors are reported as described 477 in Section 4.3 and cannot be reported through RSVP (using this 478 mechanism). However, this mechanism provides a simple, less secure 479 mechanism for reporting generic policy errors. Most likely the two 480 would be used in concert such that a generic error code is provided 481 by RSVP, while Policy Element specific errors are encapsulated in a 482 return POLICY_DATA object (as in Section 4.3). 484 ERROR_SPEC class = 6 486 Error Code = 02: Policy Control failure 488 Error Value: 16 bit 490 0 = ERR_INFO : Information reporting 491 1 = ERR_WARN : Warning 492 2 = ERR_UNKNOWN : Reason unknown 493 3 = ERR_REJECT : Generic Policy Rejection 494 4 = ERR_EXCEED : Quota or Accounting violation 495 5 = ERR_PREEMPT : Flow was preempted 496 6 = ERR_EXPIRED : Previously installed policy expired (not 497 refreshed) 498 7 = ERR_REPLACED: Previous policy data was replaced & caused 499 rejection 500 8 = ERR_MERGE : Policies could not be merged (multicast) 501 9 = ERR_PDP : PDP down or non functioning 502 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 503 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 504 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 505 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 506 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD 507 object) 508 15= ERR_NO_RSC : PEP Out of resources to handle policies. 509 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 510 17= ERR_SERVICE : Service type was rejected 511 18= ERR_STYLE : Reservation Style was rejected 512 19= ERR_FL_SPEC : FlowSpec was rejected (too large) 514 Values between 2^15 and 2^16-1 can be used for site and/or vendor 515 error values. 517 Internet Draft RSVP Extensions for Policy Control 8-Apr-99 519 Appendix B : INTEGRITY computation for POLICY_DATA objects 521 Computation of the INTEGRITY option is based on the rules set forth in 522 [MD5], with the following modifications: 524 Section 4.1: 526 Rather than computing digest for an RSVP message, a digest is 527 computed for a POLICY_DATA object in the following manner: 529 (1) The INTEGRITY object is inserted in the appropriate place in 530 the POLICY_DATA object, and its location in the message is 531 remembered for later use. 533 (2) The PDP, at its discretion, and based on destination PEP/PDP 534 or other criteria, selects an Authentication Key and the hash 535 algorithm to be used. 537 (3) A copy of RSVP SESSION object is temporarily appended to the 538 end of the PD object (for the computation purposes only, 539 without changing the length of the POLICY_DATA object). The 540 flags field of the SESSION object is set to 0. This 541 concatenation is considered as the message for which a digest 542 is to be computed. 544 (4) The rest of the steps in Section 4.1 ((4)..(9)) remain 545 unchanged when computed over the concatenated message. 547 Note: When the computation is complete, the SESSION object is 548 ignored and is not part of the POLICY_DATA object. 550 Other Provisions: 552 The processing of a received POLICY_DATA object as well as a challenge- 553 response INTEGRITY object inside a POLICY_DATA object is performed in 554 the manner described in [MD5]. This processing is subject to the 555 modified computation algorithm as described in the beginning of this 556 appendix (for Section 4.1 of [MD5]).