5. Security Considerations
In the environments of concern for this document, RSVP messages are
used to control resource reservations on a segment of the end-to-end
path of flows. The general security considerations associated with
[RFC2205] apply. To ensure the integrity of the associated
reservation and admission control mechanisms, the RSVP cryptographic
authentication mechanisms defined in [RFC2747] and [RFC3097] can be
used. Those protect RSVP messages integrity hop-by-hop and provide
node authentication, thereby protecting against corruption, spoofing
of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and
key provisioning methods, as well as their respective applicability
to RSVP authentication.
[RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms
([RFC4302][RFC4303]) and associated key provisioning methods for
security protection of RSVP. This discussion applies to the
protection of RSVP in the presence of RSVP proxies as defined in this
A subset of RSVP messages are signaled with the IP router alert
option ([RFC2113], [RFC2711]). Based on the current security
concerns associated with the use of the IP router alert option, the
applicability of RSVP (and therefore of the RSVP proxy approaches
discussed in this document) is limited to controlled environments
(i.e., environments where the security risks associated with the use
of the IP router alert option are understood and protected against).
The security aspects and common practices around the use of the
current IP router alert option, and consequences of using the IP
router alert option by applications such as RSVP, are discussed in
detail in [RTR-ALERT].
A number of additional security considerations apply to the use of
RSVP proxies and are discussed below.
With some RSVP proxy approaches, the RSVP proxy operates autonomously
inside an RSVP router. This is the case for the Path-Triggered Proxy
approaches defined in Section 4.1 and in Section 4.2, for the
Inspection-Triggered Proxy approach defined in Section 4.3, for the
STUN-Triggered Proxy approach defined in Section 4.4, and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
reservation operation assumes that the RSVP proxy can be trusted to
behave correctly in order to control the RSVP reservation as required
and expected by the end-systems. Since the basic RSVP operation
already assumes a trust model where end-systems trust RSVP nodes to
appropriately perform RSVP reservations, the use of an RSVP proxy
that behaves autonomously within an RSVP router is not seen as
introducing any significant additional security threat or as
fundamentally modifying the RSVP trust model.
With some RSVP proxy approaches, the RSVP proxy operates under the
control of another entity. This is the case for the
Application_Entity-Controlled Proxy approach defined in Section 4.5
and for the Policy_Server-Controlled Proxy approach defined in
Section 4.6. This introduces additional security risks since the
entity controlling the RSVP proxy needs to be trusted for proper
reservation operation and also introduces additional authentication
and confidentiality requirements. The exact mechanisms to establish
such trust, authentication, and confidentiality are beyond the scope
of this document, but they may include security mechanisms inside the
protocol used as the control interface between the RSVP proxy and the
entity controlling it, as well as security mechanisms for all the
interfaces involved in the reservation control chain (e.g., inside
the application signaling protocol between the end-systems and the
application entity, and, in the case of the Policy_Server-Controlled
Proxy approach, in the protocol between the application entity and
the policy server).
In some situations, the use of RSVP proxy to control reservations on
behalf of end-systems may actually reduce the security risk (at least
from the network operator viewpoint). This could be the case, for
example, because the routers where the RSVP proxy functionality runs
are less exposed to tampering than end-systems. Such a case is
further discussed in Section 4 of [RFC5946]. This could also be the
case because the use of RSVP proxy allows localization of RSVP
operation within the boundaries of a given administrative domain
(thus easily operating as a controlled environment) while the end-to-
end flow path spans multiple administrative domains.
This document benefited from earlier work on the concept of RSVP
proxy including the one documented by Silvano Gai, Dinesh Dutt,
Nitsan Elfassy, and Yoram Bernet. It also benefited from discussions
with Pratik Bose, Chris Christou, and Michael Davenport. Tullio
Loffredo and Massimo Sassi provided the base material for
Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu,
Ross Callon, Cullen Jennings, and Jari Arkko for their thorough
review and comments.
7.1. Normative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
7.2. Informative References
[QOS-MOBILE] Manner, J., "Provision of Quality of Service in IP-
based Mobile Access Networks", Doctoral
dissertation, University of Helsinki, 2003,
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Application Identity Policy Element for Use with
RSVP", RFC 2872, June 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F., and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session
Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and
B. Moore, "Policy Quality of Service (QoS)
Information Model", RFC 3644, November 2003.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
and M. Davenport, "Generic Aggregate Resource
ReSerVation Protocol (RSVP) Reservations", RFC 4860,
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS)
Signaling in a Nested Virtual Private Network",
RFC 4923, August 2007.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
Service (QoS) Mechanism Selection in the Session
Description Protocol (SDP)", RFC 5432, March 2009.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R.,
Hawrylyshen, A., and M. Bhatia, "Requirements from
Session Initiation Protocol (SIP) Session Border
Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria,
A., and G. Zorn, "Diameter Quality-of-Service
Application", RFC 5866, May 2010.
[RFC5946] Le Faucheur, F., Manner, J., Narayanan, A., Guillou,
A., and H. Malik, "Resource Reservation Protocol
(RSVP) Extensions for Path-Triggered RSVP Receiver
Proxy", RFC 5946, October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-
Service Signaling", RFC 5974, October 2010.
[RSVP-SEC-KEY] Behringer, M. and F. Le Faucheur, "Applicability of
Keying Methods for RSVP Security", Work in Progress,
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and
Usage", Work in Progress, October 2009.
[W3C] "World Wide Web Consortium (W3C) - Web Services
Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks
As broadband services for residential customers are becoming more and
more prevalent, next-generation aggregation networks are being
deployed in order to aggregate traffic from broadband users (whether
attached via Digital Subscriber Line technology, aka DSL; Fiber To
The Home/Curb, aka FTTx; Cable; or other broadband access
technology). Video on Demand (VoD) services, which may be offered to
broadband users, present significant capacity planning challenges for
the aggregation network for a number of reasons. First, each VoD
stream requires significant dedicated sustained bandwidth (typically
2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition
TV). Secondly, the VoD codec algorithms are very sensitive to packet
loss. Finally, the load resulting from such services is very hard to
predict (e.g., it can vary quite suddenly with blockbuster titles
made available as well as with promotional offerings). As a result,
transport of VoD streams on the aggregation network usually translate
into a strong requirement for admission control. The admission
control solution protects the quality of established VoD sessions by
rejecting the additional excessive session attempts during
unpredictable peaks, during link or node failures, or a combination
of those factors.
RSVP can be used in the aggregation network for admission control of
the VoD sessions. However, since customer premises equipment such as
Set Top Boxes (STBs) (which behave as the receiver for VoD streams)
often do not support RSVP, the last IP hop in the aggregation network
can behave as an RSVP Receiver Proxy. This way, RSVP can be used
between VoD pumps and the last IP hop in the aggregation network to
perform accurate admission control of VoD streams over the resources
set aside for VoD in the aggregation network (typically a certain
percentage of the bandwidth of any link). As VoD streams are
unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as
described in Section 4.1) is all that is required in this use case.
Figure 14 illustrates operation of RSVP-based admission control of
VoD sessions in an aggregation network involving RSVP support on the
VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop
of the aggregation network. All the customer premises equipment
| VoD SRM |
/ |-------------| \
|****| *** *** *** |********| |-----| |---|
|VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| *** *** *** |Receiver| |-----| |---|
|****| |Proxy |
SRM Session Resource Manager
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
==> segment of flow path protected by RSVP reservation
/\ VoD Application-level signaling (e.g., RTSP)
Figure 14: VoD Use Case with Receiver Proxy
In the case where the VoD pumps are not RSVP-capable, an
Application_Entity-Controlled Sender Proxy via the "RSVP over GRE"
approach (as described in Section 4.5.1) can also be implemented on
the VoD Controller or Session Resource Manager (SRM) devices
typically involved in VoD deployments. Figure 15 illustrates
operation of RSVP-based admission control of VoD sessions in an
aggregation network involving such an Application_Entity-Controlled
Source Proxy combined with an RSVP Receiver Proxy on the last IP hop
of the aggregation network. All the customer premises equipment, as
well as the VoD pumps, remain RSVP-unaware.
////| VoD SRM |\\\\\\\\\\\
/ | | \
/ | + | \
/ | RSVP Sender | \
/ |Proxy Control| \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |Proxy |
SRM Systems Resource Manager
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
==> segment of flow path protected by RSVP reservation
/ VoD Application-level signaling (e.g., RTSP)
/=/ GRE-tunneled RSVP (Path messages)
Figure 15: VoD Use Case with Receiver Proxy
and SRM-Based Sender Proxy
The RSVP proxy entities specified in this document play a significant
role here since they allow immediate deployment of an RSVP-based
admission control solution for VoD without requiring any upgrade to
the huge installed base of non-RSVP-capable customer premises
equipment. In one mode described above, they also avoid upgrade of
non-RSVP-capable VoD pumps. In turn, this means that the benefits of
on-path admission control can be offered to VoD services over
broadband aggregation networks without network or VoD pump upgrade.
Those include accurate bandwidth accounting regardless of topology
(hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic
adjustment to any change in topology (such as failure, routing
change, additional links, etc.).
A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in
More and more enterprises are migrating their telephony and
videoconferencing applications onto IP. When doing so, there is a
need for retaining admission control capabilities of existing TDM-
based (Time-Division Multiplexing) systems to ensure the QoS of these
applications is maintained even when transiting through the
enterprise's Wide Area Network (WAN). Since many of the endpoints
already deployed (such as IP phones or videoconferencing terminals)
are not RSVP-capable, RSVP proxy approaches are very useful: they
allow deployment of an RSVP-based admission control solution over the
WAN without requiring upgrade of the existing terminals.
A common deployment architecture for such environments relies on the
Application_Entity-Controlled Proxy approach as defined in
Section 4.5. Routers sitting at the edges of the WAN are naturally
"on-path" for all inter-campus calls (or sessions) and behave as RSVP
proxies. The RSVP proxies establish, maintain, and tear down RSVP
reservations over the WAN segment for the calls (or sessions) under
the control of the SIP server/proxy. The SIP server/proxy
synchronizes the RSVP reservation status with the status of end-to-
end calls. For example, the called IP phone will only be instructed
to play a ring tone if the RSVP reservation over the corresponding
WAN segment has been successfully established.
This architecture allowing RSVP-based admission control of voice and
video on the enterprise WAN is illustrated in Figure 16.
packets. Increasingly popular multimedia applications would benefit
from better than best-effort service from the network, a forwarding
service with strict Quality of Service (QoS) with guaranteed minimum
bandwidth and bounded delay. Other applications, such as electronic
commerce, network control and management, and remote-login
applications, would also benefit from a differentiated treatment.
The IETF has two main models for providing differentiated treatment
of packets in routers. The Integrated Services (IntServ) model
[RFC1633], together with the Resource Reservation Protocol (RSVP)
[RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to-
end transmission service. The Differentiated Services (Diffserv)
framework [RFC2475] provides non-signaled flow differentiation that
usually provides, but does not guarantee, proper transmission
However, these architectures have potential weaknesses for deployment
in Mobile Access Networks. For example, RSVP requires support from
both communication endpoints, and the protocol may have potential
performance issues in mobile environments. Diffserv can only provide
statistical guarantees and is not well suited for dynamic
Let us consider a scenario, where a fixed network correspondent node
(CN) would be sending a multimedia stream to an end host behind a
wireless link. If the correspondent node does not support RSVP, it
cannot signal its traffic characteristics to the network and request
specific forwarding services. Likewise, if the correspondent node is
not able to mark its traffic with a proper Differentiated Services
codepoint (DSCP) to trigger service differentiation, the multimedia
stream will get only best-effort service, which may result in poor
visual and audio quality in the receiving application. Even if the
connecting wired network is over-provisioned, an end host would still
benefit from local resource reservations, especially in wireless
access networks, where the bottleneck resource is most probably the
RSVP proxies would be a very beneficial solution to this problem. It
would allow distinguishing local network reservations from the end-
to-end reservations. The end host does not need to know the access
network topology or the nodes that will reserve the local resources.
The access network would do resource reservations for both incoming
and outgoing flows based on certain criteria, e.g., filters based on
application protocols. Another option is that the mobile end host
makes an explicit reservation that identifies the intention, and the
access network will find the correct local access network node(s) to
respond to the reservation. RSVP proxies would, thus, allow resource
reservation over the segment that is the most likely bottleneck, the
wireless link. If the wireless access network uses a local mobility
management mechanism, where the IP address of the mobile node does
not change during handover, RSVP reservations would follow the mobile
A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways
[RFC4923] discusses how resource reservation can be supported end-to-
end in a nested VPN environment. At each VPN level, VPN routers
behave as [RFC4301] security gateways between a plaintext domain and
a ciphertext domain. To achieve end-to-end resource reservation, the
VPN routers process RSVP signaling on the plaintext side, perform
aggregation of plaintext reservations, and maintain the corresponding
aggregate RSVP reservations on the ciphertext side. Each aggregate
reservation is established on behalf of multiple encrypted end-to-end
sessions sharing the same ingress and egress VPN routers. These
aggregate reservations can be as specified in [RFC3175] or [RFC4860].
Section 3 of [RFC4923] discusses the necessary data flows within a
VPN router to achieve the behavior described in the previous
paragraph. Two mechanisms are described to achieve such data flows.
Section 3.1 presents the case where the VPN router carries data
across the cryptographic boundary. Section 3.2 discusses the case
where the VPN router uses a Network Guard.
Where such mechanisms are not supported by the VPN routers, the
approach for end-to-end reservations presented in [RFC4923] cannot be
deployed. An alternative approach to support resource reservations
within the ciphertext core is to use the Application_Entity-
Controlled Proxy approach (as defined in Section 4.5) in the
o the RSVP proxies are located inside the ciphertext domain and use
aggregate RSVP reservations.
o the application entity exchange application-level signaling with
the end-systems in the plaintext domain.
o the application entity controls the RSVP proxies in the ciphertext
domain via an RSVP proxy control interface.
This is illustrated in Figure 17 in the case where the application is
SIP-based multimedia communications.
Where the sender and receiver are RSVP-capable, they may also use
RSVP signaling. This achieves resource reservation on the plaintext
segments of the end-to-end, i.e.,
o from the sender to the ingress IPsec gateway, and
o from the egress IPsec gateway to the receiver.
In this use case, because the VPN routers do not support any RSVP-
specific mechanism, the end-to-end RSVP signaling is effectively
hidden by the IPsec gateways on the ciphertext segment of the end-to-
As with the Application_Entity-Controlled Proxy approach (defined in
Section 4.5), the solution here for synchronizing RSVP signaling with
application-level signaling is to rely on an application-level
signaling device that controls an on-path RSVP proxy function.
However, in this use case, the RSVP proxies are a component of a
ciphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications, including the
1. encrypted flows cannot be identified in the ciphertext domain so
that network nodes can only classify traffic based on IP address
and Differentiated Services codepoints (DSCPs). As a result,
only aggregate RSVP reservations (such as those specified in
[RFC3175] or [RFC4860]) can be used. This is similar to
2. Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be
used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the
application entity may maintain awareness of which RSVP proxy is
on the ciphertext path between a given pair of IPsec gateways.
How such awareness is achieved is beyond the scope of this
document. We simply observe that such awareness can be easily
achieved through simple configuration in the particular case
where a single (physical or logical) RSVP proxy is fronting a
given IPsec gateway. We also observe that when awareness of the
RSVP Receiver Proxy for a particular egress IPsec gateway (or
end-to-end flow) is not available, the aggregate reservation may
be signaled by the RSVP Sender Proxy to the destination address
of the egress IPsec gateway and then proxied by the RSVP Receiver
Different flavors of operations are possible in terms of aggregate
reservation sizing. For example, the application entity can initiate
an aggregate reservation of fixed size a priori and then simply keep
count of the bandwidth used by sessions and reject sessions that
would result in excess usage of an aggregate reservation. The
application entity could also re-size the aggregate reservations on a
session-by-session basis. Alternatively, the application entity
could re-size the aggregate reservations in step increments typically
corresponding to the bandwidth requirement of multiple sessions.
Francois Le Faucheur
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
Phone: +33 4 97 23 26 19
Department of Communications and Networking (Comnet)
P.O. Box 13000
Phone: +358 9 470 22481
170 West Tasman Drive
San Jose, CA 95134
40-42 Quai du Point du Jour