rfc2750.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

Network Working Group                                           S. Herzog
Request for Comments: 2750                                      IPHighway
Updates: 2205                                                January 2000
Category: Standards Track


                   RSVP Extensions for Policy Control

Status of this Memo

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

Copyright Notice

   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 perceived as an
   extension to the RSVP functional specifications [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 [RAP, COPS, COPS-RSVP].



















Herzog                      Standards Track                     [Page 1]

RFC 2750           RSVP Extensions for Policy Control       January 2000


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

   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. Version 1 of the
   RSVP Functional Specifications [RSVP] left a placeholder for policy
   support in the form of 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 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 do not 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.









Herzog                      Standards Track                     [Page 2]

RFC 2750           RSVP Extensions for Policy Control       January 2000


2  A Simple Scenario

   It is generally assumed that policy enforcement (at least in its
   initial stages) is likely to concentrate on border nodes between
   autonomous systems.

   Figure 1 illustrates a simple autonomous domain with two boundary
   nodes (A, C) which represent PEPs controlled by PDPs. A core node (B)
   represents 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

   Here, policy objects transmitted across the domain traverse an
   intermediate PIN node (B) that is allowed to process RSVP message but
   considered non-trusted for handling policy information.

   This document describes processing rules for both PEP as well as 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 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.

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






Herzog                      Standards Track                     [Page 3]

RFC 2750           RSVP Extensions for Policy Control       January 2000


3.1 Base Format

   POLICY_DATA class=14

   o   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

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

       Reserved: 16 bits

            Always 0.

       Option List: Variable length

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

   Policy Element List: Variable length

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

3.2 Options

   This section describes a set of options that may appear in
   POLICY_DATA objects. All policy options appear as RSVP objects but
   their semantic is modified when used as policy data options.







Herzog                      Standards Track                     [Page 4]

RFC 2750           RSVP Extensions for Policy Control       January 2000


   FILTER_SPEC object (list) or SCOPE object

   These objects describe 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.

   In Packed FF Resv messages, this FILTER_SPEC option provides
   association between a reserved flow and its POLICY_DATA objects.

   In WF or SE styles, this option preserves the original
   flow/POLICY_DATA association as formed by PDPs, even across RSVP
   capable PINs. Such preservation is required since PIN nodes may
   change the list of reserved flows on a per-hop basis, irrespective of
   legitimate Edge-to-Edge PDP policy considerations.

   Last, the SCOPE object should be used to prevent "policy loops" in a
   manner similar to the one described in [RSVP], Section 3.4. When PIN
   nodes are part of a WF reservation path, the RSVP SCOPE object is
   unable to prevent policy loops and 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 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).




Herzog                      Standards Track                     [Page 5]

RFC 2750           RSVP Extensions for Policy Control       January 2000


   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) provides an example where POLICY_DATA objects
   are 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 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 are not 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 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.




Herzog                      Standards Track                     [Page 6]

RFC 2750           RSVP Extensions for Policy Control       January 2000


   This option is especially useful to combine 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.

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                  |
   +---------------------------+---------------------------+
   |                                                       |