draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt   draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt 
TSVWG F. Le Faucheur TSVWG F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational J. Manner Intended status: Informational J. Manner
Expires: March 15, 2008 University of Helsinki Expires: June 16, 2008 University of Helsinki
D. Wing D. Wing
Cisco Cisco
A. Guillou A. Guillou
Neuf Neuf
September 12, 2007 December 14, 2007
RSVP Proxy Approaches RSVP Proxy Approaches
draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 15, 2008. This Internet-Draft will expire on June 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
RSVP signaling can be used to make end-to-end resource reservations RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the Quality of Service in an IP network in order to guarantee the Quality of Service
required by certain flows. With conventional RSVP, both the data required by certain flows. With conventional RSVP, both the data
skipping to change at page 19, line 6 skipping to change at page 19, line 6
Application Entity may be the signaling component of the SBC. Application Entity may be the signaling component of the SBC.
This RSVP Proxy approach does not require any extension to the RSVP This RSVP Proxy approach does not require any extension to the RSVP
protocol. However, it relies on an RSVP Proxy control interface protocol. However, it relies on an RSVP Proxy control interface
allowing control of the RSVP Proxy by an application signaling allowing control of the RSVP Proxy by an application signaling
entity. This RSVP Proxy control interface is beyond the scope of the entity. This RSVP Proxy control interface is beyond the scope of the
present document. Candidate protocols for realizing such interface present document. Candidate protocols for realizing such interface
include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may
rely on soft states or hard states. Clearly, when hard states are rely on soft states or hard states. Clearly, when hard states are
used, those need to be converted appropriately by the RSVP Proxy used, those need to be converted appropriately by the RSVP Proxy
entities into the corresponding RSVP soft states. entities into the corresponding RSVP soft states. As an example,
[I-D.ietf-dime-diameter-qos] is intended to allow control of RSVP
Proxy via DIAMETER.
In general, the Application Entity is not expected to maintain In general, the Application Entity is not expected to maintain
awareness of which RSVP Receiver Proxy is on the path to which awareness of which RSVP Receiver Proxy is on the path to which
destination. However, in the particular cases where it does so destination. However, in the particular cases where it does so
reliably, we observe that the Application Entity could control the reliably, we observe that the Application Entity could control the
RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP
reservations are used between those, instead of one reservation per reservations are used between those, instead of one reservation per
flow. For example, these aggregate reservations could be of RSVP- flow. For example, these aggregate reservations could be of RSVP-
AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type
as specified in [RFC4860]. Such aggregate reservations could be used as specified in [RFC4860]. Such aggregate reservations could be used
skipping to change at page 27, line 33 skipping to change at page 27, line 33
5. Security Considerations 5. Security Considerations
In the environments of concern for this document, RSVP messages are In the environments of concern for this document, RSVP messages are
used to control resource reservations on a segment of the end-to-end used to control resource reservations on a segment of the end-to-end
path of flows. To ensure the integrity of the associated reservation path of flows. To ensure the integrity of the associated reservation
and admission control mechanisms, the cryptographic authentication and admission control mechanisms, the cryptographic authentication
mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those
protect RSVP messages integrity hop-by-hop and provide node protect RSVP messages integrity hop-by-hop and provide node
authentication, thereby protecting against corruption, spoofing of authentication, thereby protecting against corruption, spoofing of
RSVP messages and replay. RSVP messages and
[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key types, replay.[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key
key provisioning methods as well as their respective applicability. types and key provisioning methods as well as their respective
applicability to RSVP authentication mechanisms and to IPsec
protection (e.g. [RFC4303]) of RSVP.
A number of additional security considerations apply to the use of A number of additional security considerations apply to the use of
RSVP proxies and are discussed below. RSVP proxies and are discussed below.
With some RSVP Proxy approaches, the RSVP proxy operates autonomously With some RSVP Proxy approaches, the RSVP proxy operates autonomously
inside an RSVP router. This is the case for the Path-Triggered Proxy 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 approaches defined in Section 4.1 and in Section 4.2, for the
Inspection-Triggered Proxy approach defined in Section 4.3, 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 STUN-Triggered Proxy approach defined in Section 4.4 and for the
RSVP-Signaling-Triggered approach defined in Section 4.7. Proper RSVP-Signaling-Triggered approach defined in Section 4.7. Proper
skipping to change at page 28, line 47 skipping to change at page 29, line 4
This document benefited from earlier work on the concept of RSVP This document benefited from earlier work on the concept of RSVP
Proxy including the one documented by Silvano Gai, Dinesh Dutt, Proxy including the one documented by Silvano Gai, Dinesh Dutt,
Nitsan Elfassy and Yoram Bernet. It also benefited from discussions Nitsan Elfassy and Yoram Bernet. It also benefited from discussions
with Pratik Bose, Chris Christou and Michael Davenport. Tullio with Pratik Bose, Chris Christou and Michael Davenport. Tullio
Loffredo and Massimo Sassi provided the base material for Loffredo and Massimo Sassi provided the base material for
Section 4.6. Section 4.6.
8. Informative References 8. Informative References
[I-D.behringer-tsvwg-rsvp-security-groupkeying] [I-D.behringer-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Le Faucheur, "A Framework for RSVP Behringer, M. and F. Le Faucheur, "Applicability of Keying
Security Using Dynamic Group Keying", July 2007. Methods for RSVP Security", November 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Wing, "Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-09 (work in progress), draft-ietf-behave-rfc3489bis-13 (work in progress),
August 2007. November 2007.
[I-D.ietf-dime-diameter-qos]
Zorn, G., "Protocol for Diameter Quality of Service
Application", November 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-17 (work in progress), July 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sipping-sbc-funcs] [I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments", Initiation Protocol) Session Border Control Deployments",
April 2007. April 2007.
[I-D.ietf-tsvwg-rsvp-proxy-proto] [I-D.ietf-tsvwg-rsvp-proxy-proto]
Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A.,
Receiver Proxy", February 2007. and H. Malik, "RSVP Extensions For Path-Triggered RSVP
Receiver Proxy", December 2007.
[I-D.ietf-tsvwg-vpn-signaled-preemption]
Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual
Private Network", February 2007.
[I-D.manner-tsvwg-rsvp-proxy-sig] [I-D.manner-tsvwg-rsvp-proxy-sig]
Manner, J., "Localized RSVP for Controlling RSVP Proxies", Manner, J., "Localized RSVP for Controlling RSVP Proxies",
October 2006. October 2006.
[Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote [Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote
Client and One-Pass Signalling", IWQoS Karlsruhe, Germany, Client and One-Pass Signalling", IWQoS Karlsruhe, Germany,
2006. 2006.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
skipping to change at page 30, line 24 skipping to change at page 30, line 28
April 2001. April 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor,
"Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007. Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling
in a Nested Virtual Private Network", RFC 4923,
August 2007.
Appendix A. Use Cases for RSVP Proxies Appendix A. Use Cases for RSVP Proxies
A.1. RSVP-based VoD CAC in Broadband Aggregation Networks A.1. RSVP-based VoD CAC in Broadband Aggregation Networks
As broadband services for residential are becoming more and more As broadband services for residential are becoming more and more
prevalent, next generation aggregation networks are being deployed in prevalent, next generation aggregation networks are being deployed in
order to aggregate traffic from broadband users (whether attached via order to aggregate traffic from broadband users (whether attached via
Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb
aka FTTx, Cable or other broadband access technology). Video on aka FTTx, Cable or other broadband access technology). Video on
Demand (VoD) services which may be offered to broadband users present Demand (VoD) services which may be offered to broadband users present
skipping to change at page 39, line 9 skipping to change at page 39, line 9
access network will find the correct local access network node(s) to access network will find the correct local access network node(s) to
respond to the reservation. RSVP proxies would, thus, allow resource respond to the reservation. RSVP proxies would, thus, allow resource
reservation over the segment which is the most likely bottleneck, the reservation over the segment which is the most likely bottleneck, the
wireless connectivity. If the wireless access network uses a local wireless connectivity. If the wireless access network uses a local
mobility management mechanism, where the IP address of the mobile mobility management mechanism, where the IP address of the mobile
node does not change during handover, RSVP reservations would follow node does not change during handover, RSVP reservations would follow
the mobile node movement. the mobile node movement.
A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways
[I-D.ietf-tsvwg-vpn-signaled-preemption] discusses how resource [RFC4923] discusses how resource reservation can be supported end-to-
reservation can be supported end-to-end in a nested VPN environment. end in a nested VPN environment. At each VPN level, VPN Routers
At each VPN level, VPN Routers behave as [RFC4301] security gateways behave as [RFC4301] security gateways between a plaintext domain and
between a plaintext domain and a cyphertext domain. To achieve end- a cyphertext domain. To achieve end-to-end resource reservation, the
to-end resource reservation, the VPN Routers process RSVP signaling VPN Routers process RSVP signaling on the plaintext side, perform
on the plaintext side, perform aggregation of plaintext reservations, aggregation of plaintext reservations, and maintain the corresponding
and maintain the corresponding aggregate RSVP reservations on the aggregate RSVP reservations on the cyphertext side. Each aggregate
cyphertext side. Each aggregate reservation is established on behalf reservation is established on behalf of multiple encrypted end-to-end
of multiple encrypted end-to-end sessions sharing the same ingress sessions sharing the same ingress and egress VPN Routers. These
and egress VPN Routers. These aggregate reservations can be as aggregate reservations can be as specified in [RFC3175] or [RFC4860].
specified in [RFC3175] or [RFC4860].
Section 3 of [I-D.ietf-tsvwg-vpn-signaled-preemption] discusses the Section 3 of [RFC4923] discusses the necessary data flows within a
necessary data flows within a VPN Router to achieve the behavior VPN Router to achieve the behavior described in the previous
described in the previous paragraph. Two mechanisms are described to paragraph. Two mechanisms are described to achieve such data flows.
achieve such data flows. Section 3.1 presents the case where the VPN Section 3.1 presents the case where the VPN Router carries data
Router carries data across the cryptographic boundary. Section 3.2 across the cryptographic boundary. Section 3.2 discusses the case
discusses the case where the VPN router uses a Network-Guard. where the VPN router uses a Network-Guard.
Where such mechanisms are not supported by the VPN Routers, the Where such mechanisms are not supported by the VPN Routers, the
approach for end-to-end reservation presented in approach for end-to-end reservation presented in [RFC4923] cannot be
[I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed. An deployed. An alternative approach to support resource reservations
alternative approach to support resource reservations within the within the cyphertext core is to use the "Application_Entity-
cyphertext core is to use the "Application_Entity-Controlled Proxy" Controlled Proxy" approach (as defined in Section 4.5) in the
approach (as defined in Section 4.5) in the following way: following way:
o the RSVP Proxies are located inside the cyphertext domain and use o the RSVP Proxies are located inside the cyphertext domain and use
aggregate RSVP reservations, aggregate RSVP reservations,
o the Application Entity exchange application level signaling with o the Application Entity exchange application level signaling with
the end systems in the plaintext domain, the end systems in the plaintext domain,
o the Application Entity controls the RSVP Proxies in the cyphertext o the Application Entity controls the RSVP Proxies in the cyphertext
domain via an RSVP Proxy control interface domain via an RSVP Proxy control interface
skipping to change at page 41, line 32 skipping to change at page 41, line 32
signaling device that controls an on-path RSVP Proxy function. signaling device that controls an on-path RSVP Proxy function.
However, in the present use case, the RSVP Proxies are a component of However, in the present use case, the RSVP Proxies are a component of
a cyphertext network where all user (bearer) traffic is IPsec a cyphertext network where all user (bearer) traffic is IPsec
encrypted. This has a number of implications including the encrypted. This has a number of implications including the
following: following:
1. encrypted flows can not be identified in the cyphertext domain so 1. encrypted flows can not be identified in the cyphertext domain so
that network nodes can only classify traffic based on IP address that network nodes can only classify traffic based on IP address
and DiffServ Code Points (DSCPs). As a result, only aggregate and DiffServ Code Points (DSCPs). As a result, only aggregate
RSVP reservations (such as those specified in [RFC3175] or RSVP reservations (such as those specified in [RFC3175] or
[RFC4860] ) can be used. This is similar to [RFC4860] ) can be used. This is similar to [RFC4923].
[I-D.ietf-tsvwg-vpn-signaled-preemption].
2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be
used for aggregation of a given flow from sender to receiver used for aggregation of a given flow from sender to receiver
creates a number of challenges. Details on how this may be creates a number of challenges. Details on how this may be
achieved are beyond the scope of this document. We observe that, achieved are beyond the scope of this document. We observe that,
as illustrated in Figure 17, this may be facilitated by a network as illustrated in Figure 17, this may be facilitated by a network
management interface between the application entity and the IPsec management interface between the application entity and the IPsec
gateways. For example, this interface may be used by the gateways. For example, this interface may be used by the
application entity to obtain information about which IPsec application entity to obtain information about which IPsec
gateway is on the path of a given end-to-end flow. Then, the gateway is on the path of a given end-to-end flow. Then, the
 End of changes. 17 change blocks. 
48 lines changed or deleted 55 lines changed or added

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