As per Relevance of the word extension, we have this rfc below:
Network Working Group S.
Request for Comments: 2750
Updates: 2205 January 2000
Category: Standards
RSVP Extensions for Policy
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo presents a set of extensions for supporting generic
based admission control in RSVP. It should be perceived as
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
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
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
RSVP, by definition, discriminates between users, by providing
users with better service at the expense of others. Therefore, it
reasonable to expect that RSVP be accompanied by mechanisms
controlling and enforcing access and usage policies. Version 1 of
RSVP Functional Specifications [RSVP] left a placeholder for
support in the form of POLICY_DATA object
The current RSVP Functional Specification describes the interface
admission (traffic) control that is based "only" on
availability. In this document we describe a set of extensions
RSVP for supporting policy based admission control as well. The
of this document is limited to these extensions and does not
specific architectures for policy based controls
For the purpose of this document we do not differentiate
Policy Decision Point (PDP) and Local Decision Point (LDPs)
described in [RAP]. The term PDP should be assumed to include LDP
well
Herzog Standards Track [Page 2]
RFC 2750 RSVP Extensions for Policy Control January 2000
2 A Simple
It is generally assumed that policy enforcement (at least in
initial stages) is likely to concentrate on border nodes
autonomous systems
Figure 1 illustrates a simple autonomous domain with two
nodes (A, C) which represent PEPs controlled by PDPs. A core node (B
represents an RSVP capable policy ignorant node (PIN)
capabilities limited to default policy handling (Section 4.2).
PDP1 PDP
| |
| |
+---+ +---+ +---+
| A +---------+ B +---------+ C |
+---+ +---+ +---+
PEP2 PIN PEP
Figure 1: Autonomous Domain
Here, policy objects transmitted across the domain traverse
intermediate PIN node (B) that is allowed to process RSVP message
considered non-trusted for handling policy information
This document describes processing rules for both PEP as well as
nodes
3 Policy Data
POLICY_DATA objects are carried by RSVP messages and contain
information. All policy-capable nodes (at any location in
network) can generate, modify, or remove policy objects, even
senders or receivers do not provide, and may not even be aware
policy data objects
The exchange of POLICY_DATA objects between policy-capable
along the data path, supports the generation of consistent end-to-
policies. Furthermore, such policies can be successfully
across multiple administrative domains when border nodes
and translate POLICY_DATA objects according to established sets
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
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
The offset in bytes of the data portion (from the
byte of the object header).
Reserved: 16
Always 0.
Option List: Variable
The list of options and their usage is defined in
3.2.
Policy Element List: Variable
The contents of policy elements is opaque to RSVP. See
details in Section 3.3.
3.2
This section describes a set of options that may appear
POLICY_DATA objects. All policy options appear as RSVP objects
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
These objects describe the set of senders associated with
POLICY_DATA object. If none is provided, the policy information
assumed to be associated with all the flows of the session. These
types of objects are mutually exclusive, and cannot be mixed
In Packed FF Resv messages, this FILTER_SPEC option
association between a reserved flow and its POLICY_DATA objects
In WF or SE styles, this option preserves the
flow/POLICY_DATA association as formed by PDPs, even across
capable PINs. Such preservation is required since PIN nodes
change the list of reserved flows on a per-hop basis, irrespective
legitimate Edge-to-Edge PDP policy considerations
Last, the SCOPE object should be used to prevent "policy loops" in
manner similar to the one described in [RSVP], Section 3.4. When
nodes are part of a WF reservation path, the RSVP SCOPE object
unable to prevent policy loops and the separate policy SCOPE
is required
Note: using the SCOPE option may have significant impact on
and size of POLICY_DATA objects
Originating RSVP_
The RSVP_HOP object identifies the neighbor/peer policy-capable
that constructed the policy object. When policy is enforced at
nodes, peer policy nodes may be several RSVP hops away from
other and the originating RSVP_HOP is the basis for the
that allows them to recognize each other and communicate safely
directly
If no RSVP_HOP object is present, the policy data is
assumed to have been constructed by the RSVP_HOP indicated in
RSVP message itself (i.e., the neighboring RSVP node is policy
capable).
Destination RSVP_
A second RSVP_HOP object may follow the originating RSVP_HOP object
This second RSVP_HOP identifies the destination policy node. This
used to ensure the POLICY_DATA object is delivered to targeted
nodes. It may be used to emulate unicast delivery in multicast
messages. It may also help prevent using a policy object in
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_
that includes a destination RSVP_HOP that doesn't match its own
address
INTEGRITY
Figure 1 (Section 2) provides an example where POLICY_DATA
are transmitted between boundary nodes while traversing non-
PIN nodes. In this scenario, the RSVP integrity mechanism
ineffective since it places policy trust with intermediate PIN
(which are trusted to perform RSVP signaling but not to
policy decisions or manipulations).
The INTEGRITY object option inside POLICY_DATA object creates
secure communications between non-neighboring PEPs (and
controlling PDPs) without involving PIN nodes
This option can be used at the discretion of PDPs, and is computed
a manner described in Appendix B
Policy Refresh TIME_VALUES (PRT
The Policy Refresh TIME_VALUES (PRT) option is used to slow
refresh frequency for policies that have looser timing
relative to RSVP. If the PRT option is present, policy refreshes
be withheld as long as at least one refresh is sent before the
refresh timer expires. A minimal value for PRT is R; lower values
assumed to be R (neither error nor warning should be triggered).
To simplify RSVP processing, time values are not based directly
the PRT value, but on a Policy Refresh Multiplier N computed
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
cleanup are slowed by a factor of N).
The refresh multiplier applies to no-change periodic refreshes
(rather than updates). For example, a policy being refreshed at
T, T+N, T+2N,... may encounter a route change detected at T+X.
this case, the event would force an immediate policy update and
reset srfresh times to T+X+N, T+X+2N,...
When network nodes restart, RSVP messages between PRT
refreshes may be rejected since they arrive without
POLICY_DATA objects. This error situation would clear with the
periodic policy refresh or with a policy update triggered by
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
reservation only for a limited time, after which the
certificate is required
This approach may reduce the overhead of POLICY_DATA processing
Strong certificates could be transmitted less frequently, while
certificates are included in every RSVP refresh
3.3 Policy
The content of policy elements is opaque to RSVP; their
format is understood by policy peers e.g. an RSVP Local
Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry
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
Policy state expires in the granularity of Policy
(POLICY_DATA objects are mere containers and do not expire as such).
Policy elements expire in the exact manner and time as the RSVP
received in the same message (see [RSVP] Section 3.7).
controlled state expires N times slower (see Section 3.2).
Only one policy element of a certain P-Type can be active at
given time. Therefore, policy elements are instantaneously
when another policy element of the same P-Type is received from
same PDP (previous or next policy RSVP_HOP). An empty policy
of a certain P-Type is used to delete (rather than a replace)
policy state of the same P-Type
Herzog Standards Track [Page 7]
RFC 2750 RSVP Extensions for Policy Control January 2000
4 Processing
These sections describe the minimal required policy processing
for RSVP
4.1 Basic
This memo mandates enforcing policy control for Path, Resv, PathErr
and ResvErr messages only. PathTear and ResvTear are assumed not
require policy control based on two main presumptions. First,
Integrity verification [MD5] guarantee that the Tear is received
the same node that sent the installed reservation, and second,
it is functionally equivalent to that node holding-off refreshes
this reservation
4.2 Default Handling for PIN
Figure 1 illustrates an example of where policy data objects
PIN nodes in transit from one PEP to another
A PIN node is required at a minimum to forward the
POLICY_DATA objects in the appropriate outgoing messages according
the following rules
o POLICY_DATA objects are to be forwarded as is, without
modifications
o Multicast merging (splitting) nodes
In the upstream direction
When multiple POLICY_DATA objects arrive from downstream,
RSVP node should concatenate all of them (as a list of
original POLICY_DATA objects) and forward them with
outgoing (upstream) message
On the downstream direction
When a single incoming POLICY_DATA object arrives
upstream, it should be forwarded (copied) to all
branches of the multicast tree
The same rules apply to unrecognized policies (sub-objects)
the POLICY_DATA object. However, since this can only occur in
policy-capable node, it is the responsibility of the PDP and
RSVP
Herzog Standards Track [Page 8]
RFC 2750 RSVP Extensions for Policy Control January 2000
4.3 Error
Policy errors are reported by either ResvErr or PathErr messages
a policy failure error code in the ERROR_SPEC object. Policy
message must include a POLICY_DATA object; the object
details of the error type and reason in a P-Type specific format (
Section 3.3).
If a multicast reservation fails due to policy reasons, RSVP
not attempt to discover which reservation caused the failure (as
would do for Blockade State). Instead, it should attempt to
the policy ResvErr to ALL downstream hops, and have the PDP (or LDP
decide where messages should be sent. This mechanism allows the
to limit the error distribution by deciding which "culprit" next-
should be informed. It also allows the PDP to prevent
distribution of ResvErr or PathErr messages by performing
repair (e.g. substituting the failed POLICY_DATA object with
different one).
Error codes are described in Appendix Appendix A
5 IANA
RSVP Policy Elements (P-Types
Following the policies outlined in [IANA-CONSIDERATIONS],
0-49151 are allocated as standard policy elements by IETF
action, numbers in the range 49152-53247 are allocated as
specific (one per vendor) by First Come First Serve, and
53248-65535 are reserved for private use and are not assigned
IANA
6 Security
This memo describes the use of POLICY_DATA objects to carry policy
related information between RSVP nodes. Two security mechanisms
be optionally used to ensure the integrity of the
information. The first mechanism relies on RSVP integrity [MD5]
provide a chain of trust when all RSVP nodes are policy capable.
second mechanism relies on the INTEGRITY object within
POLICY_DATA object to guarantee integrity between non-
RSVP PEPs (see Sections 2 and 3.2).
Herzog Standards Track [Page 9]
RFC 2750 RSVP Extensions for Policy Control January 2000
7
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "
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
Policy Service) Protocol", RFC 2748,
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
(RSVP) - Functional Specification", RFC 2205,
September 1997.
[MD5] Baker, F., Lindell B. and M. Talwar, "
Cryptographic Authentication", RFC 2747,
January 2000.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines
Writing an IANA Considerations Section
RFCs", BCP 26, RFC 2434, October 1998.
8
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, and
others
9 Author
Shai
IPHighway, Inc
55 New York
Framingham, MA 01701
Phone: (508) 620-1141
EMail: herzog@iphighway.
Herzog Standards Track [Page 10]
RFC 2750 RSVP Extensions for Policy Control January 2000
Appendix A: Policy Error
This Appendix extends the list of error codes described in Appendix
of [RSVP].
Note that Policy Element specific errors are reported as described
Section 4.3 and cannot be reported through RSVP (using
mechanism). However, this mechanism provides a simple, less
mechanism for reporting generic policy errors. Most likely the
would be used in concert such that a generic error code is
by RSVP, while Policy Element specific errors are encapsulated in
return POLICY_DATA object (as in Section 4.3).
ERROR_SPEC class = 6
Error Code = 02: Policy Control
Error Value: 16
0 = ERR_INFO : Information
1 = ERR_WARN :
2 = ERR_UNKNOWN : Reason
3 = ERR_REJECT : Generic Policy
4 = ERR_EXCEED : Quota or Accounting
5 = ERR_PREEMPT : Flow was
6 = ERR_EXPIRED : Previously installed policy expired (
refreshed
7 = ERR_REPLACED: Previous policy data was replaced &
8 = ERR_MERGE : Policies could not be merged (multicast
9 = ERR_PDP : PDP down or non
10= ERR_SERVER : Third Party Server (e.g., Kerberos)
11= ERR_PD_SYNTX: POLICY_DATA object has bad
12= ERR_PD_INTGR: POLICY_DATA object failed Integrity
13= ERR_PE_BAD : POLICY_ELEMENT object has bad
14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the
object
15= ERR_NO_RSC : PEP Out of resources to handle policies
16= ERR_RSVP : PDP encountered bad RSVP objects or
17= ERR_SERVICE : Service type was
18= ERR_STYLE : Reservation Style was
19= ERR_FL_SPEC : FlowSpec was rejected (too large
Values between 2^15 and 2^16-1 can be used for site and/or
error values
Herzog Standards Track [Page 11]
RFC 2750 RSVP Extensions for Policy Control January 2000
Appendix B: INTEGRITY computation for POLICY_DATA
Computation of the INTEGRITY option is based on the rules set
in [MD5], with the following modifications
Section 4.1:
Rather than computing digest for an RSVP message, a digest
computed for a POLICY_DATA object in the following manner
(1) The INTEGRITY object is inserted in the appropriate place
the POLICY_DATA object, and its location in the message
remembered for later use
(2) The PDP, at its discretion, and based on destination PEP/
or other criteria, selects an Authentication Key and the
algorithm to be used
(3) A copy of RSVP SESSION object is temporarily appended to
end of the PD object (for the computation purposes only
without changing the length of the POLICY_DATA object).
flags field of the SESSION object is set to 0.
concatenation is considered as the message for which a
is to be computed
(4) The rest of the steps in Section 4.1 ((4)..(9))
unchanged when computed over the concatenated message
Note: When the computation is complete, the SESSION object is
and is not part of the POLICY_DATA object
Other Provisions
The processing of a received POLICY_DATA object as well as
challenge-response INTEGRITY object inside a POLICY_DATA object
performed in the manner described in [MD5]. This processing
subject to the modified computation algorithm as described in
beginning of this appendix (for Section 4.1 of [MD5]).
Herzog Standards Track [Page 12]
RFC 2750 RSVP Extensions for Policy Control January 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Herzog Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
