idnits 2.17.1 draft-iesg-vendor-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 245 has weird spacing: '...llowing good...' -- 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 (October 27, 2003) is 7458 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: 'DHC' is mentioned on line 110, but not defined == Unused Reference: 'DHCP' is defined on line 309, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSID') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Scott O. Bradner 3 Harvard University 4 Thomas Narten 5 IBM 6 October 27, 2003 8 Considerations on the Extensibility of IETF protocols 10 12 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as work in progress. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document discusses issues related to the extensibility of IETF 35 protocols, including when it is reasonable to extend IETF protocols 36 with little or no review, and when extensions need to be reviewed by 37 the larger IETF community. The document also recommends that major 38 extensions to IETF protocols only take place through normal IETF 39 processes or in coordination with the IETF. 41 Contents 43 Status of this Memo.......................................... 1 45 1. Introduction............................................. 2 47 2. Principles............................................... 2 48 3. Recommendation........................................... 4 50 4. Examples................................................. 6 51 4.1. RADIUS Vendor-Specific Attributes................... 6 52 4.2. LDAP Schema Extensions.............................. 6 53 4.3. L2TP Extensions..................................... 6 55 5. IANA Considerations...................................... 7 57 6. Security Considerations.................................. 7 59 7. Acknowledgments.......................................... 7 61 8. Informative References................................... 7 63 9. Editor's Addresses....................................... 7 65 1. Introduction 67 When developing protocols, quite a few IETF working groups have made 68 facilities whereby these protocols can be extended in the future. 69 Vendors, other standards development organizations and technology 70 fora have used those facilities. Sometimes the result is non- 71 interoperability or poorly designed mechanisms. 73 The purpose of this memo is to make explicit some guiding principles 74 based on the community's experience with extensibility mechanisms. 75 One of the key principles is that protocols should not be made more 76 extensible than clearly necessary at inception. The IESG is 77 presently applying some version of these principles when evaluating 78 proposals for new standards. 80 2. Principles 82 The most important principle driving this memo, and in fact the IETF 83 as a whole is the principle of: 85 o IETF Standards are intended to encourage and enable multiple 86 implementers to build implementations of protocols that will 87 interoperate. 89 It is a good principle to design extensible protocols but 90 extensibility features should be limited to what is clearly necessary 91 when the protocol is developed and any later extensions should be 92 done carefully and with a full understanding of the base protocol, 93 existing implementations, and current operational practice. 95 If extensions to IETF protocols are done outside the IETF, experience 96 has shown that documentation of these extensions can be hard to 97 obtain, short-sighted design choices are sometimes made, basic 98 underlying architectural principals of the protocol are sometimes 99 violated, assessing the quality of the specification is hard, and 100 achieving interoperability can be hard. 102 It can be particularly difficult for a user to figure out who is at 103 fault and what to do about it if two pieces of software that both 104 claim to be implementations of an IETF standard do not work together. 106 Yet there are situations where extensions to IETF protocols can make 107 sense. There are two general ways in which protocols are extended. 108 Many (if not most) protocols are designed to carry opaque data of 109 some kind, where the protocol itself mostly doesn't care what the 110 contents of that data is. For example, DHCP [DHC] transports options, 111 but the contents of the option are generally of no concern to the 112 DHCP protocol itself. Many other protocols provide such a capability, 113 including OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc. 114 Important points to note about such extensions include: 116 o The protocol is designed to carry such opaque data and no 117 changes to the underlying base protocol are needed to carry a 118 new type of data. Specifically, no changes are required to 119 existing and currently deployed implementations unless they want 120 to make use of the new data type. 122 o Using the existing protocol to carry a new type of opaque data 123 will not impact existing implementations or cause operational 124 problems. 126 Examples of minor extensions include the DHC vendor-specific option, 127 the enterprise OID tree for MIB modules, vnd. MIME types, and some 128 classes of (non-critical) certification extensions. Such extensions 129 can safely be made with minimal IETF coordination and are indicated 130 by having an IANA Considerations that allows assignments of code 131 points with minimal overhead (e.g., first come first served) [IANA- 132 CONSID]. 134 The more interesting way in which protocols are extended is called a 135 major extension. Major extensions have some or all of the following 136 characteristics: 138 o Change or extend the way in which the basic underlying protocol 139 works, e.g., by changing the semantics of existing PDUs or 140 defining new message types that require implementation changes 141 in existing and deployed implementations of the protocols, even 142 if they do not want to make use of the new functions or data 143 types. 145 o Change basic architectural assumptions about the protocol that 146 have been an assumed part of the protocol and its 147 implementations. 149 o Lead to new uses of the protocol in ways not originally intended 150 or investigated, potentially leading to operational and other 151 difficulties when deployed, even in cases where the "on-the- 152 wire" format has not changed. For example, the overall quantity 153 of traffic the protocol is expected to carry might go up 154 substantially, typical packet sizes may increase compared to 155 existing deployments, simple implementation algorithms that are 156 widely deployed may not scale sufficiently or otherwise be up to 157 the new task at hand, etc. 159 Exactly what is considered to be a major extension and what is 160 considered normal usage will depend on the specific protocol and the 161 proposed extension at issue. Even for protocols designed to carry 162 opaque data, whether a proposed usage qualifies as a major extension 163 may involve considerable debate. But it is important that such 164 discussion involve the IETF community of experts knowledgeable about 165 the protocol's architecture and existing usage in order to fully 166 understand the implications of a proposed extension. 168 Major extensions should be well, and publicly, documented and 169 reviewed by the IETF community to be sure that the extension does not 170 undermine basic assumptions and safeguards designed into the 171 protocol, such as security functions, or undermine its architectural 172 integrity. 174 3. Recommendation 176 The following principles are the main guiding principles concerning 177 extensions to IETF protocols: 179 o Extensibility features in IETF protocols should be limited to 180 providing just the amount of extensibility that is seen as 181 required. Protocols should not be extensible just for the sake 182 of being extensible. 184 o All major extensions to IETF protocols should be done with 185 adequate review by or direct involvement of the IETF. 187 o The decision on whether an extension is major or minor should be 188 done with the direct involvement of the IETF. 190 Ideally, extensions should be done by IETF working groups using 191 normal IETF processes or, if a working group does not consider a 192 proposed extension to be general enough, at least documented in an 193 IETF informational RFC that is reviewed by the working group and the 194 IESG. No individual, vendor, standards development organization or 195 forum should be able create what is viewed to be a major extension to 196 an IETF protocol on its own and legitimately be able to claim that 197 implementations that implement the extension are compliant to the 198 IETF specification, or that the extension is a part of the IETF 199 specification. 201 It should be noted that the second bullet above leads to the 202 possibility of a denial-of-service issue, as it implies that any 203 major extension should be done within or reviewed by the IETF. At the 204 same time, the IETF may not have the resources to develop (or even 205 review) every possible extension and will need to prioritize the use 206 of its resources. Thus, it is important to be pragmatic in terms of 207 what work can and will be taken on by the IETF, and to set 208 expectations accordingly. In those cases where the IETF is unable to 209 take on a particular work item, it should be understood that the IETF 210 will review extensions to its technology that it is asked to publish, 211 and may approve publication only after changes are made, or may not 212 agree to publish the extension at all. Thus, anyone proposing 213 extensions outside of the IETF is advised to coordinate any such 214 extensions with the IETF as early as possible. Waiting until the last 215 minute before consulting with the IETF and then assuming quick 216 publication of a finished extension is not recommended. 218 It should also be noted that there are limits to what the IETF can do 219 to prevent others from improperly extending protocols outside of the 220 IETF. The IETF's leverage is limited to such actions as recommending 221 against publication of an extension or denying the assignment of an 222 IANA code point (e.g., when relevant IANA considerations guidelines 223 apply). There is also the real possibility that the development of a 224 poor extension will generate ill-will in the IETF community, which 225 can greatly complicate subsequent attempts by the offending group to 226 carry out future work in the IETF, whether directly related to the 227 particular extension or not. 229 IETF protocols should not be designed to encourage the definition of 230 major extensions outside the IETF process. IETF protocols should 231 carefully analyze and identify which protocol components can be 232 extended safely with minimal or no community review and which need 233 community review, and then write appropriate IANA considerations 234 sections that ensure the appropriate level of community review prior 235 to the assignment of numbers. For example, the definition of 236 additional data formats that can be carried may require no review, 237 while the addition of new protocol message types might require a 238 Standards Track action [IANA-CONSID]. 240 4. Examples 242 This section discusses some specific examples, as it is not always 243 immediately clear what constitutes a major extension. 245 [note: to be completed, are the following good and representative 246 of some of the debates that have been had?] 248 4.1. RADIUS Vendor-Specific Attributes 250 4.2. LDAP Schema Extensions 252 4.3. L2TP Extensions 254 L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs 255 having no semantics to the L2TP protocol itself. However, it should 256 be noted that L2TP message types are identified by a Message Type AVP 257 (Attribute Type 0) with specific AVP values indicating the actual 258 message type. Thus, extensions relating to Message Type AVPs would 259 likely be considered major extensions. 261 L2TP also provides for Vendor-Specific AVPs. Because everything in 262 L2TP is encoded using AVPs, it would be easy to define vendor- 263 specific AVPs that would be considered major extensions. 265 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 266 messages containing AVPs they do not understand but that have the 267 mandatory bit set, are expected to reject the message and terminate 268 the tunnel or session the message refers to. This leads to 269 interesting interoperability issues, because a sender can include a 270 vendor-specific AVP with the M-bit set, which then cause the 271 recipient to not interoperate with the sender. This sort of behavior 272 is counter to the IETF ideals, as implementations of the IETF 273 standard should interoperate successfully with other implementations 274 and not require the implementation of non-IETF extensions in order to 275 interoperate successfully. Section 4.2 of the L2TP specification 276 [L2TP] includes specific wording on this point, though there was 277 significant debate at the time as to whether such language was by 278 itself sufficient. 280 Fortunately, it does not appear that the above concerns have been a 281 problem in practice. At the time of this writing, the authors are 282 unaware of the existance of vendor-specific AVPs that also set the M- 283 bit. 285 5. IANA Considerations 287 None. 289 6. Security Considerations 291 Insufficiently reviewed extensions can easily lead to protocols with 292 significant security vulnerabilities. In addition, a poorly designed 293 extension can circumvent strong security features that the IETF 294 designed into a protocol. 296 7. Acknowledgments 298 The initial version of this document was put together by the IESG. 300 8. Informative References 302 [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing 303 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 304 October 1998. 306 [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 307 and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 308 2661, August 1999. 309 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 310 March 1997. 312 9. Editor's Addresses 314 Scott Bradner 315 Harvard University 316 29 Oxford St 317 Cambridge MA 02138 318 USA 320 Phone: +1 617-495-3864 321 EMail: sob@harvard.edu 323 Thomas Narten 324 IBM Corporation 325 P.O. Box 12195 326 Research Triangle Park, NC 27709-2195 327 USA 328 Phone: +1 919 254 7798 329 EMail: narten@us.ibm.com