idnits 2.17.1 draft-ietf-rap-rsvp-ext-05.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 2, 1999) is 9149 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. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: October 1999 IPHighway 4 File: draft-ietf-rap-rsvp-ext-05.txt 5 Updates RFC 2205 7 RSVP Extensions for Policy Control 9 April 2, 1999 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo presents a set of extensions for supporting generic policy 35 based admission control in RSVP. It should be perceived as an 36 extension to the RSVP functional specifications [RSVP] 38 These extensions include the standard format of POLICY_DATA objects, 39 and a description of RSVP's handling of policy events. 41 This document does not advocate particular policy control 42 mechanisms; 43 however, a Router/Server Policy Protocol description for these 44 extensions can be found in [RAP, COPS, COPS-RSVP]. 46 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 48 Table of Contents 50 Abstract.............................................................1 51 Table of Contents....................................................2 52 1 Introduction.......................................................3 53 2 Policy Data Objects................................................3 54 2.1 Base Format.....................................................4 55 2.2 Options.........................................................4 56 2.3 Policy Elements.................................................6 57 2.4 Purging Policy State............................................7 58 3 Processing Rules...................................................7 59 3.1 Basic Signaling.................................................7 60 3.2 Default Handling................................................7 61 3.3 Error Signaling.................................................8 62 4 IANA Considerations................................................9 63 5 Security Considerations............................................9 64 6 References........................................................10 65 7 Acknowledgments...................................................10 66 8 Author Information................................................10 67 Appendix A: Policy Error Codes......................................11 68 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 70 1 Introduction 72 RSVP, by definition, discriminates between users, by providing some 73 users with better service at the expense of others. Therefore, it is 74 reasonable to expect that RSVP be accompanied by mechanisms for 75 controlling and enforcing access and usage policies. Ver. 1 of the 76 RSVP Functional Specifications [RSVP] left a placeholder for policy 77 support in the form of POLICY_DATA object. 79 The current RSVP Functional Specification describes the interface to 80 admission (traffic) control that is based "only" on resource 81 availability. In this document we describe a set of extensions to 82 RSVP for supporting policy based admission control as well. The 83 scope of this document is limited to these extensions and does not 84 advocate specific architectures for policy based controls. 86 For the purpose of this document we do not differentiate between 87 Policy Decision Point (PDP) and Local Decision Point (LDPs) as 88 described in [RAP]. The term PDP should be assumed to include LDP as 89 well. 91 2 Policy Data Objects 93 POLICY_DATA objects are carried by RSVP messages and contain policy 94 information. All policy-capable nodes (at any location in the 95 network) can generate, modify, or remove policy objects, even when 96 senders or receivers do not provide, and may not even be aware of 97 policy data objects. 99 The exchange of POLICY_DATA objects between policy-capable nodes 100 along the data path, supports the generation of consistent end-to- 101 end policies. Furthermore, such policies can be successfully 102 deployed across multiple administrative domains when border nodes 103 manipulate and translate POLICY_DATA objects according to 104 established sets of bilateral agreements. 106 The following extends section A.13 in [RSVP]. 108 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 110 2.1 Base Format 112 POLICY_DATA class=14 114 o Type 1 POLICY_DATA object: Class=14, C-Type=1 116 +-------------+-------------+-------------+-------------+ 117 | Length | POLICY_DATA | 1 | 118 +---------------------------+-------------+-------------+ 119 | Data Offset | 0 (reserved) | 120 +---------------------------+-------------+-------------+ 121 | | 122 // Option List // 123 | | 124 +-------------------------------------------------------+ 125 | | 126 // Policy Element List // 127 | | 128 +-------------------------------------------------------+ 130 Data Offset: 16 bits 132 The offset in bytes of the data portion (from the first 133 byte of the object header). 135 Reserved: 16 bits 137 Always 0. 139 Option List: Variable length 141 The list of options and their usage is defined in Section 142 2.2. 144 Policy Element List: Variable length 146 The contents of policy elements is opaque to RSVP. See more 147 details in Section 2.3. 149 2.2 Options 151 This section describes a set of options that may appear in 152 POLICY_DATA objects. All policy options appear as RSVP objects but 153 their semantic is modified when used as policy data options. 155 FILTER_SPEC object (list) or SCOPE object 157 These objects describe the set of senders associated with the 158 POLICY_DATA object. If none is provided, the policy information is 159 assumed to be associated with all the flows of the session. These 160 two types of objects are mutually exclusive, and cannot be mixed. 162 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 164 In Packed FF Resv messages, this FILTER_SPEC option provides 165 association between a reserved flow and its POLICY_DATA objects. 167 In WF or SE styles, this option preserves the original 168 flow/POLICY_DATA association as formed by PDPs, even across RSVP 169 capable PIN nodes. Such preservation is required since PIN nodes may 170 change the list of reserved flows on a per-hop basis, irrespective 171 of legitimate Edge-to-Edge PDP policy considerations. 173 Last, the SCOPE object should be used to prevent "policy loops" in a 174 manner similar to the one described in [RSVP], Section 3.4. When PIN 175 nodes are part of a WF reservation path, the RSVP SCOPE object is 176 unable to prevent policy loops and the separate policy SCOPE object 177 is required. 179 Note: using the SCOPE option may have significant impact on scaling 180 and size of POLICY_DATA objects. 182 Originating RSVP_HOP 184 The RSVP_HOP object identifies the neighbor/peer policy-capable node 185 that constructed the policy object. When policy is enforced at 186 border nodes, peer policy nodes may be several RSVP hops away from 187 each other and the originating RSVP_HOP is the basis for the 188 mechanism that allows them to recognize each other and communicate 189 safely and directly. 191 If no RSVP_HOP object is present, the policy data is implicitly 192 assumed to have been constructed by the RSVP_HOP indicated in the 193 RSVP message itself (i.e., the neighboring RSVP node is policy- 194 capable). 196 Destination RSVP_HOP 198 A second RSVP_HOP object may follow the originating RSVP_HOP object. 199 This second RSVP_HOP identifies the destination policy node. This is 200 used to ensure the POLICY_DATA object is delivered to targeted 201 policy nodes. It may be used to emulate unicast delivery in 202 multicast Path messages. It may also help prevent using a policy 203 object in other parts of the network (replay attack). 205 On the receiving side, a policy node should ignore any POLICY_DATA 206 that includes a destination RSVP_HOP that doesn't match its own IP 207 address. 209 INTEGRITY Object 211 The INTEGRITY object provides guarantees that the object was not 212 compromised. It follows the rules from [MD5], and is calculated over 214 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 216 the POLICY_DATA object, the SESSION object, and the message type 217 field (byte, padded with zero to 32 bit) as if they formed one 218 continuous in-order message. This concatenation is designed to 219 prevent copy and replay attacks of POLICY_DATA objects from other 220 sessions, flows, message types or even other network locations. 222 Policy Refresh TIME_VALUES (PRT) 224 The Policy Refresh TIME_VALUES (PRT) option is used to slow policy 225 refresh frequency for policies that have looser timing constraints 226 relative to RSVP. If the PRT option is present, policy refreshes can 227 be withheld as long as at least one refresh is sent before the 228 policy refresh timer expires. A minimal value for PRT is R; lower 229 values are assumed to be R (neither error nor warning should be 230 triggered). 232 To simplify RSVP processing, time values are not based directly on 233 the PRT value, but on a Policy Refresh Multiplier N computed as 234 N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP] 235 Section 3.7 assuming the refresh period for PRT POLICY DATA is R' 236 computed as R'=N*R. In effect, both the refresh and the state 237 cleanup are slowed by a factor of N). 239 The refresh multiplier applies to no-change periodic refreshes only 240 (rather than updates). For example, a policy being refreshed at time 241 T, T+N, T+2N,... may encounter a route change detected at T+X. In 242 this case, the event would force an immediate policy update and 243 would reset refresh times to T+X, T+X+N, T+X+2N,... 245 When network nodes restart, RSVP messages between PRT policy 246 refreshes may be rejected since they arrive without necessary 247 POLICY_DATA objects. This error situation would clear with the next 248 periodic policy refresh or with a policy update triggered by ResvErr 249 or PathErr messages. 251 This option is especially useful to combine strong (high overhead) 252 and weak (low overhead) authentication certificates as policy data. 253 In such schemes the weak certificate can support admitting a 254 reservation only for a limited time, after which the strong 255 certificate is required. 257 This approach may reduce the overhead of POLICY_DATA processing. 258 Strong certificates could be transmitted less frequently, while weak 259 certificates are included in every RSVP refresh. 261 2.3 Policy Elements 263 The content of policy elements is opaque to RSVP; their internal 264 format is understood by policy peers e.g. an RSVP Local Decision 265 Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of 267 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 269 policy element codepoints and their meaning is maintained by [IANA- 270 CONSIDERATIONS] (also see Section 4). 272 Policy Elements have the following format: 274 +-------------+-------------+-------------+-------------+ 275 | Length | P-Type | 276 +---------------------------+---------------------------+ 277 | | 278 // Policy information (Opaque to RSVP) // 279 | | 280 +-------------------------------------------------------+ 282 2.4 Purging Policy State 284 Policy state expires in the granularity of Policy Elements 285 (POLICY_DATA objects are mere containers and do not expire as such). 287 Policy elements expire in the exact manner and time as the RSVP 288 state received in the same message (see [RSVP] Section 3.7). PRT 289 controlled state expires N times slower (see Section 2.2). 291 Only one policy element of a certain P-Type can be active at any 292 given time. Therefore, policy elements are instantaneously replaced 293 when another policy element of the same P-Type is received from the 294 same PDP (previous or next policy RSVP_HOP). An empty policy element 295 of a certain P-Type is used to delete (rather than a replace) all 296 policy state of the same P-Type. 298 3 Processing Rules 300 These sections describe the minimal required policy processing rules 301 for RSVP. 303 3.1 Basic Signaling 305 This draft mandates enforcing policy control for Path, Resv, 306 PathErr, and ResvErr messages only. PathTear and ResvTear are 307 assumed not to require policy control based on two main 308 presumptions. First, that Integrity verification [MD5] guarantee 309 that the Tear is received from the same node that sent the installed 310 reservation, and second, that it is functionally equivalent to that 311 node holding-off refreshes for this reservation. 313 3.2 Default Handling 315 It is generally assumed that policy enforcement (at least in its 316 initial stages) is likely to concentrate on border nodes between 317 autonomous systems. Consequently, policy objects transmitted at one 318 edge of an autonomous cloud may traverse intermediate policy 319 ignorant RSVP nodes (PINs). A PIN is required at a minimum to 321 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 323 forward the received POLICY_DATA objects in the appropriate outgoing 324 messages according to the following rules: 326 o POLICY_DATA objects are to be forwarded as is, without any 327 modifications. 329 o Multicast merging (splitting) nodes: 331 In the upstream direction: 333 When multiple POLICY_DATA objects arrive from downstream, the 334 RSVP node should concatenate all of them (as a list of the 335 original POLICY_DATA objects) and forward them with the 336 outgoing (upstream) message. 338 On the downstream direction: 340 When a single incoming POLICY_DATA object arrives from 341 upstream, it should be forwarded (copied) to all downstream 342 branches of the multicast tree. 344 The same rules apply to unrecognized policies (sub-objects) within 345 the POLICY_DATA object. However, since this can only occur in a 346 policy-capable node, it is the responsibility of the PDP and not 347 RSVP. 349 3.3 Error Signaling 351 Policy errors are reported by either ResvErr or PathErr messages 352 with a policy failure error code in the ERROR_SPEC object. Policy 353 error message must include a POLICY_DATA object; the object contains 354 details of the error type and reason in a P-Type specific format 355 (See Section 2.3). 357 If a multicast reservation fails due to policy reasons, RSVP should 358 not attempt to discover which reservation caused the failure (as it 359 would do for Blockade State). Instead, it should attempt to deliver 360 the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) 361 decide where messages should be sent. This mechanism allows the PDP 362 to limit the error distribution by deciding which "culprit" next- 363 hops should be informed. It also allows the PDP to prevent further 364 distribution of ResvErr or PathErr messages by performing local 365 repair (e.g. substituting the failed POLICY_DATA object with a 366 different one). 368 Error codes are described in Appendix A. 370 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 372 4 IANA Considerations 374 RSVP Policy Elements (P-Types) 376 Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- 377 49151 are allocated as standard policy elements by IETF Consensus 378 action, numbers in the range 49152-53247 are allocated as vendor 379 specific (one per vendor) by First Come First Serve, and numbers 380 53248-65535 are reserved for private use and are not assigned by 381 IANA. 383 5 Security Considerations 385 This draft describes the use of POLICY_DATA objects to carry policy- 386 related information between RSVP nodes. Two security mechanisms can 387 be optionally used to ensure the integrity of the carried 388 information. The first mechanism relies on RSVP integrity [MD5] to 389 provide a chain of trust when all RSVP nodes are policy capable. The 390 second mechanism relies on the INTEGRITY object within the 391 POLICY_DATA object to guarantee integrity between non-neighboring 392 RSVP PEPs (see Section 2.2). 394 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 396 6 References 398 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 399 Control",IETF , Jan., 1999. 401 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 402 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 403 IETF , Jan. 1999. 405 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 406 Sastry, A., "COPS Usage for RSVP", IETF , Feb. 1999. 409 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 410 Functional Specification.", IETF RFC 2205, Proposed Standard, 411 Sep. 1997. 413 [MD5] Baker, F., Lindell B., Talwar, M. "RSVP Cryptographic 414 Authentication" Internet-Draft, , 415 Nov. 1998. 417 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 418 Writing an IANA Considerations Section in RFCs", RFC 2434, 419 October 1998. 421 7 Acknowledgments 423 This document incorporates inputs from Lou Berger, Bob Braden, 424 Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, 425 Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many 426 others. 428 8 Author Information 430 Shai Herzog, IPHighway 431 Parker Plaza, Suite 1500 432 400 Kelby St. 433 Fort-Lee, NJ 07024 434 (201) 585-0800 435 herzog@iphighway.com 437 Internet Draft RSVP Extensions for Policy Control 2-Apr-99 439 Appendix A: Policy Error Codes 441 This Appendix extends the list of error codes described in Appendix 442 B of [RSVP]. 444 Note that Policy Element specific errors are reported as described 445 in Section 3.3 and cannot be reported through RSVP (using this 446 mechanism). However, this mechanism provides a simple, less secure 447 mechanism for reporting generic policy errors. Most likely the two 448 would be used in concert such that a generic error code is provided 449 by RSVP, while Policy Element specific errors are encapsulated in a 450 return POLICY_DATA object (as in Section 3.3). 452 ERROR_SPEC class = 6 454 Error Code = 02: Policy Control failure 456 Error Value: 16 bit 458 0 = ERR_INFO : Information reporting 459 1 = ERR_WARN : Warning 460 2 = ERR_UNKNOWN : Reason unknown 461 3 = ERR_REJECT : Generic Policy Rejection 462 4 = ERR_EXCEED : Quota or Accounting violation 463 5 = ERR_PREEMPT : Flow was preempted 464 6 = ERR_EXPIRED : Previously installed policy expired (not 465 refreshed) 466 7 = ERR_REPLACED: Previous policy data was replaced & caused 467 rejection 468 8 = ERR_MERGE : Policies could not be merged (multicast) 469 9 = ERR_PDP : PDP down or non functioning 470 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 471 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 472 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 473 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 474 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD 475 object) 476 15= ERR_NO_RSC : PEP Out of resources to handle policies. 477 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 478 17= ERR_SERVICE : Service type was rejected 479 18= ERR_STYLE : Reservation Style was rejected 480 19= ERR_FL_SPEC : FlowSpec was rejected (too large) 482 Values between 2^15 and 2^16-1 can be used for site and/or vendor 483 error values.