doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2208.txt b/doc/rfc/rfc2208.txt
new file mode 100644
index 0000000..e01cc89
--- /dev/null
+++ b/doc/rfc/rfc2208.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                     A. Mankin, Ed.
+Request for Comments: 2208                                       USC/ISI
+Category: Informational                                         F. Baker
+                                                           Cisco Systems
+                                                               B. Braden
+                                                                 USC/ISI
+                                                              S. Bradner
+                                                                 Harvard
+                                                               M. O`Dell
+                                                      UUNET Technologies
+                                                              A. Romanow
+                                                        Sun Microsystems
+                                                              A. Weinrib
+                                                       Intel Corporation
+                                                                L. Zhang
+                                                                    UCLA
+                                                          September 1997
+
+
+                  Resource ReSerVation Protocol (RSVP)
+                   Version 1 Applicability Statement
+                     Some Guidelines on Deployment
+
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 1]
+
+RFC 2208           RSVP Applicability and Deployment      September 1997
+
+
+1.  Introduction
+
+   RSVP [RFC 2205] 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 [RFC 2211] and [RFC 2212] 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 [RFC 2210].
+
+   2. Router and host mechanisms (e.g. packet classification and
+      scheduling, admission control algorithms) to implement one or
+      both of the models [RFC 2211] and [RFC 2212], 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.
+
+   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
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 2]
+
+RFC 2208           RSVP Applicability and Deployment      September 1997
+
+
+   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.
+
+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
+   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 Considerations
+
+   The RSVP WG submission for Proposed Standard includes two security-
+   related documents [Baker96, RFC 2207]. [Baker96] addresses denial and
+   hijacking or theft of service attacks.  [RFC 2207] addresses RSVP
+   mechanisms for data flows that themselves use IPSEC.
+
+
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 3]
+
+RFC 2208           RSVP Applicability and Deployment      September 1997
+
+
+   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 [RFC 2206].
+
+   The Integrity object defined by [Baker96] may also play a role in
+   policy control, as will be described in 2.3.
+
+   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.
+
+
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 4]
+
+RFC 2208           RSVP Applicability and Deployment      September 1997
+
+
+   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
+   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.
+
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 5]
+
+RFC 2208           RSVP Applicability and Deployment      September 1997
+
+
+4.  References
+
+   [Baker96]  Baker, F., "RSVP Cryptographic Authentication", Work in
+           Progress.
+
+   [RFC 2206], Baker, F. and J. Krawczyk, "RSVP Management Information
+           Base", RFC 2206, September 1997.
+
+   [RFC 2207]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
+           Data Flows", RFC 2207, September 1997.
+
+   [RFC 2211] Wroclawski, J., "Specification of Controlled-Load
+           Network Element Service", RFC 2211, September 1997.
+
+   [RFC 2212] Shenker, S., C. Partridge and R. Guerin, "Specification
+           of Guaranteed Quality of Service", RFC 2212, September 1997.
+
+   [RFC 2205]  Braden, R. Ed. et al, "Resource ReserVation Protocol
+           -- Version 1 Functional Specification", RFC 2205,
+           September 1997.
+
+   [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
+           Services", RFC 2210, September 1997.
+
+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                 Allyn Romanow
+   Harvard University            Sun Microsystems
+   Phone: 617-495-3864           Phone: 415-786-5179
+   EMail: sob@harvard.edu        EMail: allyn@eng.sun.com
+
+   Michael O'Dell		 Allison Mankin	
+   UUNET Technologies		 mankin@east.isi.edu
+   Phone: 703-206-5471
+   EMail: mo@uu.net
+
+
+
+Mankin, Ed., et. al.         Informational                      [Page 6]
+