--- 1/draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt 2007-12-14 15:12:05.000000000 +0100 +++ 2/draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt 2007-12-14 15:12:05.000000000 +0100 @@ -1,23 +1,23 @@ TSVWG F. Le Faucheur Internet-Draft Cisco Intended status: Informational J. Manner -Expires: March 15, 2008 University of Helsinki +Expires: June 16, 2008 University of Helsinki D. Wing Cisco A. Guillou Neuf - September 12, 2007 + December 14, 2007 RSVP Proxy Approaches - draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt + draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The IETF Trust (2007). Abstract RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service required by certain flows. With conventional RSVP, both the data @@ -721,21 +721,23 @@ Application Entity may be the signaling component of the SBC. This RSVP Proxy approach does not require any extension to the RSVP protocol. However, it relies on an RSVP Proxy control interface allowing control of the RSVP Proxy by an application signaling entity. This RSVP Proxy control interface is beyond the scope of the present document. Candidate protocols for realizing such interface include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may rely on soft states or hard states. Clearly, when hard states are 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 awareness of which RSVP Receiver Proxy is on the path to which destination. However, in the particular cases where it does so reliably, we observe that the Application Entity could control the RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP reservations are used between those, instead of one reservation per flow. For example, these aggregate reservations could be of RSVP- AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type as specified in [RFC4860]. Such aggregate reservations could be used @@ -1078,23 +1080,25 @@ 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. To ensure the integrity of the associated reservation and admission control mechanisms, the 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. - [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key types, - key provisioning methods as well as their respective applicability. + RSVP messages and + replay.[I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key + 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 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 @@ -1139,48 +1143,49 @@ 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. 8. Informative References [I-D.behringer-tsvwg-rsvp-security-groupkeying] - Behringer, M. and F. Le Faucheur, "A Framework for RSVP - Security Using Dynamic Group Keying", July 2007. + Behringer, M. and F. Le Faucheur, "Applicability of Keying + Methods for RSVP Security", November 2007. [I-D.ietf-behave-rfc3489bis] - Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. - Wing, "Session Traversal Utilities for (NAT) (STUN)", - draft-ietf-behave-rfc3489bis-09 (work in progress), - August 2007. + Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for (NAT) (STUN)", + draft-ietf-behave-rfc3489bis-13 (work in progress), + November 2007. + + [I-D.ietf-dime-diameter-qos] + Zorn, G., "Protocol for Diameter Quality of Service + Application", November 2007. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) 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] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", April 2007. [I-D.ietf-tsvwg-rsvp-proxy-proto] - Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP - Receiver Proxy", February 2007. - - [I-D.ietf-tsvwg-vpn-signaled-preemption] - Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual - Private Network", February 2007. + Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., + and H. Malik, "RSVP Extensions For Path-Triggered RSVP + Receiver Proxy", December 2007. [I-D.manner-tsvwg-rsvp-proxy-sig] Manner, J., "Localized RSVP for Controlling RSVP Proxies", October 2006. [Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote Client and One-Pass Signalling", IWQoS Karlsruhe, Germany, 2006. [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated @@ -1210,30 +1215,34 @@ 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. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation 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 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. Davenport, "Generic Aggregate Resource ReSerVation 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 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks As broadband services for residential 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 @@ -1543,45 +1552,44 @@ 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 which is the most likely bottleneck, the wireless connectivity. 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 node movement. A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways - [I-D.ietf-tsvwg-vpn-signaled-preemption] 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 cyphertext 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 - cyphertext 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]. + [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 cyphertext 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 cyphertext 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 [I-D.ietf-tsvwg-vpn-signaled-preemption] 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. + 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 reservation presented in - [I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed. An - alternative approach to support resource reservations within the - cyphertext core is to use the "Application_Entity-Controlled Proxy" - approach (as defined in Section 4.5) in the following way: + approach for end-to-end reservation presented in [RFC4923] cannot be + deployed. An alternative approach to support resource reservations + within the cyphertext core is to use the "Application_Entity- + Controlled Proxy" approach (as defined in Section 4.5) in the + following way: o the RSVP Proxies are located inside the cyphertext 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 cyphertext domain via an RSVP Proxy control interface @@ -1655,22 +1663,21 @@ signaling device that controls an on-path RSVP Proxy function. However, in the present use case, the RSVP Proxies are a component of a cyphertext network where all user (bearer) traffic is IPsec encrypted. This has a number of implications including the following: 1. encrypted flows can not be identified in the cyphertext domain so that network nodes can only classify traffic based on IP address and DiffServ Code Points (DSCPs). As a result, only aggregate RSVP reservations (such as those specified in [RFC3175] or - [RFC4860] ) can be used. This is similar to - [I-D.ietf-tsvwg-vpn-signaled-preemption]. + [RFC4860] ) can be used. This is similar to [RFC4923]. 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