idnits 2.17.1 draft-ietf-rap-rsvp-ext-04.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 (February 26, 1999) is 9162 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: 'COPS-RSVP' is mentioned on line 44, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' -- 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 (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: August 1999 IPHighway 4 File: draft-ietf-rap-rsvp-ext-04.txt 5 Updates RFC 2205 7 RSVP Extensions for Policy Control 9 February 26, 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 26-Feb-99 48 Table of Contents 50 Abstract.............................................................1 51 Table of Contents....................................................2 52 1 Introduction.......................................................3 53 2 Policy Data Object Format..........................................3 54 2.1 Base Format.....................................................4 55 2.2 Options.........................................................4 56 2.3 Native RSVP Options.............................................5 57 2.4 Other Options...................................................6 58 2.5 Policy Elements.................................................7 59 3 Processing Rules...................................................7 60 3.1 Basic Signaling.................................................7 61 3.2 Default Handling................................................7 62 3.3 Error Signaling.................................................8 63 4 IANA Considerations................................................9 64 5 Security Considerations............................................9 65 6 References........................................................10 66 7 Acknowledgments...................................................10 67 8 Author Information................................................10 68 A. Appendix: Policy Error Codes.....................................11 69 Internet Draft RSVP Extensions for Policy Control 26-Feb-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. Historically, 77 when RSVP Ver. 1 was developed, the knowledge and understanding of 78 policy issues was in its infancy. As a result, Ver. 1 of the RSVP 79 Functional Specifications [RSVP] left a place holder for policy 80 support in the form of POLICY_DATA objects. However, it deliberately 81 refrained from specifying mechanisms, message formats, or providing 82 insight into how policy enforcement should be carried out. This 83 document is intended to fill in this void. 85 The current RSVP Functional Specification describes the interface to 86 admission (traffic) control that is based "only" on resource 87 availability. In this document we describe a set of extensions to 88 RSVP for supporting policy based admission control as well. The 89 scope of this document is limited to these extensions and does not 90 advocate specific architectures for policy based controls. 92 For the purpose of this document we do not differentiate between 93 Policy Decision Point (PDP) and Local Decision Point (LDPs) as 94 described in [RAP]. The term PDP should be assumed to include LDP as 95 well. 97 2 Policy Data Object Format 99 The following replaces section A.13 in [RSVP]. 101 POLICY_DATA objects are carried by RSVP messages and contain policy 102 information. All policy-capable nodes (at any location in the 103 network) can generate, modify, or remove policy objects, even when 104 senders or receivers do not provide, and may not even be aware of 105 policy data objects. 107 The exchange of POLICY_DATA objects between policy-capable nodes 108 along the data path, supports the generation of consistent end-to- 109 end policies. Furthermore, such policies can be successfully 110 deployed across multiple administrative domains when border nodes 111 manipulate and translate POLICY_DATA objects according to 112 established sets of bilateral agreements. 114 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 116 2.1 Base Format 118 POLICY_DATA class=14 120 o Type 1 POLICY_DATA object: Class=14, C-Type=1 122 +-------------+-------------+-------------+-------------+ 123 | Length | POLICY_DATA | 1 | 124 +---------------------------+-------------+-------------+ 125 | Data Offset | 0 (reserved) | 126 +---------------------------+-------------+-------------+ 127 | | 128 // Option List // 129 | | 130 +-------------------------------------------------------+ 131 | | 132 // Policy Element List // 133 | | 134 +-------------------------------------------------------+ 136 Data Offset: 16 bits 138 The offset in bytes of the data portion (from the first 139 byte of the object header). 141 Reserved: 16 bits 143 Always 0. 145 Option List: Variable length 147 The list of options and their usage is defined in Section 148 2.2. 150 Policy Element List: Variable length 152 The contents of policy elements is opaque to RSVP. See more 153 details in Section 2.5. 155 2.2 Options 157 This section describes a set of options that may appear in 158 POLICY_DATA objects. All policy options appear as RSVP objects; some 159 use their valid original format while others appear as NULL objects. 161 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 163 2.3 Native RSVP Options 165 The following objects retain the same format specified in [RSVP] 166 however, they gain different semantics when used inside POLICY_DATA 167 objects. 169 FILTER_SPEC object (list) or SCOPE object 171 The set of senders associated with the POLICY_DATA object. If none 172 is provided, the policy information is assumed to be associated with 173 all the flows of the session. These two types of objects are 174 mutually exclusive, and cannot be mixed. 176 This option is only useful for WF or SE reservation styles, where 177 merged reservations may have originally been intended for different 178 subsets of senders. It can also be used to prevent "policy loops" in 179 a manner similar to the usage of RSVP's SCOPE object. Using this 180 option may have significant impact on scaling and size of 181 POLICY_DATA objects and therefore should be taken with care. 183 Originating RSVP_HOP 185 The RSVP_HOP object identifies the neighbor/peer policy-capable node 186 that constructed the policy object. When policy is enforced at 187 border nodes, peer policy nodes may be several RSVP hops away from 188 each other and the originating RSVP_HOP is the basis for the 189 mechanism that allows them to recognize each other and communicate 190 safely and directly. 192 If no RSVP_HOP object is present, the policy data is implicitly 193 assumed to have been constructed by the RSVP_HOP indicated in the 194 RSVP message itself (i.e., the neighboring RSVP node is policy- 195 capable). 197 Destination RSVP_HOP 199 A second RSVP_HOP object may follow the originating RSVP_HOP object. 200 This second RSVP_HOP identifies the destination policy node. This is 201 used to ensure the POLICY_DATA object is delivered to targeted 202 policy nodes. It may be used to emulate unicast delivery in 203 multicast Path messages. It may also help prevent using a policy 204 object in other parts of the network (replay attack). 206 On the receiving side, a policy node should ignore any POLCY_DATA 207 that includes a destination RSVP_HOP that doesn't match its own IP 208 address. 210 INTEGRITY Object 212 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 214 The INTEGRITY object provides guarantees that the object was not 215 compromised. It follows the rules from [MD5], and is calculated over 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 2.4 Other Options 224 All options that do not use a valid RSVP object format, should use 225 the NULL RSVP object format with different C-Type values. This 226 document defines only one such option, however, several other may be 227 considered in future versions. (e.g., Fragmentation, NoChange, 228 etc.). 230 o Policy Refresh Period (PRP) 232 The Policy Refresh Period (PRP) option is used slow down policy 233 refresh frequency for policies that have looser timing constraints 234 compared with RSVP. If the PRP option is present, policy refreshes 235 can be withheld as long as at least one refresh is sent before the 236 policy refresh timer expires (PRP must be bigger than R). 238 +-------------+-------------+-------------+-------------+ 239 | 8 | NULL | 1 | 240 +-------------+-------------+-------------+-------------+ 241 | Policy Refresh Period (PRP) (in seconds) | 242 +-------------+-------------+---------------------------+ 244 It is recommended that this infrequent policy refresh would be 245 piggybacked with normal RSVP refreshes. Given an RSVP refresh R, the 246 policy must be refreshed at least once in N RSVP refreshes, where 247 N=Floor(PRP/R) and the Floor function provides the integer portion 248 of the result. 250 In effect, state cleanup rules apply specifically to the POLICY_DATA 251 object as if the RSVP refresh period was N*R. 253 Any RSVP update must include the full policy information. For 254 example, a policy being refreshed at time T, T+N, T+2N,... may 255 encounter a route change detected at T+X such that T < T+X < T+N. 256 The update event would force an immediate update of the policy and 257 change its refresh times to T+X, T+X+N, T+X+2N,... 259 When network nodes restart, it is possible that an RSVP message in 260 between policy refreshes would be rejected since it arrives to a 261 node that did not receive the original POLICY_DATA object. This 262 error situation would clear with the next periodic policy refresh or 263 by an update triggered by ResvErr or PathErr messages. 265 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 267 This option is especially useful to combine strong (high overhead) 268 and weak (low overhead) authentication certificates. In such schemes 269 the weak certificate supports admitting a reservation only for a 270 limited time, after which the strong certificate is required. 272 This approach may reduce the overhead of POLICY_DATA processing. 273 Strong certificates could be transmitted less frequently, while weak 274 certificates could be included in every RSVP refresh. 276 2.5 Policy Elements 278 The content of policy elements is opaque to RSVP; their internal 279 format is understood by policy peers e.g. an RSVP Local Decision 280 Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of 281 policy element codepoints and their meaning is maintained by [IANA- 282 CONSIDERATIONS] (also see Section 4). 284 Policy Elements have the following format: 286 +-------------+-------------+-------------+-------------+ 287 | Length | P-Type | 288 +---------------------------+---------------------------+ 289 | | 290 // Policy information (Opaque to RSVP) // 291 | | 292 +-------------------------------------------------------+ 294 3 Processing Rules 296 These sections describe the minimal required policy processing rules 297 for RSVP. 299 3.1 Basic Signaling 301 It is generally agreed that policy control should only be enforced 302 for Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and 303 assumed not to require policy control based on two assumptions: 304 First, that Integrity verification [MD5] guarantee that the Tear is 305 received from the same node that sent the installed reservation, and 306 second, that it is functionally equivalent to that node holding-off 307 refreshes for this reservation. 309 3.2 Default Handling 311 It is generally assumed that policy enforcement (at least in its 312 initial stages) is likely to concentrate on border nodes between 313 autonomous systems. Consequently, policy objects transmitted at one 314 edge of an autonomous cloud may traverse intermediate policy 315 ignorant RSVP nodes (PINs). A PIN is required at a minimum to 316 forward the received POLICY_DATA objects in the appropriate outgoing 317 messages according to the following rules: 319 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 321 o POLICY_DATA objects are to be forwarded as is, without any 322 modifications. 324 o Multicast merging (splitting) nodes: 326 In the upstream direction: 328 When multiple POLICY_DATA objects arrive from downstream, the 329 RSVP node should concatenate all of them and forward them 330 with the outgoing (upstream) message. 332 On the downstream direction: 334 When a single incoming POLICY_DATA object arrives from 335 upstream, it should be forwarded (copied) to all downstream 336 branches of the multicast tree. 338 The same rules apply to unrecognized policies (sub-objects) within 339 the POLICY_DATA object. However, since this can only occur in a 340 policy-capable node, it is the responsibility of the PDP and not 341 RSVP. 343 3.3 Error Signaling 345 Policy errors are reported by either ResvErr or PathErr messages 346 with a policy failure error code in the ERROR_SPEC object. Policy 347 error message must include a POLICY_DATA object; the object contains 348 details of the error type and reason in a P-Type specific format. 350 If a multicast reservation fails due to policy reasons, RSVP should 351 not attempt to discover which reservation caused the failure (as it 352 would do for Blockade State). Instead, it should attempt to deliver 353 the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) 354 decide where messages should be sent. This mechanism allows the PDP 355 to limit the error distribution by deciding which "culprit" next- 356 hops should be informed. It also allows the PDP to prevent further 357 distribution of ResvErr or PathErr messages by performing local 358 repair (e.g. substituting the failed POLICY_DATA object with a 359 different one). 361 Error codes are described in Appendix A. 363 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 365 4 IANA Considerations 367 RSVP Policy Elements 369 Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- 370 49151 are allocated as standard policy elements by IETF Consensus 371 action, numbers in the range 49152-53247 are allocated as vendor 372 specific (one per vendor) by First Come First Serve, and numbers 373 53248-65535 are reserved for private use and are not assigned by 374 IANA. 376 5 Security Considerations 378 This draft describes the use of POLICY_DATA objects to carry policy- 379 related information between RSVP nodes. Two security mechanisms can 380 be optionally used to ensure the integrity of the carried 381 information. The first mechanism relies on RSVP integrity [MD5] to 382 provide a chain of trust when all RSVP nodes are policy capable. The 383 second mechanism relies on the INTEGRITY object within the 384 POLICY_DATA object to guarantee integrity between non-neighboring 385 RSVP PEPs. (See Section 2.3). 387 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 389 6 References 391 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 392 Control",IETF , Jan., 1999. 394 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 395 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 396 IETF , Jan. 1999. 398 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 399 Functional Specification.", IETF RFC 2205, Proposed Standard, 400 Sep. 1997. 402 [MD5] Baker, F., Linden B., Talwar, M. "RSVP Cryptographic 403 Authentication" Internet-Draft, , 404 Nov. 1998. 406 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 407 Writing an IANA Considerations Section in RFCs", RFC 2434, 408 October 1998. 410 7 Acknowledgments 412 This document incorporates inputs from Lou Berger, Bob Braden, 413 Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, 414 Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many 415 others. 417 8 Author Information 419 Shai Herzog, IPHighway 420 Parker Plaza, Suite 1500 421 400 Kelby St. 422 Fort-Lee, NJ 07024 423 (201) 585-0800 424 herzog@iphighway.com 426 Internet Draft RSVP Extensions for Policy Control 26-Feb-99 428 A. Appendix: Policy Error Codes 430 This Appendix expends the list of error codes described in Appendix 431 B of [RSVP]. 433 Note that Policy Element specific errors are reported as described 434 in Section 3.3 and cannot be reported through RSVP (using this 435 mechanism). However, this mechanism provides a simple, less secure 436 mechanism for reporting generic policy errors. Most likely the two 437 would be used in concert such that a generic error code is provided 438 by RSVP, while Policy Element specific errors are encapsulated in a 439 return POLICY_DATA object (as in Section 3.3). 441 ERROR_SPEC class = 6 443 Error Code = 02: Policy Control failure 445 Error Value: 16 bit 447 0 = ERR_INFO : Information reporting 448 1 = ERR_WARN : Warning 449 2 = ERR_UNKNOWN : Reason unknown 450 3 = ERR_REJECT : Generic Policy Rejection 451 4 = ERR_EXCEED : Quota or Accounting violation 452 5 = ERR_PREEMPT : Flow was preempted 453 6 = ERR_EXPIRED : Previously installed policy expired (not 454 refreshed) 455 7 = ERR_REPLACED: Previous policy data was replaced & caused 456 rejection 457 8 = ERR_MERGE : Policies could not be merged (multicast) 458 9 = ERR_PDP : PDP down or non functioning 459 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 460 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 461 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 462 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 463 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD 464 object) 465 15= ERR_NO_RSC : PEP Out of resources to handle policies. 466 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 467 17= ERR_SERVICE : Service type was rejected 468 18= ERR_STYLE : Reservation Style was rejected 469 19= ERR_FL_SPEC : FlowSpec was rejected (too large) 471 Values between 2^15 and 2^16-1 can be used for site and/or vendor 472 error values.