idnits 2.17.1 draft-ietf-rsvp-intsrv-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9904 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IntServ96a' is mentioned on line 79, but not defined == Missing Reference: 'IntServ96b' is mentioned on line 79, but not defined == Unused Reference: 'IntServ96' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'IntServ97' is defined on line 271, but no explicit reference was found in the text -- No information found for draft-rsvp-md5 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Baker96' == Outdated reference: A later version (-11) exists of draft-ietf-rsvp-mib-05 == Outdated reference: A later version (-08) exists of draft-berger-rsvp-ext-07 == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-14 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Allison Mankin, Editor 2 USC/ISI 3 Fred Baker 4 Cisco Systems 5 Bob Braden 6 USC/ISI 7 Scott Bradner 8 Harvard 9 Mike O`Dell 10 UUNET Technologies 11 Allyn Romanow 12 Sun Microsystems 13 Abel Weinrib 14 Intel Corporation 15 Lixia Zhang 16 UCLA 17 March 1997 18 Resource ReSerVation Protocol (RSVP) 20 Version 1 Applicability Statement 22 Some Guidelines on Deployment 24 26 Status of this Memo 28 This document is an Internet-Draft. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as ``work in progress.'' 38 To learn the current status of any Internet-Draft, please check the 39 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 40 Directories on ds.internic.net (US East Coast), nic.nordu.net 41 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 42 Rim). 44 Distribution of this memo is unlimited. 46 This Internet Draft expires September 1997. 48 Abstract 50 This document describes the applicability of RSVP along with the 51 Integrated Services protocols and other components of resource 52 reservation and offers guidelines for deployment of resource 53 reservation at this time. This document accompanies the first 54 submission of RSVP and integrated services specifications onto the 55 Internet standards track. 57 1. Introduction 59 RSVP [RSVPSpec96] is a unicast and multicast signalling protocol, 60 designed to install and maintain reservation state information at 61 each router along the path of a stream of data. The state handled by 62 RSVP is defined by services [IntServ96a] and [IntServ96b] specified 63 by the Integrated Services WG. These services and RSVP are being 64 introduced to the IETF's standards track jointly. From henceforth, 65 the acronym RSVP on its own is used as a shorthand for the signalling 66 protocol combined with the integrated service specifications. 68 RSVP must be used in conjunction with several additional components, 69 described in Table 1. 71 Table 1 Additional Components of Resource Reservation 73 1. Message formats in which parameters for desired services can be 74 expressed. A proposed standard set of these formats is specified 75 in [RSVPuse96]. 77 2. Router and host mechanisms (e.g. packet classification and 78 scheduling, admission control algorithms) to implement one or 79 both of the models [IntServ96a] and [IntServ96b], which are also 80 in the standards track. 82 3. Message formats in which parameters for desired policies for 83 admission control and resource use can be expressed. A small 84 common subset of these formats for standards track is in the 85 RSVP WG's charter. The Policy objects in the RSVP Protocol 86 Specification are optional only at this time. 88 4. Diversely located mechanisms implementing desired admission 89 control policy functions, including authorization and other 90 security mechanisms. 92 In the presence of some form of each component in Table 1, RSVP- 93 enabled applications can achieve differentiated qualities of service 94 across IP networks. Networked multimedia applications, many of which 95 require (or will benefit from) a predictable end-user experience, are 96 likely to be initial users of RSVP-signalled services. 98 Because RSVP and the integrated services and other components listed 99 in Table 1 mark a significant change to the service model of IP 100 networks, RSVP has received considerable interest and press in 101 advance of its release as a standards track RFC. At present, many 102 vendors of operating systems and routers are incorporating RSVP and 103 integrated services into their products for near-future availability. 104 The goal of this applicability statement is to describe those uses of 105 the current RSVP specification that are known to be feasible, and to 106 identify areas of limitation and ongoing chartered work addressing 107 some of these limitations. 109 2. Issues Affecting Deployment of RSVP 111 Wide scale deployment of RSVP must be approached with care, as there 112 remains a number of outstanding issues that may affect the success of 113 deployment. 115 Wide scale deployment of RSVP must be approached with care, as there 116 remains a number of outstanding issues that may affect the success of 117 deployment. 119 2.1. Scalability 121 The resource requirements (processing and storage) for running RSVP 122 on a router increase proportionally with the number of separate 123 sessions (i.e., RSVP reservations). Thus, supporting numerous small 124 reservations on a high-bandwidth link may easily overly tax the 125 routers and is inadvisable. Furthermore, implementing the packet 126 classification and scheduling capabilities currently used to provide 127 differentiated services for reserved flows may be very difficult for 128 some router products or on some of their high-speed interfaces (e.g. 129 OC-3 and above). 131 These scaling issues imply that it will generally not be appropriate 132 to deploy RSVP on high-bandwidth backbones at the present time. 133 Looking forward, the operators of such backbones will probably not 134 choose to naively implement RSVP for each separate stream. Rather, 135 techniques are being developed that will, at the "edge" of the 136 backbone, aggregate together the streams that require special 137 treatment. Within the backbone, various less costly approaches would 138 then be used to set aside resources for the aggregate as a whole, as 139 a way of meeting end-to-end requirements of individual flows. 141 In the near term, various vendors are likely to use diverse 142 approaches to the aggregation of reservations. There is not 143 currently chartered work in the IETF for development of standards in 144 this space. A BOF, Future Directions of Differential Services, on 145 April 7, 1997, at the Memphis IETF, is to consider the IETF's next 146 steps on this, among other issues. Public documentation of 147 aggregation techniques and experience is encouraged. 149 2.2. Security 151 The RSVP WG submission for Proposed Standard includes two security- 152 related documents [Baker96, Berger97]. [Baker96] addresses denial and 153 hijacking or theft of service attacks. [Berger97] addresses RSVP 154 mechanisms for data flows that themselves use IPSEC. 156 The first document is proposed to protect against spoofed reservation 157 requests arriving at RSVP routers; such requests might be used to 158 obtain service to unauthorized parties or to lock up network 159 resources in a denial of service attack. Modified and spoofed 160 reservation requests are detected by use of hop-by-hop MD5 checksums 161 (in an Integrity Object) between RSVP neighbor routers. As 162 described, RSVP hop-by-hop authentication assumes that key management 163 and distribution for routers is resolved and deployed. Until an 164 effective key infrastructure is in place, manually keyed session 165 integrity might be used. In addition, [Baker96] may be updated with 166 RFC 2085. 168 That RSVP needs an effective key infrastructure among routers is not 169 unique to RSVP: it is widely acknowledged that there are numerous 170 denial of service attacks on the routing infrastructure (quite 171 independent of RSVP) that will only be resolved by deployment of a 172 key infrastructure. 174 Theft of service risks will require the user to deploy with caution. 175 An elementary precaution is to configure management logging of new 176 and changed filter specifications in RSVP-enabled infrastructure, 177 e.g. the newFlow trap [Baker97]. 179 The Integrity object defined by [Baker96] may also play a role in 180 policy control, as will be described in 2.3. 182 The second security-related document provides a mechanism for 183 carrying flows in which the transport and user octets have been 184 encrypted (RFC 1827). Although such encryption is highly beneficial 185 to certain applications, it is not relevant to the functional 186 security of RSVP or reservations. 188 The following section on Policy Control includes additional 189 discussion of RSVP authorization security. 191 2.3. Policy Control 193 Policy control addresses the issue of who can, or cannot, make 194 reservations once a reservation protocol can be used to set up 195 unequal services. 197 Currently, the RSVP specification defines a mechanism for 198 transporting policy information along with reservations. However, 199 the specification does not define policies themselves. At present, 200 vendors have stated that they will use the RSVP-defined mechanism to 201 implement proprietary policies. There is active work on policy 202 architectures outside the IETF at this point [e.g. Herzog97]. 204 The RSVP WG is chartered to specify a simple standardized policy 205 object and complete simple mechanisms for session use of the 206 Integrity object in the near future. This applicability statement 207 may be updated at the completion of the WG's charter. 209 Before any decision to deploy RSVP, it would be wise to ensure that 210 the policy control available from a vendor is adequate for the 211 intended usage. In addition to the lack of documented policy 212 mechanisms in any of the policy areas (such as access control, 213 authorization, and accounting), the community has little experience 214 with describing, setting and controlling policies that limit Internet 215 service. Therefore it is likely that vendor solutions will be 216 revised often, particularly before the IETF has developed any policy 217 specification. 219 3. Recommendations 221 Given the current form of the RSVP specifications, multimedia 222 applications to be run within an intranet are likely to be the first 223 to benefit from RSVP. SNA/DLSW is another "application" considered 224 likely to benefit. Within the single or small number of related 225 administrative domains of an intranet, scalability, security and 226 access policy will be more manageable than in the global Internet, 227 and risk will be more controllable. Use of RSVP and supporting 228 components for small numbers of flows within a single Internet 229 Service Provider is similar to an intranet use. 231 Current experience with RSVP has been collected only from test runs 232 in limited testbeds and intranet deployment. We recommend that 233 people begin to use RSVP in production intranet or limited ISP 234 environments (as mentioned above), in which benefits can be realized 235 without having to resolve some of the issues described in Section 2. 236 To quote RFC 2026 about the use of Proposed Standard technology: 238 Implementors should treat Proposed Standards as immature 239 specifications. It is desirable to implement them in order to 240 gain experience and to validate, test, and clarify the 241 specification. However, since the content of Proposed Standards 242 may be changed if problems are found or better solutions are 243 identified, deploying implementations of such standards into a 244 disruption-sensitive environment is not recommended. 246 General issues of scalability, security and policy control as 247 outlined in Section 2 are the subjects of active research and 248 development, as are a number of topics beyond this applicability 249 statement, such as third-party setup of either reservations or 250 differentiated service. 252 4. References 254 [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in 255 Progress, RSVP Working Group, June 1996, draft-rsvp-md5- 256 02.txt 258 [Baker97], Baker, F. and J. Krawczyk, "RSVP Management Information 259 Base", Work in Progress, RSVP Working Group, January 1997, 260 draft-ietf-rsvp-mib-05.txt 262 [Berger97] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC 263 Data Flows", Work in Progress, RSVP Working Group, January 264 1997, draft-berger-rsvp-ext-07.txt 266 [IntServ96] Wroclawski, J., "Specification of Controlled-Load 267 Network Element Service", Work in Progress, Integrated 268 Services Working Group, November 1996, draft-ietf- 269 intserv-ctrl-load-svc-04.txt 271 [IntServ97] Shenker, S., C. Partridge and R. Guerin, "Specification 272 of Guaranteed Quality of Service", Work in Progress, 273 Integrated Services Working Group, February 1997, draft- 274 ietf-intserv-guaranteed-svc-07.txt 276 [RSVPSpec96] Braden, R. Ed. et al, "Resource ReserVation Protocol 277 -- Version 1 Functional Specification", Work in Progress, 278 RSVP Working Group, November 1996, draft-ietf-rsvp-spec- 279 14.txt 281 [RSVPuse96] Wroclawski, J., "The Use of RSVP with IETF Integrated 282 Services", Work in Progress, Integrated Services Working 283 Group, October 1996, draft-ietf-intserv-rsvp-use-01.txt. 285 5. Authors' Addresses 287 Fred Baker Abel Weinrib 288 Cisco Systems Intel Corporation 289 Phone: 408-526-4257 Phone: 503-264-8972 290 EMail: fred@cisco.com EMail: aweinrib@ibeam.intel.com 292 Bob Braden 293 USC/ISI Lixia Zhang 294 4676 Admiralty Way UCLA Computer Science Department 295 Marina Del Rey, CA 90292 4531G Boelter Hall 296 Phone: 310-822-1511 Los Angeles, CA 90095-1596 USA 297 EMail: braden@isi.edu Phone: 310-825-2695 298 EMail: lixia@cs.ucla.edu 299 Scott Bradner 300 Harvard University 301 Phone: 617-495-3864 302 EMail: sob@harvard.edu 304 Michael O'Dell 305 UUNET Technologies 306 Phone: 703-206-5471 307 EMail: mo@uu.net 309 Allyn Romanow 310 Sun Microsystems 311 Phone: 415-786-5179 312 EMail: allyn@eng.sun.com