draft-ietf-tsvwg-rsvp-proxy-proto-09.txt   draft-ietf-tsvwg-rsvp-proxy-proto-10.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Manner Updates: 2205 (if approved) J. Manner
Expires: November 5, 2009 University of Helsinki Intended status: Standards Track TKK
A. Narayanan Expires: April 29, 2010 A. Narayanan
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
H. Malik H. Malik
Bharti Bharti
May 4, 2009 October 26, 2009
RSVP Extensions for Path-Triggered RSVP Receiver Proxy RSVP Extensions for Path-Triggered RSVP Receiver Proxy
draft-ietf-tsvwg-rsvp-proxy-proto-09.txt draft-ietf-tsvwg-rsvp-proxy-proto-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 5, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 8 skipping to change at page 4, line 8
end-to-end path from the sender to the RSVP Receiver Proxy. However, end-to-end path from the sender to the RSVP Receiver Proxy. However,
as discussed in the companion document presenting RSVP Proxy as discussed in the companion document presenting RSVP Proxy
approaches, RSVP extensions are needed to facilitate operations with approaches, RSVP extensions are needed to facilitate operations with
an RSVP Receiver Proxy whose signaling is triggered by receipt of an RSVP Receiver Proxy whose signaling is triggered by receipt of
RSVP Path messages from the sender. This document specifies these RSVP Path messages from the sender. This document specifies these
extensions. extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions Used in This Document . . . . . . . . . . . . 7 1.1. Conventions Used in This Document . . . . . . . . . . . . 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 10
3.1. Sender Notification via PathErr Message . . . . . . . . . 12 3.1. Sender Notification via PathErr Message . . . . . . . . . 13
3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 16
3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 16
3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 17
3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 18
3.2. Sender Notification via Notify Message . . . . . . . . . . 18 3.2. Sender Notification via Notify Message . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Mechanisms for Maximizing the Reservation Span . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 4.1. Dynamic Discovery of Downstream RSVP Functionality . . . . 27
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 4.2. Receiver Proxy Control Policy Element . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.1. Default Handling . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . . 31 5.1. Security Considerations for the Sender Notification
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 via Notify Message . . . . . . . . . . . . . . . . . . . . 32
5.2. Security Considerations for the Receiver Proxy Control
Policy Element . . . . . . . . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
6.1. RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 34
6.2. Policy Element . . . . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Guaranteed QoS for some applications with tight QoS requirements may Guaranteed QoS for some applications with tight QoS requirements may
be achieved by reserving resources in each node on the end-to-end be achieved by reserving resources in each node on the end-to-end
path. The main IETF protocol for these resource reservations is RSVP path. The main IETF protocol for these resource reservations is RSVP
specified in [RFC2205]. RSVP does not require that all intermediate specified in [RFC2205]. RSVP does not require that all intermediate
nodes support RSVP, but it assumes that both the sender and the nodes support RSVP, but it assumes that both the sender and the
receiver of the data flow support RSVP. However, there are receiver of the data flow support RSVP. However, there are
environments where it would be useful to be able to reserve resources environments where it would be useful to be able to reserve resources
skipping to change at page 6, line 9 skipping to change at page 6, line 9
the sender (or RSVP Sender Proxy). the sender (or RSVP Sender Proxy).
Since the synchronization between an RSVP reservation and an Since the synchronization between an RSVP reservation and an
application is now effectively performed by the sender (or RSVP application is now effectively performed by the sender (or RSVP
Sender Proxy), it is important that the sender (or RSVP Sender Proxy) Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
is aware of the reservation state. However, as conventional RSVP is aware of the reservation state. However, as conventional RSVP
assumes that the reservation is to be controlled by the receiver, assumes that the reservation is to be controlled by the receiver,
some notifications about reservation state (notably the error message some notifications about reservation state (notably the error message
sent in case of admission control rejection of the reservation) are sent in case of admission control rejection of the reservation) are
only sent towards the receiver and therefore, in our case, sunk by only sent towards the receiver and therefore, in our case, sunk by
the RSVP Receiver Proxy. This document specifies extension to RSVP the RSVP Receiver Proxy. Section 3 of the present document specifies
procedures allowing such notifications also to be conveyed towards extensions to RSVP procedures allowing such notifications to be also
the sender. This facilitates synchronization by the sender (or RSVP conveyed towards the sender. This facilitates synchronization by the
Sender Proxy) between the RSVP reservation and the application sender (or RSVP Sender Proxy) between the RSVP reservation and the
requirements and facilitates sender-driven control of reservation in application requirements and facilitates sender-driven control of
scenarios involving a Path-Triggered RSVP receiver Proxy. reservation in scenarios involving a Path-Triggered RSVP receiver
Proxy.
With unicast applications in the presence of RSVP Receiver Proxies, With unicast applications in the presence of RSVP Receiver Proxies,
if the sender is notified about the state of the reservation towards if the sender is notified about the state of the reservation towards
the receiver (as enabled by the present document), the sender is the receiver (as enabled by the present document), the sender is
generally in a good position to synchronize the reservation with the generally in a good position to synchronize the reservation with the
application and to perform efficient sender-driven reservation: the application and to perform efficient sender-driven reservation: the
sender can control establishment (respectively removal) of the sender can control establishment (respectively removal) of the
reservation towards the receiver by sending Path (respectively reservation towards the receiver by sending Path (respectively
PathTear) messages. For example, if the sender is notified that the PathTear) messages. For example, if the sender is notified that the
reservation for a point to point audio session towards the receiver reservation for a point to point audio session towards the receiver
skipping to change at page 7, line 22 skipping to change at page 7, line 23
presence of a Path-triggered RSVP Receiver Proxy. As pointed out presence of a Path-triggered RSVP Receiver Proxy. As pointed out
previously, those apply equally whether RSVP signaling is initiated previously, those apply equally whether RSVP signaling is initiated
by a regular RSVP sender or by an RSVP Sender Proxy (with some means by a regular RSVP sender or by an RSVP Sender Proxy (with some means
to synchronize reservation state with application level requirements to synchronize reservation state with application level requirements
that are outside the scope of this document). For readability, the that are outside the scope of this document). For readability, the
rest of this document discusses operation assuming a regular RSVP rest of this document discusses operation assuming a regular RSVP
sender; however, such operation is equally applicable where an RSVP sender; however, such operation is equally applicable where an RSVP
Sender Proxy is used to initiated RSVP signaling on behalf of a non- Sender Proxy is used to initiated RSVP signaling on behalf of a non-
RSVP-capable sender. RSVP-capable sender.
As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], it is
important to keep in mind that the strongly recommended RSVP
deployment model remains end to end as assumed in [RFC2205] with RSVP
support on the sender and the receiver. The end to end model allows
the most effective synchronization between the reservation and
application requirements. Also, when compared to the end to end RSVP
model, the use of RSVP Proxies involves additional operational burden
and/or impose some topological constraints. Thus, the purpose of
this document is only to allow RSVP deployment in special
environments where RSVP just cannot be used on some senders and/or
some receivers for reasons specific to the environment.
Section 4.1.1 of [I-D.ietf-tsvwg-rsvp-proxy-approaches] discusses
mechanisms allowing the RSVP reservation for a given flow to be
dynamically extended downstream of an RSVP Proxy whenever possible
(i.e. When the receiver is RSVP capable or when there is another
RSVP Receiver Proxy downstream). This can considerably alleviate the
operational burden and the topological constraints associated with
Path-triggered RSVP Receiver Proxies. This allows (without
corresponding manual configuration) an RSVP reservation to
dynamically span as much of the corresponding flow path as possible,
with any arbitrary number of RSVP Receiver Proxies on the flow path
and whether the receiver is RSVP capable or not. In turn, this
facilitates migration from an RSVP deployment model based on Path-
triggered Receiver Proxies to an end-to-end RSVP model, since
receivers can gradually and independently be upgraded to support RSVP
and then instantaneously benefit from end-to-end reservations.
Section 4 of the present document specifies these mechanisms and
associated RSVP extensions.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The following terminology is borrowed from The following terminology is borrowed from
[I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the
skipping to change at page 19, line 31 skipping to change at page 20, line 31
o An RSVP sender interested in being notified of reservation failure o An RSVP sender interested in being notified of reservation failure
MUST include a Notify Request object (containing the sender's IP MUST include a Notify Request object (containing the sender's IP
address) in the Path messages it generates. address) in the Path messages it generates.
o Upon receiving a Path message with a Notify Request object, the o Upon receiving a Path message with a Notify Request object, the
RSVP Receiver Proxy MUST include a Notify Request object in the RSVP Receiver Proxy MUST include a Notify Request object in the
Resv messages it generates. This Notify Request object MUST Resv messages it generates. This Notify Request object MUST
contain: contain:
* either the address that was included in the Notify Request of * either the address that was included in the Notify Request of
the received Path message- a.k.a. the sender's address-. We the received Path message- a.k.a. The sender's address-. We
refer to this approach as the "Direct Notify". refer to this approach as the "Direct Notify".
* or an address of the Receiver Proxy. We refer to this approach * or an address of the Receiver Proxy. We refer to this approach
as the "Indirect Notify". as the "Indirect Notify".
o Upon receiving a downstream error notification (whether in the o Upon receiving a downstream error notification (whether in the
form of a Notify or a ResvErr or both), the RSVP Receiver Proxy: form of a Notify or a ResvErr or both), the RSVP Receiver Proxy:
* MUST generate a Notify message with upstream notification to * MUST generate a Notify message with upstream notification to
the corresponding sender, if the sender included a Notify the corresponding sender, if the sender included a Notify
skipping to change at page 20, line 9 skipping to change at page 21, line 9
is used. The reason for this recommendation is that the is used. The reason for this recommendation is that the
failure node may not support Notify, so that even if Direct failure node may not support Notify, so that even if Direct
Notification was requested by the RSVP Receiver Proxy, the Notification was requested by the RSVP Receiver Proxy, the
sender may not actually have received a Notify from the failure sender may not actually have received a Notify from the failure
node: generating a Notify from the Receiver Proxy will node: generating a Notify from the Receiver Proxy will
accelerate sender notification, as compared to simply relying accelerate sender notification, as compared to simply relying
on PathErr, in this situation. In controlled environments on PathErr, in this situation. In controlled environments
where all the nodes are known to support Notify, the Receiver where all the nodes are known to support Notify, the Receiver
Proxy MAY be configured to not generate the Notify with Proxy MAY be configured to not generate the Notify with
upstream notification when Direct Notification is used, in upstream notification when Direct Notification is used, in
order to avoid duplication of Notify messages (i.e. the sender order to avoid duplication of Notify messages (i.e. The sender
receiving both a Notify from the failure node and from the receiving both a Notify from the failure node and from the
Receiver Proxy) Receiver Proxy)
As a result of these sender and Receiver Proxy behaviors, as per As a result of these sender and Receiver Proxy behaviors, as per
existing Notify procedures, if an RSVP router detects an error existing Notify procedures, if an RSVP router detects an error
relating to a Resv state (e.g., admission control rejection after IP relating to a Resv state (e.g., admission control rejection after IP
reroute), the RSVP router will send a Notify message (conveying the reroute), the RSVP router will send a Notify message (conveying the
downstream notification with the ResvErr error code) to the IP downstream notification with the ResvErr error code) to the IP
address contained in the Resv Notify Request object. If this address address contained in the Resv Notify Request object. If this address
has been set by the RSVP Receiver Proxy to the sender's address has been set by the RSVP Receiver Proxy to the sender's address
skipping to change at page 26, line 5 skipping to change at page 27, line 5
those are conveying the same error information, only the Notify is those are conveying the same error information, only the Notify is
directly addressed to the sender while the PathErr travels hop-by- directly addressed to the sender while the PathErr travels hop-by-
hop). Therefore, operations of Indirect Notify method in the hop). Therefore, operations of Indirect Notify method in the
presence of multiple senders is similar to that of the PathErr method presence of multiple senders is similar to that of the PathErr method
as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST
be sent to the sender (respectively, the set of affected senders). be sent to the sender (respectively, the set of affected senders).
With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender,
again resulting in a somewhat over-conservative behavior in the again resulting in a somewhat over-conservative behavior in the
presence of multiple senders. presence of multiple senders.
4. Security Considerations 4. Mechanisms for Maximizing the Reservation Span
To ensure the integrity and authenticity of the associated This section defines extensions to RSVP procedures allowing an RSVP
reservation and admission control mechanisms, the RSVP Authentication reservation to span as much as possible of the flow path, with any
mechanisms defined in [RFC2747] and [RFC3097] can be used. Those arbitrary number of RSVP Receiver Proxies on the flow path and
whether the receiver is RSVP capable or not. This facilitates
deployment and operations of Path-triggered RSVP Receiver Proxies
since it alleviates the topological constraints and/or configuration
load otherwise associated with Receiver Proxies (e.g. Make sure
there is no RSVP Receiver Proxy for a flow upstream of a given
Receiver Proxy, ensure there is no Receiver Proxy for a flow if the
receiver is RSVP capable). This also facilitates migration from an
RSVP deployment model based on Path-triggered Receiver Proxies to an
end-to-end RSVP model, since receivers can gradually and
independently be upgraded to support RSVP and then instantaneously
benefit from end-to-end reservations.
Section 4.1 defines a method that allows a Path-triggered Receiver
Proxy function to discover whether there is another Receiver Proxy or
an RSVP capable receiver downstream and then dynamically extend the
span of the RSVP reservation downstream. A router implementation
claiming compliance with this document SHOULD support the method
defined in Section 4.1.
Section 4.2 defines a method that allows a sender to control whether
an RSVP router supporting the Path-triggered Receiver Proxy function
is to behave as a Receiver Proxy for a given flow or not. A router
implementation claiming compliance with this document MAY support the
method defined in Section 4.2.
In a given network environment, a network administrator may elect to
use the method defined in Section 4.1, or the method defined in
Section 4.2, or possibly combine the two.
4.1. Dynamic Discovery of Downstream RSVP Functionality
When generating a proxy Resv message upstream, a Receiver Proxy
supporting dynamic discovery of downstream RSVP functionality MUST
forward the Path message downstream instead of terminating it. If
the destination endpoint supports RSVP (or there is another Receiver
Proxy downstream), it will receive the Path and generate a Resv
upstream. When this Resv reaches the Receiver Proxy, it recognizes
the presence of a RSVP-capable receiver (or of another RSVP Receiver
Proxy) downstream and MUST internally converts its state from a
proxied reservation to a regular midpoint RSVP behavior. From then
on, the RSVP router MUST behave as a regular RSVP router for that
reservation (i.e. As if the RSVP router never behaved as an RSVP
receiver proxy for that flow).
If there is no RSVP-capable receiver (or other Receiver Proxy)
downstream of the Receiver Proxy, then the Path messages sent by the
Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by
default) will never be responded to. However, these messages consume
a small amount of bandwidth, and in addition would install some RSVP
state on RSVP-capable midpoint nodes downstream of the first Receiver
Proxy. This is seen as a very minor sub-optimality, however, to
mitigate this, the Receiver Proxy MAY tear down any unanswered
downstream Path state after a predetermined time, and MAY stop
sending Path messages for the flow (or MAY only send them at much
lower frequency).
This approach only requires support of the behavior described in the
previous paragraph and does not require any new RSVP extensions.
4.2. Receiver Proxy Control Policy Element
[RFC2750] defines extensions for supporting generic policy based
admission control in RSVP. These extensions include the standard
format of POLICY_DATA objects and a description of RSVP handling of
policy events.
The POLICY_DATA object contains one or more of Policy Elements, each
representing a different (and perhaps orthogonal) policy. As an
example, [RFC3181] specifies the Preemption Priority Policy Element.
The present document defines a new Policy Element called the Receiver
Proxy Control Policy Element. The present document only defines the
use of this Policy Element in Path messages and for unicast
reservations. Other usage are outside the scope of the present
document.
The format of the Receiver Proxy Control Policy Element is as shown
in Figure 6:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+
| Reserved |Control-Value|
+---------------------------+---------------------------+
Figure 6: Receiver Proxy Control Policy Element
where:
o Length: 16 bits
* Always 8. The overall length of the policy element, in bytes.
o P-Type: 16 bits
* REC_PROXY_CONTROL = To be allocated by IANA (see "IANA
Considerations" section)
o Reserved: 24 bits
* SHALL be set to zero on transmit and SHALL be ignored on
reception
o Control-Value: 8 bits (unsigned)
* 0 (Reserved). An RSVP Receiver Proxy that understands this
policy element MUST ignore the policy element if its Control-
Value is set to that value.
* 1 (Receiver-Proxy-Needed): An Receiver Proxy that understands
this policy element MUST attempt to insert itself as a Receiver
Proxy for that flow if the corresponding Path message contains
this Control-Value. If the Receiver Proxy also supports
dynamic discovery of downstream RSVP functionality as specified
in Section 4.1, it MUST still send the Path message downstream
and attempt to extend the reservation downstream so that the
reservation can be extended to the last Receiver Proxy). An
RSVP sender MAY insert the Receiver Proxy Control Policy
Element with this Control-Value when it knows (say by other
means such as application-level signalling) that the receiver
is not RSVP capable.
* 2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that
understands this policy element MUST NOT attempt to insert
itself as a Receiver Proxy for that flow if the corresponding
Path message contains this Control-Value. An RSVP sender MAY
insert the Receiver Proxy Control Policy Element with this
Control-Value when it knows (say by other means such as
application-level signalling) that the receiver is RSVP
capable.
4.2.1. Default Handling
As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes
(PINs) implement a default handling of POLICY_DATA objects ensuring
that those objects can traverse PIN nodes in transit from one Policy
Enforcement Point (PEP) to another. This applies to the situations
where POLICY_DATA objects contain the Receiver Proxy Control Policy
Element specified in this document, so that those can traverse PIN
nodes.
Section 4.2 of [RFC2750] also defines a similar default behavior for
policy-capable nodes that do not recognized a particular Policy
Element. This applies to the Receiver Proxy Control Policy Element
specified in this document, so that those can traverse policy-capable
nodes that do not support this document.
5. Security Considerations
As this document defines extensions to RSVP, the security
considerations of RSVP apply. Those are discussed in [RFC2205],
[RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches
for addressing those concerns are discussed further below.
The RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097]
protect RSVP message integrity hop-by-hop and provide node protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. These hop-by-hop against corruption and spoofing of RSVP messages. These hop-by-hop
integrity mechanisms can be used to protect RSVP reservations integrity mechanisms can be used to protect RSVP reservations
established using an RSVP receiver proxy in accordance with the established using an RSVP receiver proxy in accordance with the
present document. present document. [I-D.ietf-tsvwg-rsvp-security-groupkeying]
discusses key types and key provisioning methods as well as their
[RFC2747] discusses several approaches to key distribution. First, respective applicability to RSVP authentication. RSVP Authentication
the RSVP Authentication shared keys can be distributed manually. (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an
This is the base option and its support is mandated for every implementation of the present document.
implementation. However, in some environments, this approach may
become a burden if keys change frequently over time. Alternatively,
a standard key management protocol for secure key distribution can be
used.
The use of RSVP Authentication in parts of the network where there
may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such
as a Path message, an RSVP router does not know the RSVP next hop for
that message at the time of forwarding it. In fact, part of the role
of a Path message is precisely to discover the RSVP next hop (and to
dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security
association to use when forwarding such a message (see [RFC2747] for
definition of RSVP security association). In that situation, one
approach is to share the same RSVP Authentication key across all the
RSVP routers in a part of the network where there may be RSVP
neighbors with IP hops in between. For example, all the RSVP routers
of an administrative domain (including the receiver proxies) could
share the same RSVP Authentication key, while different per-neighbor
keys could be used between any RSVP router pair straddling the
boundary between two administrative domains that have agreed to use
RSVP signaling.
When the same RSVP Authentication key is to be shared among multiple
RSVP neighbors, manual key distribution may be used.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses
applicability of dynamic group key distribution method for dynamic applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and
update of such shared keys among RSVP routers. associated key provisioning methods for security protection of RSVP.
This discussion applies to the protection of RSVP in the presence of
Path-triggered RSVP Receiver Proxies as defined in the present
document.
The RSVP Authentication mechanisms do not provide confidentiality. A subset of RSVP messages are signaled with the router alert option
If confidentiality is required, IPsec ESP ([RFC4303]) may be used, ([RFC2113],[RFC2711]). Based on the current security concerns
although it imposes the burden of key distribution. It also faces associated with the use of the IP router alert option, the
the additional issue discussed for key management above in the case applicability of RSVP (and therefore of the RSVP Proxy approaches
where there can be IP hops in between RSVP hops. discussed in the present document) is limited to controlled
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of environments (i.e. Environments where the security risks associated
various keying methods for applying IPsec encryption and with the use of the router alert option are understood and protected
authentication to RSVP, including use of group keys and dynamic group against). The security aspects and common practices around the use
key distribution. of the current IP router alert option and consequences of using the
IP router alert option by applications such as RSVP are discussed in
details in [I-D.rahman-rtg-router-alert-considerations].
When an RSVP receiver proxy is used, the RSVP reservation is no When an RSVP receiver proxy is used, the RSVP reservation is no
longer controlled by the receiver, but rather is controlled by the longer controlled by the receiver, but rather is controlled by the
receiver proxy (using hints received from the sender in the Path receiver proxy (using hints received from the sender in the Path
message) on behalf of the sender. Thus, the receiver proxy ought to message) on behalf of the sender. Thus, the receiver proxy ought to
be trusted by the end-systems to control the RSVP reservation be trusted by the end-systems to control the RSVP reservation
appropriately. However, basic RSVP operation already assumes a trust appropriately. However, basic RSVP operation already assumes a trust
model where end-systems trust RSVP nodes to appropriately perform model where end-systems trust RSVP nodes to appropriately perform
RSVP reservations. So the use of RSVP receiver proxy is not seen as RSVP reservations. So the use of RSVP receiver proxy is not seen as
introducing any significant additional security threat or as introducing any significant additional security threat or as
skipping to change at page 27, line 43 skipping to change at page 32, line 26
tampered with; While the receivers are in locations that are tampered with; While the receivers are in locations that are
physically unsecured and therefore subject to a higher risk of being physically unsecured and therefore subject to a higher risk of being
tampered with. The use of an RSVP receiver proxy function tampered with. The use of an RSVP receiver proxy function
effectively increases the security of the operator's reservation and effectively increases the security of the operator's reservation and
admission control solution by completely excluding receivers from its admission control solution by completely excluding receivers from its
operation. Filters can be placed at the edge of the operator network operation. Filters can be placed at the edge of the operator network
discarding any RSVP message received from end-users. This provides a discarding any RSVP message received from end-users. This provides a
very simple and effective protection of the RSVP reservation and very simple and effective protection of the RSVP reservation and
admission control solution operating inside the operator's network. admission control solution operating inside the operator's network.
5.1. Security Considerations for the Sender Notification via Notify
Message
This document defines in Section 3.2 an optional method relying on This document defines in Section 3.2 an optional method relying on
the use of the Notify message specified in [RFC3473]. The Notify the use of the Notify message specified in [RFC3473]. The Notify
message can be sent in a non-hop-by-hop fashion that precludes use of message can be sent in a non-hop-by-hop fashion that precludes use of
RSVP hop-by-hop integrity and authentication model. The approaches RSVP hop-by-hop integrity and authentication model. The approaches
and considerations for addressing this issue presented in the and considerations for addressing this issue presented in the
Security Considerations section of [RFC3473] apply. In particular, Security Considerations section of [RFC3473] apply. In particular,
where the Notify messages are transmitted non-hop-by-hop and the same where the Notify messages are transmitted non-hop-by-hop and the same
level of security provided by [RFC2747] is desired, IPsec-based level of security provided by [RFC2747] is desired, IPsec-based
integrity and authentication can be used ([RFC4302] or [RFC4303]). integrity and authentication can be used ([RFC4302] or [RFC4303]).
Alternatively, the sending of non-hop-by-hop Notify messages can be Alternatively, the sending of non-hop-by-hop Notify messages can be
disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying] disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying]
discusses applicability of group keying for non-hop-by-hop Notify discusses applicability of group keying for non-hop-by-hop Notify
messages. messages.
5. IANA Considerations 5.2. Security Considerations for the Receiver Proxy Control Policy
Element
This document also defines inSection 4.2 the optional Receiver Proxy
Control Policy Element. Policy Elements are signaled by RSVP through
encapsulation in a Policy Data object as defined in [RFC2750].
Therefore, like any other Policy Elements, the integrity of the
Receiver Proxy Control Policy Element can be protected as discussed
in section 6 of [RFC2750] by two optional security mechanisms.
The first mechanism relies on the RSVP Authentication discussed above
that provides a chain of trust when all RSVP nodes are policy
capable. With this mechanism, the INTEGRITY object is carried inside
RSVP messages.
The second mechanism relies on the INTEGRITY object within the
POLICY_DATA object to guarantee integrity between RSVP Policy
Enforcement Points (PEPs) that are not RSVP neighbors. This is
useful only when some RSVP nodes are Policy Ignorant Nodes (PINs).
The INTEGRITY object within the POLICY_DATA object MAY be supported
by an implementation of the present document.
Details for computation of the content of the INTEGRITY object can be
found in Appendix B of [RFC2750]. This states that the Policy
Decision Point (PDP), at its discretion, and based on destination
PEP/PDP or other criteria, selects an Authentication Key and the hash
algorithm to be used. Keys to be used between PDPs can be
distributed manually or via standard key management protocol for
secure key distribution.
Note that where non-RSVP hops may exist in between RSVP hops, as well
as where RSVP capable Policy Ignorant Nodes (PINs) may exist in
between PEPs, it may be difficult for the PDP to determine what is
the destination PDP for a POLICY_DATA object contained in some RSVP
messages (such as a Path message). This is because in those cases
the next PEP is not known at the time of forwarding the message. In
this situation, key shared across multiple PDPs may be used. This is
conceptually similar to the use of key shared across multiple RSVP
neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying].
We observe also that this issue may not exist in some deployment
scenarios where a single (or low number of) PDP is used to control
all the PEPs of a region (such as an administrative domain). In such
scenarios, it may be easy for a PDP to determine what is the next hop
PDP, even when the next hop PEP is not known, simply by determining
what is the next region that will be traversed (say based on the
destination address).
6. IANA Considerations
6.1. RSVP Error Codes
Since, as discussed in Section 3.1.2, this document allows two Error Since, as discussed in Section 3.1.2, this document allows two Error
Codes to be used in PathErr messages while [RFC2205] only specified Codes to be used in PathErr messages while [RFC2205] only specified
their use in ResvErr messages, this document requires that IANA their use in ResvErr messages, this document requires that IANA
updates the existing entries for these two Error Codes under the updates the existing entries for these two Error Codes under the
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. "Error Codes and Globally-Defined Error Value Sub-Codes" registry.
Each entry should refer to this document, in addition to referring to Each entry should refer to this document, in addition to referring to
[RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2
should respectively read: should respectively read:
skipping to change at page 30, line 5 skipping to change at page 34, line 49
TBD Unrecoverable Receiver Proxy Error [RFCXXX] TBD Unrecoverable Receiver Proxy Error [RFCXXX]
The sixteen bits of the Error Value field are defined in [RFCXXX] The sixteen bits of the Error Value field are defined in [RFCXXX]
" "
where [RFCXXX] refers to this document and TBD is the value to be where [RFCXXX] refers to this document and TBD is the value to be
allocated by IANA. allocated by IANA.
6. Acknowledgments 6.2. Policy Element
This document defines in Section 4.2 a new Policy Element called the
Receiver Proxy Control Policy Element. As specified in [RFC2750],
Standard RSVP Policy Elements (P-type values) are to be assigned by
IANA as per "IETF Consensus" policy following the policies outlined
in [RFC2434] (this policy is now called "IETF Review" as per
[RFC5226]) .
Thus, this document requires that IANA allocates one P-Type to the
Receiver Proxy Control Policy Element from the Standard RSVP Policy
Element range.
In Section 4.2, the present document defines a Control-Value field
inside the Receiver Proxy Control Policy Element. IANA needs to
create a registry for this field and allocate the following values:
o 0 : Reserved
o 1 : Receiver-Proxy-Needed
o 2 : Receiver-Proxy-Not-Needed
Following the policies outlined in [RFC5226], numbers in the range
3-127 are allocated according to the "IETF Review" policy, numbers in
the range 128-240 as "First Come First Served" and numbers between
241-255 are reserved for "Private Use".
7. Acknowledgments
This document benefited from discussions with Carol Iturralde and This document benefited from discussions with Carol Iturralde and
Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided
review and guidance, in particular on the usage of the review and guidance, in particular on the usage of the
Path_State_Removed flag and of the Notify message, both borrowed from Path_State_Removed flag and of the Notify message, both borrowed from
[RFC3473]. We also thank Ken Carlberg for his valuable input. [RFC3473]. We also thank Stephen Kent, Ken Carlberg and Tim Polk for
their valuable input and proposed enhancements. Finally we thank
Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating
the work on extensions maximizing the reservation span and
facilitating migration from Proxy model to end-to-end RSVP model.
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
8.2. Informative References
[I-D.ietf-tsvwg-rsvp-proxy-approaches] [I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
Proxy Approaches", Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in
progress), October 2008. progress), May 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.rahman-rtg-router-alert-considerations]
Behringer, M. and F. Faucheur, "Applicability of Keying Faucheur, F., "IP Router Alert Considerations and Usage",
Methods for RSVP Security", draft-rahman-rtg-router-alert-considerations-02 (work in
draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in progress), July 2009.
progress), March 2009.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005.
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
Jukka Manner Jukka Manner
University of Helsinki Helsinki University of Technology (TKK)
P.O. Box 68 P.O. Box 3000
University of Helsinki FIN-00014 University of Helsinki Espoo FIN-02015 TKK
Finland Finland
Phone: +358 9 191 51298 Phone: +358 9 451 2481
Email: jmanner@cs.helsinki.fi Email: jukka.manner@tkk.fi
URI: http://www.cs.helsinki.fi/u/jmanner/ URI: http://www.netlab.tkk.fi/~jmanner/
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MAS 01719 Boxborough, MAS 01719
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Allan Guillou Allan Guillou
Neuf Cegetel SFR
40-42 Quai du Point du Jour 40-42 Quai du Point du Jour
Boulogne-Billancourt, 92659 Boulogne-Billancourt, 92659
France France
Email: allan.guillou@sfr.com Email: allan.guillou@sfr.com
Hemant Malik Hemant Malik
Bharti Airtel Ltd. Bharti Airtel Ltd.
4th Floor, Tower A, Unitech Cyber Park 4th Floor, Tower A, Unitech Cyber Park
Gurgaon, Sector 39, 122001 Gurgaon, Sector 39, 122001
India India
 End of changes. 31 change blocks. 
97 lines changed or deleted 386 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/