Internet Draft                                              Shai Herzog
Expiration: Apr. July 1999                                           IPHighway
File: draft-ietf-rap-rsvp-ext-01.txt draft-ietf-rap-rsvp-ext-02.txt

                    RSVP Extensions for Policy Control

                          November 18, 1998

                          January 22, 1999

Status of this Memo

  This document is an Internet Draft.  Internet Drafts are working
  documents of the Internet Engineering Task Force (IETF), its Areas, and
  its Working Groups.  Note that other groups may also distribute working
  documents as Internet Drafts.

  Internet Drafts are draft documents valid for a maximum of six months.
  Internet Drafts may be updated, replaced, or obsoleted by other
  documents at any time.  It is not appropriate to use Internet Drafts as
  reference material or to cite them other than as a "working draft" or
  "work in progress".

  To learn the current status of any Internet-Draft, please check the
  1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
  munnari.oz.au.

  A revised version of this draft document will be submitted to the RFC
  editor as a Proposed Standard for the Internet Community.  Discussion
  and suggestions for improvement are requested.  This document will
  expire at the expiration date listed above. Distribution of this draft
  is unlimited.

Abstract

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

  These extensions include the standard format of POLICY_DATA objects,
  and a description of RSVP's handling of policy events.

  This document does not advocate particular policy control mechanisms;
  however, a Router/Server Policy Protocol description for these
  extensions can be found in [Fwk, [RAP, COPS, COPS-RSVP].

Table of Contents

Abstract...............................................................1
Table of Contents......................................................2
1. Introduction........................................................3
2. Policy Data Object Format...........................................3
2.1. Base Format.......................................................4
2.2. Options...........................................................4
2.2.1.Native RSVP Options..............................................5
2.2.2.Other Options....................................................6
2.3. Policy Elements...................................................6 Elements...................................................7
3. Processing Rules....................................................7
3.1. Basic Signaling...................................................7
3.2. Error Signaling...................................................7
3.3. Default Handling..................................................7
3.3. Error Signaling...................................................8
4. References..........................................................9 IANA Considerations.................................................8
5. Acknowledgments.....................................................9 References..........................................................9
6. Acknowledgments.....................................................9
7. Author Information..................................................9
A. Appendix: Policy Error Codes.......................................10

1. Introduction

  RSVP, by definition, discriminates between users, by providing some
  users with better service at the expense of others. Therefore, it is
  reasonable to expect that RSVP be accompanied by mechanisms for
  controlling and enforcing access and usage policies.  Historically,
  when RSVP Ver. 1 was developed, the knowledge and understanding of
  policy issues was in its infancy. As a result, Ver. 1 of the RSVP
  Functional Specifications [RSVPSP] [RSVP] left a place holder for policy support
  in the form of POLICY_DATA objects. However, it deliberately refrained
  from specifying mechanisms, message formats, or providing insight into
  how policy enforcement should be carried out. This document is intended
  to fill in this void.

  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
  for supporting policy based admission control as well. The scope of
  this document is limited to these extensions and does not advocate
  specific architectures for policy based controls.

  For the purpose of this document we define Local do not differentiate between Policy Module (LPM) as
  the policy entity within the RSVP node. This may be fully contained
  within the RSVP node or may be using an outsourcing mechanism such
  Decision Point (PDP) and Local Decision Point (LDPs) as described in [Fwk, COPS, COPS-RSVP].
  [RAP]. The term PDP should be assumed to include LDP as well.

2. Policy Data Object Format

  The following replaces section A.13 in [RSVPSP]. [RSVP].

  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 do not provide, and may not even be aware of policy data
  objects.

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

2.1. Base Format

  POLICY_DATA class=14

  o   Type 1 POLICY_DATA object: Class=14, C-Type=1

      +-------------+-------------+-------------+-------------+
      |  Length                   | POLICY_DATA |      1      |
      +---------------------------+-------------+-------------+
      |  Data Offset              | Flags       | 0 (reserved)| (reserved)              |
      +---------------------------+-------------+-------------+
      |                                                       |
      // Option List                                         //
      |                                                       |
      +-------------------------------------------------------+
      |                                                       |
      // Policy Element List                                 //
      |                                                       |
      +-------------------------------------------------------+

      Data Offset: 16 bits

          The offset in bytes of the data portion (from the first
          byte of the object header).

      Flags: 8 bits

          0x01  PCF_Updt
                A modified object, don't check against previous one. This
                is an optimization for systems that attempt to detect
                unchanged refreshes of POLICY_DATA objects

      Reserved: 8 16 bits

           Always 0.

      Option List: Variable length

          The list of options and their usage is defined in Section 2.2.

      Policy Element List: Variable length

          The contents of policy elements is opaque to RSVP. See more
          details in Section 2.3.

2.2. Options

  This section describes a set of options that may appear as options in POLICY_DATA
  objects. All policy options appear as RSVP objects; some use their
  valid original format while others appear as NULL objects.

2.2.1. Native RSVP Options

  The following objects retain the same format specified in [RSVPSP] [RSVP]
  however, they gain different semantics when used inside POLICY_DATA
  objects.

  FILTER_SPEC object (list) or SCOPE object

  The set of senders associated with the POLICY_DATA object. If none is
  provided, the policy information is assumed to be associated with all
  the flows of the session. These two types of objects are mutually
  exclusive, and cannot be mixed.

  This option is only useful for WF or SE reservation styles, where
  merged reservations may have originally been intended for different
  subsets of senders. It can also be used to prevent “policy loops” in a
  manner similar to the usage of RSVP’s SCOPE object. Using this option
  may have significant impact on scaling and size of POLICY_DATA objects
  and therefore should be taken with care.

  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 allows
  them to 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 RSVP_HOP identifies the destination policy node. This is
  used to ensure the POLICY_DATA object is 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 POLCY_DATA that
  includes a destination RSVP_HOP that doesn’t match its own IP address.

  INTEGRITY Object

  The INTEGRITY object provides guarantees that the object was not
  compromised. It follows the rules from [MD5], and is calculated over
  the POLICY_DATA object, the SESSION object, and the message type field
  (byte, padded with zero to 32 bit) as if they formed one continuous in-
  order message.  This concatenation is designed to prevent copy and
  replay attacks of POLICY_DATA objects from other sessions, flows,
  message types or even other network locations.

2.2.2. Other Options

  All options that do not use a valid RSVP object format, should use the
  NULL RSVP object format with different CType values. This document
  defines only one such option, however, several other may be considered
  in future versions.  (e.g., Fragmentation, NoChange, etc.).

  o    Policy Refresh Multiplier

  Some Period (PRP)

  The Policy Refresh Period (PRP) option is used slow down policy refresh
  frequency for policies may that have looser timing constraints than RSVP, and
  therefore may allow for lower refresh frequency. compared
  with RSVP. If the Policy Refresh
  Multiplier PRP option is present, policy refreshes can be
  withheld as long as at least one refresh is refreshed only once in
  "Multiplier" RSVP refreshes, for "Duplicates" times. sent before the policy
  refresh timer expires (PRP must be bigger than R).

  +-------------+-------------+-------------+-------------+
  |             8             |    NULL     |     1       |
  +-------------+-------------+-------------+-------------+
  |        Multiplier         |       Duplicates         Policy Refresh Period (PRP) (in seconds)      |
  +-------------+-------------+---------------------------+

  For example, for "Multiplier=16" and "Duplicates=3",

  It is recommended that this infrequent policy refresh would be
  piggybacked with normal RSVP refreshes. Given an RSVP refresh R, the
  policy should must be refreshed on RSVP's refreshes number 1,2,3,16,17,18,...

  Note: this option’s natural recovery time may be as long at least once in N RSVP refreshes, where
  N=Floor(PRP/R) and the Floor function provides the integer portion of
  the result.

  In effect, state cleanup rules apply specifically to the POLICY_DATA
  object as Multiplier
  times if the RSVP refresh period. Hence, it should only be used in
  conjunction with longer-term policies or topologies period was N*R.

  Any RSVP update must include the full policy information. For example,
  a policy being refreshed at time T, T+N, T+2N,... may encounter a route
  change detected at T+X such that can tolerate
  longer recovery time.

2.3. Policy Elements T < T+X < T+N. The contents update event would
  force an immediate update of the policy elements is opaque to RSVP and change its internal
  format refresh times to
  T+X, T+X+N, T+X+2N,...

  When network nodes restart, it is only known possible that an RSVP message in
  between policy refreshes would be rejected since it arrives to a node
  that did not receive the Local Policy Module (LPM). A list original POLICY_DATA object.  This error
  situation would clear with the next periodic policy refresh or by an
  update triggered by ResvErr or PathErr messages.

  This option is especially useful to combine strong (high overhead) and
  weak (low overhead) authentication certificates. In such schemes the
  weak certificate supports 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 could be included in every RSVP refresh.

2.3. Policy Elements

  The content of policy elements code points (based on P-type) starting from 0, is registered
  with IANA. Local, Proprietary, and temporary P-Types can be used from
  the high end and down (2^16-1 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 down). their meaning is maintained by [IANA-CONSIDERATIONS]
  (also see Section 4).

  Policy Elements have the following format:

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

3. Processing Rules

  This

  These sections describes describe the minimal required policy processing rules
  for RSVP.

3.1. Basic Signaling

  It is generally agreed that policy control should only be enforced for
  Path, Resv, PathErr, and ResvErr. PathTear and ResvTear and assumed not
  to require policy control based on two assumptions: First, that MD-5
  authentication verifies
  Integrity verification [MD5] guarantee that the Tear is received from
  the same node that sent the initial installed reservation, and second, that it
  is functionally equivalent to that node holding-off refreshes for this
  reservation.

3.2. Error Signaling

  Policy errors are reported by either ResvErr or PathErr messages with a
  policy failure error code (specified in [RSVPSP]). 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.

  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 LPM decide where
  messages should be sent. This mechanism allows the LPM to limit the
  error distribution by deciding which "culprit" next-hops should be
  informed. It also allows the LPM to prevent further distribution of
  ResvErr or PathErr messages by performing local repair (e.g.
  substituting the failed POLICY_DATA object with a different one).

3.3. Default Handling

  It is generally assumed that policy enforcement (at least in its
  initial stages) is likely to concentrate on border nodes between
  autonomous systems. Consequently, policy objects transmitted at one
  edge of an autonomous cloud may traverse intermediate non-policy-
  capable RSVP nodes.  The minimal requirement from a non-policy-capable policy ignorant
  RSVP node nodes (PINs). A PIN is required at a minimum to forward the
  received POLICY_DATA objects embedded in the appropriate outgoing messages
  according to the following rules:

  o    POLICY_DATA objects are to be forwarded as is, without any
       modifications.

  o    Multicast merging (splitting) nodes:

       In the upstream direction:

          When multiple POLICY_DATA objects arrive from downstream, the
          RSVP node should concatenate all of them 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 LPM PDP and not RSVP.

4. References

  [Fwk]   R. Yavatkar, D. Pendarakis, R. Guerin.  "A Framework for

3.3. Error Signaling

  Policy
          Based errors are reported by either ResvErr or PathErr messages with a
  policy failure error code in the ERROR_SPEC object. 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.

  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 allows the PDP to limit
  the error distribution by deciding which "culprit" next-hops should be
  informed. It also allows the PDP to 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 A.

4. IANA Considerations

  RSVP Policy Elements

  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.

5. References

  [RAP]  Yavatkar, R., et al., "A Framework for Policy Based Admission Control", Internet-Draft <draft-ietf-rap-
          framework-00.txt>, November, 1997.
         Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.

  [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., Sastry,
         A., "The COPS (Common Open Policy Service) Protocol",
          Internet-Draft <draft-ietf-rap-cops-02.txt>, Aug. 1998.

  [RSVPSP] IETF
         <draft-ietf-rap-cops-05.txt>, Jan. 1999.

  [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., R. ed., "Resource Reservation ReSerVation Protocol (RSVP) Version 1 -
         Functional
          Specification", Specification.", IETF RFC 2205, Proposed Standard, September
         Sep. 1997.

  [MD5]  F. Baker.  Baker, F., Linden B., Talwar, M. “RSVP Cryptographic
         Authentication" Internet-Draft,
          <draft-ietf-rsvp-md5-05.txt>, Aug. 1997.

5. <draft-ietf-rsvp-md5-07.txt>,
         Nov. 1998.

  [IANA-CONSIDERATIONS]  Alvestrand, H. and T. Narten, "Guidelines for
         Writing an IANA Considerations Section in RFCs", RFC 2434,
         October 1998.

6. Acknowledgments

  This document incorporates inputs from Lou Berger, Bob Braden, Deborah
  Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju
  Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar Yavatkar, and many others.

6.

7. Author Information

  Shai Herzog, IPHighway
  Parker Plaza, Suite 1500
  400 Kelby St.
  Fort-Lee, NJ 07024
  (201) 585-0800
  herzog@iphighway.com

A. Appendix: Policy Error Codes

  This Appendix expends the list of error codes described in Appendix B
  of [RSVP].

  Note that Policy Element specific errors are reported as described in
  Section 3.3 and cannot be reported through RSVP (using this mechanism).
  However, this mechanism provides a simple, less secure mechanism for
  reporting generic policy errors. Most likely the two would be used in
  concert such that a generic error code is provided by RSVP, while
  Policy Element specific errors are encapsulated in a return POLICY_DATA
  object (as in Section 3.3).

  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.