idnits 2.17.1 draft-ietf-rap-new-rsvp-ext-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 an Authors' Addresses 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 180: '...is time. This field MUST be set to 0....' RFC 2119 keyword, line 210: '... other but not both MAY be included in...' RFC 2119 keyword, line 232: '... not both MAY be included in the Opt...' RFC 2119 keyword, line 234: '...The SCOPE option SHOULD be used to pre...' RFC 2119 keyword, line 272: '... RSVP_HOP option MAY be included in th...' (3 more instances...) -- The draft header indicates that this document updates RFC2750, but the abstract doesn't seem to directly say this. It does mention RFC2750 though, so this could be OK. -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) -- 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 (June 2001) is 8341 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) ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Possible downref: Normative reference to a draft: ref. 'POLICY-MD5' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP') Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAP Working Group R. Hess, Ed. 3 Internet Draft Intel 4 Updates: 2205, 2750 S. Herzog 5 Expires December 2001 IPHighway 6 June 2001 8 RSVP Extensions for Policy Control 10 draft-ietf-rap-new-rsvp-ext-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. Internet-Drafts are working documents of 16 the Internet Engineering Task Force (IETF), its areas, and its 17 working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 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 The distribution of this memo is unlimited. This memo is filed as 32 , and expires December 31, 2001. 33 Please send comments to the author. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This memo presents a set of extensions for supporting generic policy 42 based admission control in RSVP. It should be perceived as an 43 extension to the RSVP functional specifications [RSVP]. 45 These extensions include the standard format of POLICY_DATA objects, 46 and a description of RSVP's handling of policy events. 48 This document does not advocate particular policy control mechanisms; 49 however, a Router/Server Policy Protocol description for these 50 extensions can be found in [RAP, COPS, COPS-RSVP]. 52 This memo address a security hole in RFC 2750 whereby POLICY_DATA 53 objects are vulnerable to replay attacks. 55 Table of Contents 57 1. Introduction.................................................... 2 58 2. A Simple Scenario............................................... 3 59 3. Policy Data Objects............................................. 3 60 3.1. Base Format................................................... 4 61 3.2. Options....................................................... 4 62 3.2.1. FILTER_SPEC (List).......................................... 5 63 3.2.2. SCOPE....................................................... 5 64 3.2.3. Originating RSVP_HOP........................................ 5 65 3.2.4. Destination RSVP_HOP........................................ 6 66 3.2.5. INTEGRITY................................................... 6 67 3.2.6. Policy Refresh TIME_VALUES (PRT)............................ 6 68 3.3. Policy Elements............................................... 7 69 3.4. Purging Policy State.......................................... 8 70 4. Processing Rules................................................ 8 71 4.1. Basic Signaling............................................... 8 72 4.2. Default Handling for PIN Nodes................................ 8 73 4.3. Error Signaling............................................... 9 74 5. IANA Considerations............................................. 9 75 6. Security Considerations......................................... 9 76 7. References......................................................10 77 8. Acknowledgements................................................11 78 9. Author Information..............................................11 79 Appendix A: Policy Error Codes.....................................12 80 Full Copyright Statement ..........................................13 82 1. Introduction 84 RSVP, by definition, discriminates between users, by providing some 85 users with better service at the expense of others. Therefore, it is 86 reasonable to expect that RSVP be accompanied by mechanisms for 87 controlling and enforcing access and usage policies. Version 1 of 88 the RSVP functional specification [RSVP] left a placeholder for 89 policy support in the form of a POLICY_DATA object. 91 The current RSVP functional specification [RSVP] describes an 92 interface to admission (traffic) control that is based "only" on 93 resource availability. In this document we describe a set of 94 extensions to RSVP for supporting policy based admission control as 95 well. The scope of this document is limited to these extensions and 96 does not advocate specific architectures for policy based controls. 98 For the purpose of this document we do not differentiate between 99 Policy Decision Point (PDP) and Local Decision Point (LDP) as 100 described in [RAP]. The term PDP should be assumed to include LDP as 101 well. 103 2. A Simple Scenario 105 It is generally assumed that policy enforcement (at least in its 106 initial stages) is likely to concentrate on border nodes between 107 autonomous systems. 109 Figure 1 illustrates a simple autonomous domain with two boundary 110 nodes (A, C) which represent Policy Enforcement Points (PEPs) 111 controlled by PDPs. A core node (B) represents an RSVP capable, 112 policy ignorant node (PIN) with capabilities limited to default 113 policy handling. 115 PDP1 PDP2 116 | | 117 | | 118 +---+ +---+ +---+ 119 | A +---------+ B +---------+ C | 120 +---+ +---+ +---+ 121 PEP2 PIN PEP2 123 Figure 1: Autonomous Domain scenario 125 Here, policy objects transmitted across the domain traverse an 126 intermediate PIN node (B) that is allowed to process RSVP messages 127 but is considered non-trusted for handling policy information. 129 This document describes processing rules for both PEP and PIN nodes. 131 3. Policy Data Objects 133 POLICY_DATA objects are carried in RSVP messages and contain policy 134 information. All policy-capable RSVP nodes at any location in the 135 network can generate, modify, or remove policy objects, even when the 136 senders or the receivers do not provide, and may not even be aware of 137 policy data objects. 139 The exchange of POLICY_DATA objects between policy-capable nodes 140 along the data path, supports the generation of consistent end-to-end 141 policies. Furthermore, such policies can be successfully deployed 142 across multiple administrative domains when border nodes manipulate 143 and translate POLICY_DATA objects according to established sets of 144 bilateral agreements. 146 The following extends section A.13 in [RSVP]. 148 3.1. Base Format 150 POLICY_DATA class = 14 152 o Type 1 POLICY_DATA object: Class = 14, C-Type = 1 154 +-------------+-------------+-------------+-------------+ 155 | Length | POLICY_DATA | 1 | 156 +-------------+-------------+-------------+-------------+ 157 | Data Offset | 0 (Reserved) | 158 +-------------+-------------+-------------+-------------+ 159 | | 160 // Option List // 161 | | 162 +-------------+-------------+-------------+-------------+ 163 | | 164 // Policy Element List // 165 | | 166 +-------------+-------------+-------------+-------------+ 168 Length: 16 bits 170 The total length of the POLICY_DATA object in bytes. Must 171 always be a multiple of 4. 173 Data Offset: 16 bits 175 The offset in bytes of the Policy Element List from the first 176 byte of the object header. 178 Reserved: 16 bits 180 Unused at this time. This field MUST be set to 0. 182 Option List: Variable length 184 The list of options and their usage are defined in Section 185 3.2. 187 Policy Element List: Variable length 189 The contents of policy elements are opaque to RSVP. Further 190 details are provided in Section 3.3. 192 3.2. Options 194 This section describes the set of options that may appear in the 195 Option List field of a POLICY_DATA object. All policy options 196 described in this document are RSVP objects (defined in [RSVP, MD5]), 197 but when used as a policy option, their semantics have been modified 198 as described below. 200 3.2.1. FILTER_SPEC (List) 202 The FILTER_SPEC option is defined to be identical to RSVP's 203 FILTER_SPEC object as defined in [RSVP], Section A.9, with the 204 following semantic changes. 206 This option describes the set of senders associated with the 207 POLICY_DATA object. If none is provided and if the SCOPE option is 208 also absent, the policy information is assumed to be associated with 209 all the flows of the RSVP session. This option is mutually exclusive 210 of the SCOPE option; one or the other but not both MAY be included in 211 the Option List of a POLICY_DATA object. 213 In Packed FF Resv messages, the FILTER_SPEC option provides 214 association between a reserved flow and its POLICY_DATA objects. 216 In WF or SE styles, this option preserves the original 217 flow/POLICY_DATA association as formed by PDPs, even across policy 218 ignorant RSVP nodes. Such preservation is required since PINs may 219 change the list of reserved flows on a per-hop basis, irrespective of 220 legitimate edge-to-edge PDP policy considerations. 222 3.2.2. SCOPE 224 The SCOPE option is defined to be identical to RSVP's SCOPE object as 225 defined in [RSVP], Section A.6, with the following semantic changes. 227 This option also describes the set of senders associated with the 228 POLICY_DATA object. If none is provided and if the FILTER_SPEC 229 option is also absent, the policy information is assumed to be 230 associated with all the flows of the RSVP session. This option is 231 mutually exclusive of the FILTER_SPEC option; one or the other but 232 not both MAY be included in the Option List of a POLICY_DATA object. 234 The SCOPE option SHOULD be used to prevent "policy loops" in a manner 235 similar to the one described in [RSVP], Section 3.4. When PIN nodes 236 are part of a WF reservation path, the RSVP SCOPE object found in the 237 RSVP message is insufficient to prevent policy loops; hence, a 238 separate policy SCOPE option is required. 240 Note: Use the SCOPE option may have significant impact on the scaling 241 and the size of POLICY_DATA objects. 243 3.2.3. Originating RSVP_HOP 245 The Originating RSVP_HOP option is defined to be identical to RSVP's 246 RSVP_HOP object as defined in [RSVP], Section A.2, with the following 247 semantic changes. 249 This option identifies the neighbor/peer policy aware RSVP node that 250 constructed the POLICY_DATA object. When policy is enforced at 251 border nodes, peer policy nodes may be several RSVP hops away from 252 each other. The Originating RSVP_HOP provides the basis for a 253 mechanism that allows policy aware RSVP nodes to communicate directly 254 with each other. 256 If no Originating RSVP_HOP option is present, the policy data is 257 implicitly assumed to have been constructed by the RSVP_HOP indicated 258 in the RSVP message itself and that, furthermore, the said node is 259 policy-capable. 261 3.2.4. Destination RSVP_HOP 263 The Destination RSVP_HOP option is defined to be identical to RSVP's 264 RSVP_HOP object as defined in [RSVP], Section A.2, with the following 265 semantic changes. 267 This option identifies the destination policy node. This is used to 268 ensure that the POLICY_DATA object is delivered to the targeted 269 policy node. It may be used to emulate unicast delivery in multicast 270 Path messages. 272 The Destination RSVP_HOP option MAY be included in the Option List 273 of a POLICY_DATA object. When it is included, it MUST follow the 274 Originating RSVP_HOP option. If no Originating RSVP_HOP option is 275 present, then the Destination RSVP_HOP option MUST NOT be included. 277 A policy node SHOULD ignore any POLICY_DATA objects it receives that 278 include a Destination RSVP_HOP that doesn't match its own IP address. 280 3.2.5. INTEGRITY 282 Figure 1 (Section 2) provides an example where POLICY_DATA objects 283 are transmitted between boundary nodes while traversing non-secure 284 PIN nodes. In this scenario, the RSVP integrity mechanism becomes 285 ineffective since it places policy trust with intermediate PIN nodes 286 (which are trusted to perform RSVP signaling but not to perform 287 policy decisions or manipulations). 289 The INTEGRITY option inside a POLICY_DATA object creates direct and 290 secure communications between non-neighboring PEPs (and their 291 controlling PDPs) without involving PIN nodes. 293 This option can be used at the discretion of PDPs. Its use is 294 described in [POLICY-MD5]. 296 3.2.6. Policy Refresh TIME_VALUES (PRT) 298 The Policy Refresh TIME_VALUES (PRT) option is defined to be 299 identical to RSVP's TIME_VALUES object as defined in [RSVP], Section 300 A.4., with the following semantic changes. 302 The PRT option is used to slow the policy refresh frequency for 303 policies that have looser timing constraints relative to RSVP. If 304 the PRT option is present, policy refreshes can be withheld provided 305 a minimum of one refresh is sent before the policy refresh timer 306 expires. 308 The minimum value for PRT is R, R defined as the value found in the 309 TIME_VALUES object of a RSVP message. Lower values for PRT are 310 assumed to be R (neither error nor warning should be triggered). 312 To simplify RSVP processing, time values are not based directly on 313 the PRT value, but on a Policy Refresh Multiplier N computed as 314 N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP], 315 Section 3.7, assuming the refresh period for PRT POLICY_DATA is R' 316 computed as R'=N*R. The net effect is that the refresh and the state 317 cleanup are slowed by a factor of N. 319 The Policy Refresh Multiplier applies to no-change periodic refreshes 320 only, not to updates. For example, a policy being refreshed at time 321 T, T+N, T+2N, ... may encounter a route change detected at T+X. In 322 this case, the event would force an immediate policy update and would 323 reset refresh times to T+X+N, T+X+2N, ... 325 When network nodes restart, RSVP messages between PRT policy 326 refreshes may be rejected since they arrive without the necessary 327 POLICY_DATA objects. This error situation would clear with the next 328 periodic policy refresh or with a policy update triggered by ResvErr 329 or PathErr messages. 331 This option is especially useful when combining strong (high 332 overhead) and weak (low overhead) authentication certificates as 333 policy data. In such schemes the weak certificate can support 334 admitting a reservation only for a limited time, after which the 335 strong certificate is required. This approach may reduce the 336 overhead of POLICY_DATA processing. Strong certificates could be 337 transmitted less frequently, while weak certificates are included in 338 every RSVP refresh. 340 3.3. Policy Elements 342 The content of policy elements is opaque to RSVP; their internal 343 format is understood by policy peers e.g. a RSVP Local Decision 344 Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of 345 policy element codepoints and their meaning is maintained by [IANA- 346 CONSIDERATIONS] (also see Section 5). 348 Policy Elements have the following format: 350 +-------------+-------------+-------------+-------------+ 351 | Length | P-Type | 352 +-------------+-------------+-------------+-------------+ 353 | | 354 // Policy information (Opaque to RSVP) // 355 | | 356 +-------------+-------------+-------------+-------------+ 358 3.4. Purging Policy State 360 Policy state expires in the granularity of Policy Elements 361 (POLICY_DATA objects are mere containers and do not expire as such). 363 Policy elements expire in the exact manner and time as the RSVP state 364 received in the same message (see [RSVP] Section 3.7). PRT 365 controlled state expires N times slower (see Section 3.2). 367 Only one policy element of a certain P-Type can be active at any 368 given time. Therefore, policy elements are instantaneously replaced 369 when another policy element of the same P-Type is received from the 370 same PDP (previous or next policy RSVP_HOP). An empty policy element 371 of a certain P-Type is used to delete (rather than replace) all 372 policy state of the same P-Type. 374 4. Processing Rules 376 These sections describe the minimal required policy processing rules 377 for RSVP. 379 4.1. Basic Signaling 381 This memo mandates enforcing policy control for Path, Resv, PathErr, 382 and ResvErr messages only. PathTear and ResvTear are assumed not to 383 require policy control based on two main presumptions. First, that 384 Integrity verification [MD5] guarantees that the Tear is received 385 from the same node that sent the installed reservation, and second, 386 that it is functionally equivalent to that node holding off on 387 refreshes for this reservation. 389 4.2. Default Handling for PIN Nodes 391 Figure 1 illustrates an example of where policy data objects traverse 392 PIN nodes in transit from one PEP to another. 394 A PIN node is required at a minimum to forward the received 395 POLICY_DATA objects in the appropriate outgoing messages according to 396 the following rules: 398 o POLICY_DATA objects are to be forwarded as is, without any 399 modifications. 401 o Multicast merging (splitting) nodes: 403 In the upstream direction: 405 When multiple POLICY_DATA objects arrive from downstream, the 406 RSVP node should concatenate all of them (as a list of the 407 original POLICY_DATA objects) and forward them with the 408 outgoing (upstream) message. 410 On the downstream direction: 412 When a single incoming POLICY_DATA object arrives from 413 upstream, it should be forwarded (copied) to all downstream 414 branches of the multicast tree. 416 The same rules apply to unrecognized policies (sub-objects) within 417 the POLICY_DATA object. However, since this can only occur in a 418 policy-capable node, it is the responsibility of the PDP and not of 419 RSVP. 421 4.3. Error Signaling 423 Policy errors are reported by either ResvErr or PathErr messages with 424 a policy failure error code in the ERROR_SPEC object. A Policy error 425 message must include a POLICY_DATA object; the object contains 426 details of the error type and reason in a P-Type specific format (See 427 Section 3.3). 429 If a multicast reservation fails due to policy reasons, RSVP should 430 not attempt to discover which reservation caused the failure (as it 431 would do for Blockade State). Instead, it should attempt to deliver 432 the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) 433 decide where messages should be sent. This mechanism allows the PDP 434 to limit the error distribution by deciding which of the "culprit" 435 next-hops should be informed. It also allows the PDP to prevent 436 further distribution of ResvErr or PathErr messages by performing 437 local repair (e.g. substituting the failed POLICY_DATA object with a 438 different one). 440 Error codes are described in Appendix A. 442 5. IANA Considerations 444 RSVP Policy Elements (P-Types) 446 Following the policies outlined in [IANA-CONSIDERATIONS], numbers 447 0-49151 are allocated as standard policy elements by IETF Consensus 448 action, numbers in the range 49152-53247 are allocated as vendor 449 specific (one per vendor) by First Come First Serve, and numbers 450 53248-65535 are reserved for private use and are not assigned by 451 IANA. 453 6. Security Considerations 455 This memo raises the following security issues. 457 o POLICY_DATA integrity and node authentication 459 Corrupted or spoofed POLICY_DATA objects could lead to theft of 460 service by unauthorized parties or to denial of service caused 461 by locking up network resources. RSVP protects against such 462 attacks with a PEP peer to PEP peer authentication mechanism 463 using an encrypted hash function. The mechanism is supported by 464 INTEGRITY options that may appear in any POLICY_DATA object. 465 These options use a keyed cryptographic digest technique, which 466 assumes that PEP peers share a secret. Although this mechanism 467 is part of the base POLICY_DATA specification, it is described 468 in a companion document [POLICY-MD5]. 470 Widespread use of the POLICY_DATA integrity mechanism will 471 require the availability of the long-sought key management and 472 distribution infrastructure for routers. Until that 473 infrastructure becomes available, manual key management will 474 be required to secure POLICY_DATA integrity. 476 o User authentication 478 Policy control will depend upon positive authentication of 479 the user and/or application responsible for each reservation 480 request. Policy data may therefore include cryptographically 481 protected user certificates. This is described in a companion 482 document [IDENTITY-REP]. 484 Protection against the aforementioned attacks is provided by 485 establishing a chain of trust, using the PEP peer to PEP peer 486 INTEGRITY option described earlier. 488 7. References 490 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., 491 Raja, R. and Sastry, A., "The COPS (Common Open 492 Policy Service) Protocol", RFC 2748, January 493 2000. 495 [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., 496 Raja, R. and Sastry, A., "COPS Usage for RSVP", 497 RFC 2749, January 2000. 499 [IANA-CONSIDERATIONS] Alvestrand, H. and Narten, T., "Guidelines for 500 Writing an IANA Considerations Section in 501 RFCs", BCP 26, RFC 2434, October 1998. 503 [IDENTITY-REP] Hess, R., Ed., Yadav, S., Yavatkar, R., 504 Pabbati, R., Ford, P., Moore, T., Herzog, S., 505 "Identity Representation for RSVP", work in 506 progress, 507 draft-ietf-rap-rsvp-newidentity-02.txt, May 508 2001. 510 [MD5] Baker, F., Lindell, B. and Talwar, M., "RSVP 511 Cryptographic Authentication", RFC 2747, 512 January 2000. 514 [POLICY-MD5] Hess, R., "Cryptographic Authentication for 515 RSVP POLICY_DATA Objects", work in progress, 516 draft-ietf-rap-auth-policy-data-00.txt, 517 June 2001. 519 [RAP] Yavatkar, R., Pendarakis, D. and Guerin, R., "A 520 Framework for Policy Based Admission Control", 521 RFC 2753, January 2000. 523 [RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, 524 S. and Jamin, S., "Resource ReSerVation 525 Protocol (RSVP) - Functional Specification", 526 RFC 2205, September 1997. 528 8. Acknowledgements 530 This document incorporates inputs from Lou Berger, Bob Braden, 531 Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, 532 Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many 533 others. 535 9. Authors' Information 537 Rodney Hess 538 Intel Corp, BD1 539 28 Crosby Dr 540 Bedford, MA 01730 542 EMail: rodney.hess@intel.com 544 Shai Herzog 545 IPHighway, Inc. 546 55 New York Avenue 547 Framingham, MA 01701 549 Phone: (508) 620-1141 550 EMail: herzog@iphighway.com 552 Appendix A: Policy Error Codes 554 This Appendix extends the list of error codes described in Appendix B 555 of [RSVP]. 557 Note that Policy Element specific errors are reported as described in 558 Section 4.3 and cannot be reported through RSVP (using this 559 mechanism). However, this mechanism provides a simple, less secure 560 mechanism for reporting generic policy errors. Most likely the two 561 would be used in concert such that a generic error code is provided 562 by RSVP, while Policy Element specific errors are encapsulated in a 563 return POLICY_DATA object (as in Section 4.3). 565 ERROR_SPEC class = 6 567 Error Code = 02: Policy Control failure 569 Error Value: 16 bit 571 0 = ERR_INFO : Information reporting 572 1 = ERR_WARN : Warning 573 2 = ERR_UNKNOWN : Reason unknown 574 3 = ERR_REJECT : Generic Policy Rejection 575 4 = ERR_EXCEED : Quota or Accounting violation 576 5 = ERR_PREEMPT : Flow was preempted 577 6 = ERR_EXPIRED : Previously installed policy expired (not 578 refreshed) 579 7 = ERR_REPLACED: Previous policy data was replaced & caused 580 rejection 581 8 = ERR_MERGE : Policies could not be merged (multicast) 582 9 = ERR_PDP : PDP down or non functioning 583 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 584 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 585 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 586 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 587 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD 588 object) 589 15= ERR_NO_RSC : PEP Out of resources to handle policies. 590 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 591 17= ERR_SERVICE : Service type was rejected 592 18= ERR_STYLE : Reservation Style was rejected 593 19= ERR_FL_SPEC : FlowSpec was rejected (too large) 595 Values between 2^15 and 2^16-1 can be used for site and/or vendor 596 error values. 598 Full Copyright Statement 600 Copyright (C) The Internet Society (2001). All Rights Reserved. 602 This document and translations of it may be copied and furnished to 603 others, and derivative works that comment on or otherwise explain it 604 or assist in its implementation may be prepared, copied, published 605 and distributed, in whole or in part, without restriction of any 606 kind, provided that the above copyright notice and this paragraph are 607 included on all such copies and derivative works. However, this 608 document itself may not be modified in any way, such as by removing 609 the copyright notice or references to the Internet Society or other 610 Internet organizations, except as needed for the purpose of 611 developing Internet standards in which case the procedures for 612 copyrights defined in the Internet Standards process must be 613 followed, or as required to translate it into languages other than 614 English. 616 The limited permissions granted above are perpetual and will not be 617 revoked by the Internet Society or its successors or assigns. 619 This document and the information contained herein is provided on an 620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Acknowledgement 628 Funding for the RFC Editor function is currently provided by the 629 Internet Society.