RFC 2750

RSVP Extensions for Policy Control

📅 published January 2000, from ietf

RSVP Extensions for Policy Control 💖

Okay bestie, here's the vibe check 🎀 This is RFC 2750, written by S. Herzog of IPHighway. It's a Standards Track doc, dated January 2000, and it updates RFC 2205 (the RSVP functional spec). It doesn't list anything it obsoletes. 🦋

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. 👑

Abstract 🧚

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. 💜 It should be seen as an extension to the RSVP functional specifications [RSVP].

These extensions include the standard format of POLICY_DATA objects, and a description of how RSVP handles policy events. 🍓

This document does not push any particular policy control mechanisms. 🙈 A Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].

Table of Contents 📖

1 Introduction.......................................................2
2 A Simple Scenario..................................................3
3 Policy Data Objects................................................3
3.1  Base Format.....................................................4
3.2  Options.........................................................4
3.3  Policy Elements.................................................7
3.4  Purging Policy State............................................7
4 Processing Rules...................................................8
4.1  Basic Signaling.................................................8
4.2  Default Handling for PIN nodes..................................8
4.3  Error Signaling.................................................9
5 IANA Considerations................................................9
6 Security Considerations............................................9
7 References........................................................10
8 Acknowledgments...................................................10
9 Author Information................................................10
Appendix A: Policy Error Codes......................................11
Appendix B: INTEGRITY computation for POLICY_DATA objects...........12
Full Copyright Statement ...........................................13

1. Introduction 🎀

Okay so RSVP, by definition, picks favourites between users 👑 by giving some users better service at everyone else's expense. ngl that means it's reasonable to expect RSVP to come with mechanisms for controlling and enforcing access and usage policies. 💅 Version 1 of the RSVP Functional Specifications [RSVP] left a placeholder for policy support in the form of the POLICY_DATA object. 🦋

The current RSVP Functional Specification describes the interface to admission (traffic) control that is based "only" on resource availability. 🙄 In this document we describe a set of extensions to RSVP that add policy based admission control too. ✨ The scope here is limited to these extensions, and the document doesn't push specific architectures for policy based controls. 💖

For the purpose of this document, we don't differentiate between Policy Decision Point (PDP) and Local Decision Point (LDPs) as described in [RAP]. 🫶 The term PDP should be assumed to include LDP as well. 💜

2. A Simple Scenario 🌈

It's generally assumed that policy enforcement (at least in its early stages) is likely to focus on border nodes between autonomous systems. 🧚

Figure 1 shows a simple autonomous domain with two boundary nodes (A, C), which are PEPs controlled by PDPs. 🔥 A core node (B) is an RSVP capable policy ignorant node (PIN), with capabilities limited to default policy handling (Section 4.2). 🎀

                 PDP1                        PDP2
                  |                           |
                  |                           |
                +---+         +---+         +---+
                | A +---------+ B +---------+ C |
                +---+         +---+         +---+
                 PEP2          PIN           PEP2

               Figure 1: Autonomous Domain scenario

So here, policy objects sent across the domain pass through an intermediate PIN node (B). 😭 That node is allowed to process RSVP messages, but it's considered non-trusted for handling policy information. 🙈

This document describes processing rules for both PEP and PIN nodes. 🍓

3. Policy Data Objects 🌸

POLICY_DATA objects are carried by RSVP messages and contain policy information. ✨ All policy-capable nodes (at any location in the network) can generate, modify, or remove policy objects, even when senders or receivers don't provide them, and may not even be aware that policy data objects exist. 💅

The exchange of POLICY_DATA objects between policy-capable nodes along the data path supports the generation of consistent end-to-end policies. 🫶 Policies can also be deployed successfully across multiple administrative domains, as long as border nodes manipulate and translate POLICY_DATA objects according to established sets of bilateral agreements. 👑

The following extends section A.13 in [RSVP].

3.1 Base Format 🦋

POLICY_DATA class=14
  • Type 1 POLICY_DATA object: Class=14, C-Type=1
     +-------------+-------------+-------------+-------------+
     |  Length                   | POLICY_DATA |      1      |
     +---------------------------+-------------+-------------+
     |  Data Offset              | 0 (reserved)              |
     +---------------------------+-------------+-------------+
     |                                                       |
     // Option List                                         //
     |                                                       |
     +-------------------------------------------------------+
     |                                                       |
     // Policy Element List                                 //
     |                                                       |
     +-------------------------------------------------------+
  • Data Offset: 16 bits. This is the offset in bytes of the data portion, counted from the first byte of the object header. 🧚
  • Reserved: 16 bits. Always 0. 🙈
  • Option List: Variable length. The list of options and how they're used is defined in Section 3.2. 💖
  • Policy Element List: Variable length. The contents of policy elements are opaque to RSVP. Check Section 3.3 for more details. 🔥

That's the base format, bestie. ✨

3.2 Options ✨

okay bestie, this is the menu of options that can show up inside POLICY_DATA objects 💅 every policy option is still an RSVP object, but its meaning gets tweaked once it's being used as policy data 🎀 the vibe shift is real

FILTER_SPEC object (list) or SCOPE object

these objects describe the set of senders associated with the POLICY_DATA object 🦋 if neither one is provided, the policy info is assumed to be associated with all the flows of the session. these two types are mutually exclusive and can't be mixed 🙅

in Packed FF Resv messages, this FILTER_SPEC option is what links a reserved flow to its POLICY_DATA objects 🔗

in WF or SE styles, this option preserves the original flow/POLICY_DATA association that PDPs formed, even across RSVP capable PINs 🫶 that preservation is required because PIN nodes may change the list of reserved flows on a per-hop basis, irrespective of legit Edge-to-Edge PDP policy considerations 💀

last, the SCOPE object should be used to prevent "policy loops" in a way similar to what's described in [RSVP], Section 3.4 ✨ when PIN nodes are part of a WF reservation path, the RSVP SCOPE object can't prevent policy loops, so the separate policy SCOPE object is required

Note: using the SCOPE option may have significant impact on scaling and size of POLICY_DATA objects.

Originating RSVP_HOP

the RSVP_HOP object identifies the neighbor/peer policy-capable node that constructed the policy object 👑 when policy is enforced at border nodes, peer policy nodes may be several RSVP hops away from each other, and the originating RSVP_HOP is the basis for the mechanism that lets them recognize each other and communicate safely and directly 🌸

if no RSVP_HOP object is present, the policy data is implicitly assumed to have been constructed by the RSVP_HOP indicated in the RSVP message itself (i.e., the neighboring RSVP node is policy-capable).

Destination RSVP_HOP

a second RSVP_HOP object may follow the originating RSVP_HOP object. this second one identifies the destination policy node 🎯 it's used to make sure the POLICY_DATA object gets delivered to targeted policy nodes. it may be used to emulate unicast delivery in multicast Path messages. it may also help prevent using a policy object in other parts of the network (replay attack) 🙈

on the receiving side, a policy node should ignore any POLICY_DATA that includes a destination RSVP_HOP that doesn't match its own IP address.

INTEGRITY Object

Figure 1 (Section 2) gives an example where POLICY_DATA objects get transmitted between boundary nodes while traversing non-secure PIN nodes 😬 in this scenario, the RSVP integrity mechanism becomes ineffective, since it places policy trust with intermediate PIN nodes (which are trusted to perform RSVP signaling but not to perform policy decisions or manipulations).

the INTEGRITY object option inside a POLICY_DATA object creates direct secure communications between non-neighboring PEPs (and their controlling PDPs) without involving PIN nodes 🔐

this option can be used at the discretion of PDPs, and is computed in a manner described in Appendix B.

Policy Refresh TIME_VALUES (PRT)

the Policy Refresh TIME_VALUES (PRT) option is used to slow policy refresh frequency for policies that have looser timing constraints relative to RSVP 🐢 if the PRT option is present, policy refreshes can be withheld as long as at least one refresh is sent before the policy refresh timer expires. a minimal value for PRT is R; lower values are assumed to be R (neither error nor warning should be triggered).

to simplify RSVP processing, time values aren't based directly on the PRT value, but on a Policy Refresh Multiplier N computed as N=Floor(PRT/R). refresh and cleanup rules are derived from [RSVP] Section 3.7, assuming the refresh period for PRT POLICY DATA is R' computed as R'=N*R. in effect, both the refresh and the state cleanup are slowed by a factor of N).

the refresh multiplier applies to no-change periodic refreshes only (rather than updates). for example, a policy being refreshed at time T, T+N, T+2N,... may encounter a route change detected at T+X. in this case, the event would force an immediate policy update and would reset srfresh times to T+X+N, T+X+2N,...

when network nodes restart, RSVP messages between PRT policy refreshes may be rejected, since they arrive without the necessary POLICY_DATA objects 😵 this error situation would clear with the next periodic policy refresh or with a policy update triggered by ResvErr or PathErr messages.

this option is especially useful for combining strong (high overhead) and weak (low overhead) authentication certificates as policy data 💜 in such schemes, the weak certificate can support admitting a reservation only for a limited time, after which the strong certificate is required.

this approach may reduce the overhead of POLICY_DATA processing. strong certificates could be transmitted less frequently, while weak certificates are included in every RSVP refresh. main character efficiency 🌈

3.3 Policy Elements

the content of policy elements is opaque to RSVP 🙃 their internal format is understood by policy peers, e.g. an RSVP Local Decision Point (LDP) or a Policy Decision Point (PDP) [RAP]. a registry of policy element codepoints and their meaning is maintained by [IANA-CONSIDERATIONS] (also see Section 5).

policy Elements have the following format:

+-------------+-------------+-------------+-------------+
|  Length                   |   P-Type                  |
+---------------------------+---------------------------+
|                                                       |
// Policy information  (Opaque to RSVP)                //
|                                                       |
+-------------------------------------------------------+

3.4 Purging Policy State

policy state expires in the granularity of Policy Elements (POLICY_DATA objects are mere containers and do not expire as such) 📦

policy elements expire in the exact manner and time as the RSVP state received in the same message (see [RSVP] Section 3.7). PRT controlled state expires N times slower (see Section 3.2). ⏳

only one policy element of a certain P-Type can be active at any given time. therefore, policy elements are instantaneously replaced when another policy element of the same P-Type is received from the same PDP (previous or next policy RSVP_HOP). an empty policy element of a certain P-Type is used to delete (rather than replace) all policy state of the same P-Type. 🗑️

4 Processing Rules ✨

these sections describe the minimal required policy processing rules for RSVP.

4.1 Basic Signaling

this memo mandates enforcing policy control for Path, Resv, PathErr, and ResvErr messages only. PathTear and ResvTear are assumed not to require policy control, based on two main presumptions. first, that Integrity verification [MD5] guarantee that the Tear is received from the same node that sent the installed reservation, and second, that it is functionally equivalent to that node holding off refreshes for this reservation. 🧐

4.2 Default Handling for PIN nodes

Figure 1 illustrates an example of where policy data objects traverse PIN nodes in transit from one PEP to another 🗺️

a PIN node is required, at a minimum, to forward the received POLICY_DATA objects in the appropriate outgoing messages according to the following rules:

  • POLICY_DATA objects are to be forwarded as is, without any modifications.
  • Multicast merging (splitting) nodes:
    • In the upstream direction:
      • when multiple POLICY_DATA objects arrive from downstream, the RSVP node should concatenate all of them (as a list of the original POLICY_DATA objects) and forward them with the outgoing (upstream) message.
    • On the downstream direction:
      • when a single incoming POLICY_DATA object arrives from upstream, it should be forwarded (copied) to all downstream branches of the multicast tree.

the same rules apply to unrecognized policies (sub-objects) within the POLICY_DATA object. however, since this can only occur in a policy-capable node, it is the responsibility of the PDP and not RSVP 🫡

4.3 Error Signaling

policy errors are reported by either ResvErr or PathErr messages with a policy failure error code in the ERROR_SPEC object 🚨 a policy error message must include a POLICY_DATA object; the object contains details of the error type and reason in a P-Type specific format (See Section 3.3).

if a multicast reservation fails due to policy reasons, RSVP should not attempt to discover which reservation caused the failure (as it would do for Blockade State). instead, it should attempt to deliver the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) decide where messages should be sent. this mechanism lets the PDP limit the error distribution by deciding which "culprit" next-hops should be informed. it also lets the PDP prevent further distribution of ResvErr or PathErr messages by performing local repair (e.g. substituting the failed POLICY_DATA object with a different one) 🛠️

error codes are described in Appendix Appendix A.

5 IANA Considerations

RSVP Policy Elements (P-Types)

following the policies outlined in [IANA-CONSIDERATIONS], numbers 0-49151 are allocated as standard policy elements by IETF Consensus action, numbers in the range 49152-53247 are allocated as vendor specific (one per vendor) by First Come First Serve, and numbers 53248-65535 are reserved for private use and are not assigned by IANA. 🔢

6 Security Considerations

Security alert, bestie: this is the part where things get serious 🚨

this memo describes the use of POLICY_DATA objects to carry policy-related information between RSVP nodes. two security mechanisms can be optionally used to ensure the integrity of the carried information. the first mechanism relies on RSVP integrity [MD5] to provide a chain of trust when all RSVP nodes are policy capable. the second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between non-neighboring RSVP PEPs (see Sections 2 and 3.2). 🔐

7 References

  • [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
  • [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
  • [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
  • [RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
  • [MD5] Baker, F., Lindell B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
  • [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8. Acknowledgments 🎀

okay so this document was helped along by a crew of legends: Lou Berger, Bob Braden, Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and honestly so many others 🫶✨

9. Author Information 💅

the author is Shai Herzog 🌸

IPHighway, Inc. 55 New York Avenue Framingham, MA 01701

Phone: (508) 620-1141 EMail: herzog@iphighway.com

Appendix A: Policy Error Codes 🔥

this appendix extends the list of error codes from Appendix B of [RSVP] 💖

ngl, policy element specific errors can't be reported through RSVP using this mechanism. they get reported the way Section 4.3 describes, and that's that 🙈 but this mechanism gives you a simple, less secure way to report generic policy errors. honestly the two are meant to be used together: a generic error code comes through RSVP, and the policy element specific errors get wrapped up inside a return POLICY_DATA object (like in Section 4.3) 🧚

here's the ERROR_SPEC bit:

ERROR_SPEC class = 6

Error Code = 02: Policy Control failure

Error Value: 16 bit

0 = ERR_INFO    : Information reporting
1 = ERR_WARN    : Warning
2 = ERR_UNKNOWN : Reason unknown
3 = ERR_REJECT  : Generic Policy Rejection
4 = ERR_EXCEED  : Quota or Accounting violation
5 = ERR_PREEMPT : Flow was preempted
6 = ERR_EXPIRED : Previously installed policy expired (not
refreshed)
7 = ERR_REPLACED: Previous policy data was replaced & caused
rejection
8 = ERR_MERGE   : Policies could not be merged (multicast)
9 = ERR_PDP     : PDP down or non functioning
10= ERR_SERVER  : Third Party Server (e.g., Kerberos) unavailable
11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax
12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check
13= ERR_PE_BAD  : POLICY_ELEMENT object has bad syntax
14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD
object)
15= ERR_NO_RSC  : PEP Out of resources to handle policies.
16= ERR_RSVP    : PDP encountered bad RSVP objects or syntax
17= ERR_SERVICE : Service type was rejected
18= ERR_STYLE   : Reservation Style was rejected
19= ERR_FL_SPEC : FlowSpec was rejected (too large)

values between 2^15 and 2^16-1 can be used for site and/or vendor error values 🌈

Appendix B: INTEGRITY computation for POLICY_DATA objects 🦋

so the INTEGRITY option gets computed based on the rules in [MD5], with a few tweaks 💜

Section 4.1:

instead of computing a digest for an RSVP message, you compute a digest for a POLICY_DATA object like this:

  1. the INTEGRITY object gets inserted in the right spot in the POLICY_DATA object, and you remember where it lives in the message for later 📌
  2. the PDP, at its discretion (based on the destination PEP/PDP or other criteria), picks an Authentication Key and the hash algorithm to use 🔑
  3. a copy of the RSVP SESSION object gets temporarily tacked onto the end of the PD object (just for the computation, without changing the length of the POLICY_DATA object). the flags field of the SESSION object is set to 0. this combined thing is what the digest gets computed over 🧮
  4. the rest of the steps in Section 4.1 ((4)..(9)) stay unchanged when computed over that concatenated message ✨
note: once the computation is done, the SESSION object gets ignored and isn't part of the POLICY_DATA object 🙈

Other Provisions:

receiving a POLICY_DATA object, plus a challenge-response INTEGRITY object inside one, gets processed the way [MD5] describes. this processing uses the modified computation algorithm from the start of this appendix (for Section 4.1 of [MD5]) 💅

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸

this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💖

this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Acknowledgement

funding for the RFC Editor function is currently provided by the Internet Society 🎀✨

📦 where this page comes from