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