INTERNET-DRAFT Allison Mankin, Editor USC/ISI Fred Baker Cisco Systems Bob Braden USC/ISI Scott Bradner Harvard Mike O`Dell UUNET Technologies Allyn Romanow Sun Microsystems Abel Weinrib Intel Corporation Lixia Zhang UCLA March 1997 Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. This Internet Draft expires September 1997. draft-ietf-rsvp-intsrv-analysis-00.txt [Page 1] INTERNET-DRAFT March 1997 Abstract This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto the Internet standards track. 1. Introduction RSVP [RSVPSpec96] is a unicast and multicast signalling protocol, designed to install and maintain reservation state information at each router along the path of a stream of data. The state handled by RSVP is defined by services [IntServ96a] and [IntServ96b] specified by the Integrated Services WG. These services and RSVP are being introduced to the IETF's standards track jointly. From henceforth, the acronym RSVP on its own is used as a shorthand for the signalling protocol combined with the integrated service specifications. RSVP must be used in conjunction with several additional components, described in Table 1. Table 1 Additional Components of Resource Reservation 1. Message formats in which parameters for desired services can be expressed. A proposed standard set of these formats is specified in [RSVPuse96]. 2. Router and host mechanisms (e.g. packet classification and scheduling, admission control algorithms) to implement one or both of the models [IntServ96a] and [IntServ96b], which are also in the standards track. 3. Message formats in which parameters for desired policies for admission control and resource use can be expressed. A small common subset of these formats for standards track is in the RSVP WG's charter. The Policy objects in the RSVP Protocol Specification are optional only at this time. 4. Diversely located mechanisms implementing desired admission control policy functions, including authorization and other security mechanisms. draft-ietf-rsvp-intsrv-analysis-00.txt [Page 2] INTERNET-DRAFT March 1997 In the presence of some form of each component in Table 1, RSVP- enabled applications can achieve differentiated qualities of service across IP networks. Networked multimedia applications, many of which require (or will benefit from) a predictable end-user experience, are likely to be initial users of RSVP-signalled services. Because RSVP and the integrated services and other components listed in Table 1 mark a significant change to the service model of IP networks, RSVP has received considerable interest and press in advance of its release as a standards track RFC. At present, many vendors of operating systems and routers are incorporating RSVP and integrated services into their products for near-future availability. The goal of this applicability statement is to describe those uses of the current RSVP specification that are known to be feasible, and to identify areas of limitation and ongoing chartered work addressing some of these limitations. 2. Issues Affecting Deployment of RSVP Wide scale deployment of RSVP must be approached with care, as there remains a number of outstanding issues that may affect the success of deployment. Wide scale deployment of RSVP must be approached with care, as there remains a number of outstanding issues that may affect the success of deployment. 2.1. Scalability The resource requirements (processing and storage) for running RSVP on a router increase proportionally with the number of separate sessions (i.e., RSVP reservations). Thus, supporting numerous small reservations on a high-bandwidth link may easily overly tax the routers and is inadvisable. Furthermore, implementing the packet classification and scheduling capabilities currently used to provide differentiated services for reserved flows may be very difficult for some router products or on some of their high-speed interfaces (e.g. OC-3 and above). These scaling issues imply that it will generally not be appropriate to deploy RSVP on high-bandwidth backbones at the present time. Looking forward, the operators of such backbones will probably not choose to naively implement RSVP for each separate stream. Rather, techniques are being developed that will, at the "edge" of the draft-ietf-rsvp-intsrv-analysis-00.txt [Page 3] INTERNET-DRAFT March 1997 backbone, aggregate together the streams that require special treatment. Within the backbone, various less costly approaches would then be used to set aside resources for the aggregate as a whole, as a way of meeting end-to-end requirements of individual flows. In the near term, various vendors are likely to use diverse approaches to the aggregation of reservations. There is not currently chartered work in the IETF for development of standards in this space. A BOF, Future Directions of Differential Services, on April 7, 1997, at the Memphis IETF, is to consider the IETF's next steps on this, among other issues. Public documentation of aggregation techniques and experience is encouraged. 2.2. Security The RSVP WG submission for Proposed Standard includes two security- related documents [Baker96, Berger97]. [Baker96] addresses denial and hijacking or theft of service attacks. [Berger97] addresses RSVP mechanisms for data flows that themselves use IPSEC. The first document is proposed to protect against spoofed reservation requests arriving at RSVP routers; such requests might be used to obtain service to unauthorized parties or to lock up network resources in a denial of service attack. Modified and spoofed reservation requests are detected by use of hop-by-hop MD5 checksums (in an Integrity Object) between RSVP neighbor routers. As described, RSVP hop-by-hop authentication assumes that key management and distribution for routers is resolved and deployed. Until an effective key infrastructure is in place, manually keyed session integrity might be used. In addition, [Baker96] may be updated with RFC 2085. That RSVP needs an effective key infrastructure among routers is not unique to RSVP: it is widely acknowledged that there are numerous denial of service attacks on the routing infrastructure (quite independent of RSVP) that will only be resolved by deployment of a key infrastructure. Theft of service risks will require the user to deploy with caution. An elementary precaution is to configure management logging of new and changed filter specifications in RSVP-enabled infrastructure, e.g. the newFlow trap [Baker97]. The Integrity object defined by [Baker96] may also play a role in policy control, as will be described in 2.3. draft-ietf-rsvp-intsrv-analysis-00.txt [Page 4] INTERNET-DRAFT March 1997 The second security-related document provides a mechanism for carrying flows in which the transport and user octets have been encrypted (RFC 1827). Although such encryption is highly beneficial to certain applications, it is not relevant to the functional security of RSVP or reservations. The following section on Policy Control includes additional discussion of RSVP authorization security. 2.3. Policy Control Policy control addresses the issue of who can, or cannot, make reservations once a reservation protocol can be used to set up unequal services. Currently, the RSVP specification defines a mechanism for transporting policy information along with reservations. However, the specification does not define policies themselves. At present, vendors have stated that they will use the RSVP-defined mechanism to implement proprietary policies. There is active work on policy architectures outside the IETF at this point [e.g. Herzog97]. The RSVP WG is chartered to specify a simple standardized policy object and complete simple mechanisms for session use of the Integrity object in the near future. This applicability statement may be updated at the completion of the WG's charter. Before any decision to deploy RSVP, it would be wise to ensure that the policy control available from a vendor is adequate for the intended usage. In addition to the lack of documented policy mechanisms in any of the policy areas (such as access control, authorization, and accounting), the community has little experience with describing, setting and controlling policies that limit Internet service. Therefore it is likely that vendor solutions will be revised often, particularly before the IETF has developed any policy specification. 3. Recommendations Given the current form of the RSVP specifications, multimedia applications to be run within an intranet are likely to be the first to benefit from RSVP. SNA/DLSW is another "application" considered likely to benefit. Within the single or small number of related administrative domains of an intranet, scalability, security and access policy will be more manageable than in the global Internet, and risk will be more controllable. Use of RSVP and supporting draft-ietf-rsvp-intsrv-analysis-00.txt [Page 5] INTERNET-DRAFT March 1997 components for small numbers of flows within a single Internet Service Provider is similar to an intranet use. Current experience with RSVP has been collected only from test runs in limited testbeds and intranet deployment. We recommend that people begin to use RSVP in production intranet or limited ISP environments (as mentioned above), in which benefits can be realized without having to resolve some of the issues described in Section 2. To quote RFC 2026 about the use of Proposed Standard technology: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. General issues of scalability, security and policy control as outlined in Section 2 are the subjects of active research and development, as are a number of topics beyond this applicability statement, such as third-party setup of either reservations or differentiated service. 4. References [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in Progress, RSVP Working Group, June 1996, draft-rsvp-md5- 02.txt [Baker97], Baker, F. and J. Krawczyk, "RSVP Management Information Base", Work in Progress, RSVP Working Group, January 1997, draft-ietf-rsvp-mib-05.txt [Berger97] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", Work in Progress, RSVP Working Group, January 1997, draft-berger-rsvp-ext-07.txt [IntServ96] Wroclawski, J., "Specification of Controlled-Load Network Element Service", Work in Progress, Integrated Services Working Group, November 1996, draft-ietf- intserv-ctrl-load-svc-04.txt draft-ietf-rsvp-intsrv-analysis-00.txt [Page 6] INTERNET-DRAFT March 1997 [IntServ97] Shenker, S., C. Partridge and R. Guerin, "Specification of Guaranteed Quality of Service", Work in Progress, Integrated Services Working Group, February 1997, draft- ietf-intserv-guaranteed-svc-07.txt [RSVPSpec96] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", Work in Progress, RSVP Working Group, November 1996, draft-ietf-rsvp-spec- 14.txt [RSVPuse96] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", Work in Progress, Integrated Services Working Group, October 1996, draft-ietf-intserv-rsvp-use-01.txt. 5. Authors' Addresses Fred Baker Abel Weinrib Cisco Systems Intel Corporation Phone: 408-526-4257 Phone: 503-264-8972 EMail: fred@cisco.com EMail: aweinrib@ibeam.intel.com Bob Braden USC/ISI Lixia Zhang 4676 Admiralty Way UCLA Computer Science Department Marina Del Rey, CA 90292 4531G Boelter Hall Phone: 310-822-1511 Los Angeles, CA 90095-1596 USA EMail: braden@isi.edu Phone: 310-825-2695 EMail: lixia@cs.ucla.edu Scott Bradner Harvard University Phone: 617-495-3864 EMail: sob@harvard.edu Michael O'Dell UUNET Technologies Phone: 703-206-5471 EMail: mo@uu.net Allyn Romanow Sun Microsystems Phone: 415-786-5179 EMail: allyn@eng.sun.com draft-ietf-rsvp-intsrv-analysis-00.txt [Page 7] INTERNET-DRAFT March 1997 draft-ietf-rsvp-intsrv-analysis-00.txt [Page 8]