idnits 2.17.1 draft-ietf-rap-rsvp-ext-02.txt: -(168): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(169): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(195): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 61 lines 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. ** There are 27 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (January 22, 1999) is 9226 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 45, 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: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: July 1999 IPHighway 4 File: draft-ietf-rap-rsvp-ext-02.txt 6 RSVP Extensions for Policy Control 8 January 22, 1999 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet Drafts as 20 reference material or to cite them other than as a "working draft" or 21 "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 A revised version of this draft document will be submitted to the RFC 29 editor as a Proposed Standard for the Internet Community. Discussion 30 and suggestions for improvement are requested. This document will 31 expire at the expiration date listed above. Distribution of this draft 32 is unlimited. 34 Abstract 36 This memo presents a set of extensions for supporting generic policy 37 based admission control in RSVP. It should be perceived as an extension 38 to the RSVP functional specifications [RSVP] 40 These extensions include the standard format of POLICY_DATA objects, 41 and a description of RSVP's handling of policy events. 43 This document does not advocate particular policy control mechanisms; 44 however, a Router/Server Policy Protocol description for these 45 extensions can be found in [RAP, COPS, COPS-RSVP]. 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.2.1.Native RSVP Options..............................................5 56 2.2.2.Other Options....................................................6 57 2.3. 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.................................................8 63 5. References..........................................................9 64 6. Acknowledgments.....................................................9 65 7. Author Information..................................................9 66 A. Appendix: Policy Error Codes.......................................10 67 1. Introduction 69 RSVP, by definition, discriminates between users, by providing some 70 users with better service at the expense of others. Therefore, it is 71 reasonable to expect that RSVP be accompanied by mechanisms for 72 controlling and enforcing access and usage policies. Historically, 73 when RSVP Ver. 1 was developed, the knowledge and understanding of 74 policy issues was in its infancy. As a result, Ver. 1 of the RSVP 75 Functional Specifications [RSVP] left a place holder for policy support 76 in the form of POLICY_DATA objects. However, it deliberately refrained 77 from specifying mechanisms, message formats, or providing insight into 78 how policy enforcement should be carried out. This document is intended 79 to fill in this void. 81 The current RSVP Functional Specification describes the interface to 82 admission (traffic) control that is based "only" on resource 83 availability. In this document we describe a set of extensions to RSVP 84 for supporting policy based admission control as well. The scope of 85 this document is limited to these extensions and does not advocate 86 specific architectures for policy based controls. 88 For the purpose of this document we do not differentiate between Policy 89 Decision Point (PDP) and Local Decision Point (LDPs) as described in 90 [RAP]. The term PDP should be assumed to include LDP as well. 92 2. Policy Data Object Format 94 The following replaces section A.13 in [RSVP]. 96 POLICY_DATA objects are carried by RSVP messages and contain policy 97 information. All policy-capable nodes (at any location in the network) 98 can generate, modify, or remove policy objects, even when senders or 99 receivers do not provide, and may not even be aware of policy data 100 objects. 102 The exchange of POLICY_DATA objects between policy-capable nodes along 103 the data path, supports the generation of consistent end-to-end 104 policies. Furthermore, such policies can be successfully deployed 105 across multiple administrative domains when border nodes manipulate and 106 translate POLICY_DATA objects according to established sets of 107 bilateral agreements. 109 2.1. Base Format 111 POLICY_DATA class=14 113 o Type 1 POLICY_DATA object: Class=14, C-Type=1 115 +-------------+-------------+-------------+-------------+ 116 | Length | POLICY_DATA | 1 | 117 +---------------------------+-------------+-------------+ 118 | Data Offset | 0 (reserved) | 119 +---------------------------+-------------+-------------+ 120 | | 121 // Option List // 122 | | 123 +-------------------------------------------------------+ 124 | | 125 // Policy Element List // 126 | | 127 +-------------------------------------------------------+ 129 Data Offset: 16 bits 131 The offset in bytes of the data portion (from the first 132 byte of the object header). 134 Reserved: 16 bits 136 Always 0. 138 Option List: Variable length 140 The list of options and their usage is defined in Section 2.2. 142 Policy Element List: Variable length 144 The contents of policy elements is opaque to RSVP. See more 145 details in Section 2.3. 147 2.2. Options 149 This section describes a set of options that may appear in POLICY_DATA 150 objects. All policy options appear as RSVP objects; some use their 151 valid original format while others appear as NULL objects. 153 2.2.1. Native RSVP Options 155 The following objects retain the same format specified in [RSVP] 156 however, they gain different semantics when used inside POLICY_DATA 157 objects. 159 FILTER_SPEC object (list) or SCOPE object 161 The set of senders associated with the POLICY_DATA object. If none is 162 provided, the policy information is assumed to be associated with all 163 the flows of the session. These two types of objects are mutually 164 exclusive, and cannot be mixed. 166 This option is only useful for WF or SE reservation styles, where 167 merged reservations may have originally been intended for different 168 subsets of senders. It can also be used to prevent �policy loops� in a 169 manner similar to the usage of RSVP�s SCOPE object. Using this option 170 may have significant impact on scaling and size of POLICY_DATA objects 171 and therefore should be taken with care. 173 Originating RSVP_HOP 175 The RSVP_HOP object identifies the neighbor/peer policy-capable node 176 that constructed the policy object. When policy is enforced at border 177 nodes, peer policy nodes may be several RSVP hops away from each other 178 and the originating RSVP_HOP is the basis for the mechanism that allows 179 them to recognize each other and communicate safely and directly. 181 If no RSVP_HOP object is present, the policy data is implicitly assumed 182 to have been constructed by the RSVP_HOP indicated in the RSVP message 183 itself (i.e., the neighboring RSVP node is policy-capable). 185 Destination RSVP_HOP 187 A second RSVP_HOP object may follow the originating RSVP_HOP object. 188 This second RSVP_HOP identifies the destination policy node. This is 189 used to ensure the POLICY_DATA object is delivered to targeted policy 190 nodes. It may be used to emulate unicast delivery in multicast Path 191 messages. It may also help prevent using a policy object in other parts 192 of the network (replay attack). 194 On the receiving side, a policy node should ignore any POLCY_DATA that 195 includes a destination RSVP_HOP that doesn�t match its own IP address. 197 INTEGRITY Object 199 The INTEGRITY object provides guarantees that the object was not 200 compromised. It follows the rules from [MD5], and is calculated over 201 the POLICY_DATA object, the SESSION object, and the message type field 202 (byte, padded with zero to 32 bit) as if they formed one continuous in- 203 order message. This concatenation is designed to prevent copy and 204 replay attacks of POLICY_DATA objects from other sessions, flows, 205 message types or even other network locations. 207 2.2.2. Other Options 209 All options that do not use a valid RSVP object format, should use the 210 NULL RSVP object format with different CType values. This document 211 defines only one such option, however, several other may be considered 212 in future versions. (e.g., Fragmentation, NoChange, etc.). 214 o Policy Refresh Period (PRP) 216 The Policy Refresh Period (PRP) option is used slow down policy refresh 217 frequency for policies that have looser timing constraints compared 218 with RSVP. If the PRP option is present, policy refreshes can be 219 withheld as long as at least one refresh is sent before the policy 220 refresh timer expires (PRP must be bigger than R). 222 +-------------+-------------+-------------+-------------+ 223 | 8 | NULL | 1 | 224 +-------------+-------------+-------------+-------------+ 225 | Policy Refresh Period (PRP) (in seconds) | 226 +-------------+-------------+---------------------------+ 228 It is recommended that this infrequent policy refresh would be 229 piggybacked with normal RSVP refreshes. Given an RSVP refresh R, the 230 policy must be refreshed at least once in N RSVP refreshes, where 231 N=Floor(PRP/R) and the Floor function provides the integer portion of 232 the result. 234 In effect, state cleanup rules apply specifically to the POLICY_DATA 235 object as if the RSVP refresh period was N*R. 237 Any RSVP update must include the full policy information. For example, 238 a policy being refreshed at time T, T+N, T+2N,... may encounter a route 239 change detected at T+X such that T < T+X < T+N. The update event would 240 force an immediate update of the policy and change its refresh times to 241 T+X, T+X+N, T+X+2N,... 243 When network nodes restart, it is possible that an RSVP message in 244 between policy refreshes would be rejected since it arrives to a node 245 that did not receive the original POLICY_DATA object. This error 246 situation would clear with the next periodic policy refresh or by an 247 update triggered by ResvErr or PathErr messages. 249 This option is especially useful to combine strong (high overhead) and 250 weak (low overhead) authentication certificates. In such schemes the 251 weak certificate supports admitting a reservation only for a limited 252 time, after which the strong certificate is required. 254 This approach may reduce the overhead of POLICY_DATA processing. Strong 255 certificates could be transmitted less frequently, while weak 256 certificates could be included in every RSVP refresh. 258 2.3. Policy Elements 260 The content of policy elements is opaque to RSVP; their internal format 261 is understood by policy peers e.g. an RSVP Local Decision Point (LDP) 262 or a Policy Decision Point (PDP) [RAP]. A registry of policy element 263 codepoints and their meaning is maintained by [IANA-CONSIDERATIONS] 264 (also see Section 4). 266 Policy Elements have the following format: 268 +-------------+-------------+-------------+-------------+ 269 | Length | P-Type | 270 +---------------------------+---------------------------+ 271 | | 272 // Policy information (Opaque to RSVP) // 273 | | 274 +-------------------------------------------------------+ 276 3. Processing Rules 278 These sections describe the minimal required policy processing rules 279 for RSVP. 281 3.1. Basic Signaling 283 It is generally agreed that policy control should only be enforced for 284 Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and assumed not 285 to require policy control based on two assumptions: First, that 286 Integrity verification [MD5] guarantee that the Tear is received from 287 the same node that sent the installed reservation, and second, that it 288 is functionally equivalent to that node holding-off refreshes for this 289 reservation. 291 3.2. Default Handling 293 It is generally assumed that policy enforcement (at least in its 294 initial stages) is likely to concentrate on border nodes between 295 autonomous systems. Consequently, policy objects transmitted at one 296 edge of an autonomous cloud may traverse intermediate policy ignorant 297 RSVP nodes (PINs). A PIN is required at a minimum to forward the 298 received POLICY_DATA objects in the appropriate outgoing messages 299 according to the following rules: 301 o POLICY_DATA objects are to be forwarded as is, without any 302 modifications. 304 o Multicast merging (splitting) nodes: 306 In the upstream direction: 308 When multiple POLICY_DATA objects arrive from downstream, the 309 RSVP node should concatenate all of them and forward them with 310 the outgoing (upstream) message. 312 On the downstream direction: 314 When a single incoming POLICY_DATA object arrives from 315 upstream, it should be forwarded (copied) to all downstream 316 branches of the multicast tree. 318 The same rules apply to unrecognized policies (sub-objects) within the 319 POLICY_DATA object. However, since this can only occur in a policy- 320 capable node, it is the responsibility of the PDP and not RSVP. 322 3.3. Error Signaling 324 Policy errors are reported by either ResvErr or PathErr messages with a 325 policy failure error code in the ERROR_SPEC object. Policy error 326 message must include a POLICY_DATA object; the object contains details 327 of the error type and reason in a P-Type specific format. 329 If a multicast reservation fails due to policy reasons, RSVP should not 330 attempt to discover which reservation caused the failure (as it would 331 do for Blockade State). Instead, it should attempt to deliver the 332 policy ResvErr to ALL downstream hops, and have the PDP (or LDP) decide 333 where messages should be sent. This mechanism allows the PDP to limit 334 the error distribution by deciding which "culprit" next-hops should be 335 informed. It also allows the PDP to prevent further distribution of 336 ResvErr or PathErr messages by performing local repair (e.g. 337 substituting the failed POLICY_DATA object with a different one). 339 Error codes are described in Appendix A. 341 4. IANA Considerations 343 RSVP Policy Elements 345 Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- 346 49151 are allocated as standard policy elements by IETF Consensus 347 action, numbers in the range 49152-53247 are allocated as vendor 348 specific (one per vendor) by First Come First Serve, and numbers 53248- 349 65535 are reserved for private use and are not assigned by IANA. 351 5. References 353 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 354 Control",IETF , Jan., 1999. 356 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., Sastry, 357 A., "The COPS (Common Open Policy Service) Protocol", IETF 358 , Jan. 1999. 360 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - 361 Functional Specification.", IETF RFC 2205, Proposed Standard, 362 Sep. 1997. 364 [MD5] Baker, F., Linden B., Talwar, M. �RSVP Cryptographic 365 Authentication" Internet-Draft, , 366 Nov. 1998. 368 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 369 Writing an IANA Considerations Section in RFCs", RFC 2434, 370 October 1998. 372 6. Acknowledgments 374 This document incorporates inputs from Lou Berger, Bob Braden, Deborah 375 Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju 376 Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many others. 378 7. Author Information 380 Shai Herzog, IPHighway 381 Parker Plaza, Suite 1500 382 400 Kelby St. 383 Fort-Lee, NJ 07024 384 (201) 585-0800 385 herzog@iphighway.com 387 A. Appendix: Policy Error Codes 389 This Appendix expends the list of error codes described in Appendix B 390 of [RSVP]. 392 Note that Policy Element specific errors are reported as described in 393 Section 3.3 and cannot be reported through RSVP (using this mechanism). 394 However, this mechanism provides a simple, less secure mechanism for 395 reporting generic policy errors. Most likely the two would be used in 396 concert such that a generic error code is provided by RSVP, while 397 Policy Element specific errors are encapsulated in a return POLICY_DATA 398 object (as in Section 3.3). 400 ERROR_SPEC class = 6 402 Error Code = 02: Policy Control failure 404 Error Value: 16 bit 406 0 = ERR_INFO : Information reporting 407 1 = ERR_WARN : Warning 408 2 = ERR_UNKNOWN : Reason unknown 409 3 = ERR_REJECT : Generic Policy Rejection 410 4 = ERR_EXCEED : Quota or Accounting violation 411 5 = ERR_PREEMPT : Flow was preempted 412 6 = ERR_EXPIRED : Previously installed policy expired (not refreshed) 413 7 = ERR_REPLACED: Previous policy data was replaced & caused rejection 414 8 = ERR_MERGE : Policies could not be merged (multicast) 415 9 = ERR_PDP : PDP down or non functioning 416 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 417 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 418 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 419 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 420 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD object) 421 15= ERR_NO_RSC : PEP Out of resources to handle policies. 422 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 423 17= ERR_SERVICE : Service type was rejected 424 18= ERR_STYLE : Reservation Style was rejected 425 19= ERR_FL_SPEC : FlowSpec was rejected (too large) 427 Values between 2^15 and 2^16-1 can be used for site and/or vendor error 428 values.