draft-ietf-rap-rsvp-ext-03.txt   draft-ietf-rap-rsvp-ext-04.txt 
Internet Draft Shai Herzog Internet Draft Shai Herzog
Expiration: August 1999 IPHighway Expiration: August 1999 IPHighway
File: draft-ietf-rap-rsvp-ext-03.txt File: draft-ietf-rap-rsvp-ext-04.txt
Updates RFC 2205
RSVP Extensions for Policy Control RSVP Extensions for Policy Control
February 13, 1999 February 26, 1999
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
Abstract.............................................................1 Abstract.............................................................1
Table of Contents....................................................2 Table of Contents....................................................2
1 Introduction.......................................................3 1 Introduction.......................................................3
2 Policy Data Object Format..........................................3 2 Policy Data Object Format..........................................3
2.1 Base Format.....................................................4 2.1 Base Format.....................................................4
2.2 Options.........................................................4 2.2 Options.........................................................4
2.3 Native RSVP Options.............................................5 2.3 Native RSVP Options.............................................5
2.3.1 Other Options..................................................6 2.4 Other Options...................................................6
2.4 Policy Elements.................................................7 2.5 Policy Elements.................................................7
3 Processing Rules...................................................7 3 Processing Rules...................................................7
3.1 Basic Signaling.................................................7 3.1 Basic Signaling.................................................7
3.2 Default Handling................................................7 3.2 Default Handling................................................7
3.3 Error Signaling.................................................8 3.3 Error Signaling.................................................8
4 IANA Considerations................................................9 4 IANA Considerations................................................9
5 References.........................................................9 5 Security Considerations............................................9
6 Acknowledgments....................................................9 6 References........................................................10
7 Author Information.................................................9 7 Acknowledgments...................................................10
A. Appendix: Policy Error Codes......................................10 8 Author Information................................................10
A. Appendix: Policy Error Codes.....................................11
1 Introduction 1 Introduction
RSVP, by definition, discriminates between users, by providing some RSVP, by definition, discriminates between users, by providing some
users with better service at the expense of others. Therefore, it is users with better service at the expense of others. Therefore, it is
reasonable to expect that RSVP be accompanied by mechanisms for reasonable to expect that RSVP be accompanied by mechanisms for
controlling and enforcing access and usage policies. Historically, controlling and enforcing access and usage policies. Historically,
when RSVP Ver. 1 was developed, the knowledge and understanding of 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 policy issues was in its infancy. As a result, Ver. 1 of the RSVP
Functional Specifications [RSVP] left a place holder for policy Functional Specifications [RSVP] left a place holder for policy
skipping to change at page 4, line 42 skipping to change at page 4, line 42
Always 0. Always 0.
Option List: Variable length Option List: Variable length
The list of options and their usage is defined in Section The list of options and their usage is defined in Section
2.2. 2.2.
Policy Element List: Variable length Policy Element List: Variable length
The contents of policy elements is opaque to RSVP. See more The contents of policy elements is opaque to RSVP. See more
details in Section 2.4. details in Section 2.5.
2.2 Options 2.2 Options
This section describes a set of options that may appear in This section describes a set of options that may appear in
POLICY_DATA objects. All policy options appear as RSVP objects; some POLICY_DATA objects. All policy options appear as RSVP objects; some
use their valid original format while others appear as NULL objects. use their valid original format while others appear as NULL objects.
2.3 Native RSVP Options 2.3 Native RSVP Options
The following objects retain the same format specified in [RSVP] The following objects retain the same format specified in [RSVP]
skipping to change at page 5, line 20 skipping to change at page 5, line 20
FILTER_SPEC object (list) or SCOPE object FILTER_SPEC object (list) or SCOPE object
The set of senders associated with the POLICY_DATA object. If none The set of senders associated with the POLICY_DATA object. If none
is provided, the policy information is assumed to be associated with is provided, the policy information is assumed to be associated with
all the flows of the session. These two types of objects are all the flows of the session. These two types of objects are
mutually exclusive, and cannot be mixed. mutually exclusive, and cannot be mixed.
This option is only useful for WF or SE reservation styles, where This option is only useful for WF or SE reservation styles, where
merged reservations may have originally been intended for different merged reservations may have originally been intended for different
subsets of senders. It can also be used to prevent “policy loops” in 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 a manner similar to the usage of RSVP's SCOPE object. Using this
option may have significant impact on scaling and size of option may have significant impact on scaling and size of
POLICY_DATA objects and therefore should be taken with care. POLICY_DATA objects and therefore should be taken with care.
Originating RSVP_HOP Originating RSVP_HOP
The RSVP_HOP object identifies the neighbor/peer policy-capable node The RSVP_HOP object identifies the neighbor/peer policy-capable node
that constructed the policy object. When policy is enforced at that constructed the policy object. When policy is enforced at
border nodes, peer policy nodes may be several RSVP hops away from border nodes, peer policy nodes may be several RSVP hops away from
each other and the originating RSVP_HOP is the basis for the each other and the originating RSVP_HOP is the basis for the
mechanism that allows them to recognize each other and communicate mechanism that allows them to recognize each other and communicate
skipping to change at page 5, line 49 skipping to change at page 5, line 49
Destination RSVP_HOP Destination RSVP_HOP
A second RSVP_HOP object may follow the originating RSVP_HOP object. A second RSVP_HOP object may follow the originating RSVP_HOP object.
This second RSVP_HOP identifies the destination policy node. This is This second RSVP_HOP identifies the destination policy node. This is
used to ensure the POLICY_DATA object is delivered to targeted used to ensure the POLICY_DATA object is delivered to targeted
policy nodes. It may be used to emulate unicast delivery in policy nodes. It may be used to emulate unicast delivery in
multicast Path messages. It may also help prevent using a policy multicast Path messages. It may also help prevent using a policy
object in other parts of the network (replay attack). object in other parts of the network (replay attack).
On the receiving side, a policy node should ignore any POLCY_DATA On the receiving side, a policy node should ignore any POLCY_DATA
that includes a destination RSVP_HOP that doesnt match its own IP that includes a destination RSVP_HOP that doesn't match its own IP
address. address.
INTEGRITY Object INTEGRITY Object
The INTEGRITY object provides guarantees that the object was not The INTEGRITY object provides guarantees that the object was not
compromised. It follows the rules from [MD5], and is calculated over compromised. It follows the rules from [MD5], and is calculated over
the POLICY_DATA object, the SESSION object, and the message type the POLICY_DATA object, the SESSION object, and the message type
field (byte, padded with zero to 32 bit) as if they formed one field (byte, padded with zero to 32 bit) as if they formed one
continuous in-order message. This concatenation is designed to continuous in-order message. This concatenation is designed to
prevent copy and replay attacks of POLICY_DATA objects from other prevent copy and replay attacks of POLICY_DATA objects from other
sessions, flows, message types or even other network locations. sessions, flows, message types or even other network locations.
2.3.1 Other Options 2.4 Other Options
All options that do not use a valid RSVP object format, should use All options that do not use a valid RSVP object format, should use
the NULL RSVP object format with different C-Type values. This the NULL RSVP object format with different C-Type values. This
document defines only one such option, however, several other may be document defines only one such option, however, several other may be
considered in future versions. (e.g., Fragmentation, NoChange, considered in future versions. (e.g., Fragmentation, NoChange,
etc.). etc.).
o Policy Refresh Period (PRP) o Policy Refresh Period (PRP)
The Policy Refresh Period (PRP) option is used slow down policy The Policy Refresh Period (PRP) option is used slow down policy
skipping to change at page 7, line 14 skipping to change at page 7, line 14
This option is especially useful to combine strong (high overhead) This option is especially useful to combine strong (high overhead)
and weak (low overhead) authentication certificates. In such schemes and weak (low overhead) authentication certificates. In such schemes
the weak certificate supports admitting a reservation only for a the weak certificate supports admitting a reservation only for a
limited time, after which the strong certificate is required. limited time, after which the strong certificate is required.
This approach may reduce the overhead of POLICY_DATA processing. This approach may reduce the overhead of POLICY_DATA processing.
Strong certificates could be transmitted less frequently, while weak Strong certificates could be transmitted less frequently, while weak
certificates could be included in every RSVP refresh. certificates could be included in every RSVP refresh.
2.4 Policy Elements 2.5 Policy Elements
The content of policy elements is opaque to RSVP; their internal The content of policy elements is opaque to RSVP; their internal
format is understood by policy peers e.g. an RSVP Local Decision format is understood by policy peers e.g. an RSVP Local Decision
Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of
policy element codepoints and their meaning is maintained by [IANA- policy element codepoints and their meaning is maintained by [IANA-
CONSIDERATIONS] (also see Section 4). CONSIDERATIONS] (also see Section 4).
Policy Elements have the following format: Policy Elements have the following format:
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 9, line 16 skipping to change at page 9, line 16
RSVP Policy Elements RSVP Policy Elements
Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0- Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0-
49151 are allocated as standard policy elements by IETF Consensus 49151 are allocated as standard policy elements by IETF Consensus
action, numbers in the range 49152-53247 are allocated as vendor action, numbers in the range 49152-53247 are allocated as vendor
specific (one per vendor) by First Come First Serve, and numbers specific (one per vendor) by First Come First Serve, and numbers
53248-65535 are reserved for private use and are not assigned by 53248-65535 are reserved for private use and are not assigned by
IANA. IANA.
5 References 5 Security Considerations
This draft 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 Section 2.3).
6 References
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission
Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999. Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R.,
Sastry, A., "The COPS (Common Open Policy Service) Protocol", Sastry, A., "The COPS (Common Open Policy Service) Protocol",
IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999. IETF <draft-ietf-rap-cops-05.txt>, Jan. 1999.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Proposed Standard, Functional Specification.", IETF RFC 2205, Proposed Standard,
Sep. 1997. Sep. 1997.
[MD5] Baker, F., Linden B., Talwar, M. RSVP Cryptographic [MD5] Baker, F., Linden B., Talwar, M. "RSVP Cryptographic
Authentication" Internet-Draft, <draft-ietf-rsvp-md5-07.txt>, Authentication" Internet-Draft, <draft-ietf-rsvp-md5-07.txt>,
Nov. 1998. Nov. 1998.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 2434, Writing an IANA Considerations Section in RFCs", RFC 2434,
October 1998. October 1998.
6 Acknowledgments 7 Acknowledgments
This document incorporates inputs from Lou Berger, Bob Braden, This document incorporates inputs from Lou Berger, Bob Braden,
Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis,
Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many
others. others.
7 Author Information 8 Author Information
Shai Herzog, IPHighway Shai Herzog, IPHighway
Parker Plaza, Suite 1500 Parker Plaza, Suite 1500
400 Kelby St. 400 Kelby St.
Fort-Lee, NJ 07024 Fort-Lee, NJ 07024
(201) 585-0800 (201) 585-0800
herzog@iphighway.com herzog@iphighway.com
A. Appendix: Policy Error Codes A. Appendix: Policy Error Codes
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/