Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
draft-ietf-rsvp-intsrv-analysis-00

INTERNET-DRAFT                                    Allison Mankin, Editor
                                                                 USC/ISI
<draft-ietf-rsvp-intsrv-analysis-00.txt>                      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

                 <draft-ietf-rsvp-intsrv-analysis-00.txt>

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]