One document matched: draft-iesg-vendor-extensions-02.txt
Differences from draft-iesg-vendor-extensions-01.txt
INTERNET-DRAFT Scott O. Bradner
<draft-iesg-vendor-extensions-02.txt> Harvard University
Thomas Narten
IBM
June 4, 2004
Considerations on the Extensibility of IETF protocols
<draft-iesg-vendor-extensions-02.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document discusses issues related to the extensibility of IETF
protocols, including when it is reasonable to extend IETF protocols
with little or no review, and when extensions need to be reviewed by
the larger IETF community. Experience with IETF protocols has shown
that extensibility of protocols without IETF review can cause
problems. The document also recommends that major extensions to IETF
draft-iesg-vendor-extensions-02.txt [Page 1]
INTERNET-DRAFT June 4, 2004
protocols only take place through normal IETF processes or in
coordination with the IETF.
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Interoperability......................................... 3
3. Extensibility............................................ 4
3.1. Minor Extensions.................................... 5
3.2. Major Extensions.................................... 6
3.3. Classification of Major vs. Minor Extensions........ 6
4. Review of Proposed Protocol Extensions................... 7
5. Recommendation........................................... 7
6. Summary.................................................. 8
7. Examples................................................. 8
7.1. RADIUS Extensions................................... 9
7.2. RSVP Extensions..................................... 10
7.3. L2TP Extensions..................................... 10
8. IANA Considerations...................................... 11
9. Security Considerations.................................. 11
10. Acknowledgments......................................... 11
11. Informative References.................................. 11
12. Editor's Addresses...................................... 11
1. Introduction
When developing protocols, IETF working groups typically include
mechanisms whereby these protocols can be extended in the future.
Vendors, standards development organizations and technology fora have
used those facilities. Sometimes the result is a poorly designed
mechanism and non-interoperability.
It is of course a good principle to design extensiblity into
protocols; one common definition of a successful protocol is one that
draft-iesg-vendor-extensions-02.txt [Page 2]
INTERNET-DRAFT June 4, 2004
becomes widely used in ways not originally anticipated. Well-designed
extensibility mechanisms facilitate the evolution of protocols and
help make it easier to roll-out incremental changes in an
interoperable fashion. At the same time, experience has shown that
extensibility features should be limited to what is clearly necessary
when the protocol is developed and any later extensions should be
done carefully and with a full understanding of the base protocol,
existing implementations, and current operational practice.
If extensions to IETF protocols are done outside the IETF, experience
has shown that documentation of these extensions can be hard to
obtain, short-sighted design choices are sometimes made, basic
underlying architectural principals of the protocol are sometimes
violated, assessing the quality of the specification is hard and
achieving interoperability can be hard.
This memo makes explicit some guiding principles based on the
community's experience with extensibility mechanisms. One of the key
principles is that protocols should not be made more extensible than
clearly necessary at inception, and that proposed extensions should
be reviewed by subject-matter experts familiar with the protocol
itself and how it is used in currently deployed systems. The IESG is
presently applying some version of these principles in evaluating
proposals for new extensions and in evaluating the extensibility of
new protocols.
2. Interoperability
The importance of extending protocols only in carefully thought-out
ways is driven by the overall goal of acheiving good
interoperability. Good interoperability stems from a number of
factors, including:
- having a well-written spec, that makes clear and precise what an
implementor needs to implement and what impact each individual
operation (e.g., a message sent to a peer) will have when
invoked. However, while necessary, a well-written spec is not by
itself sufficient to result in good interoperability.
- learning lessons from deployment, including understanding what
current implementations do and how a proposed extension will
interact with deployed systems.
- having an adequate transition story for deploying the new
extension. What impact will the proposed extension have on
implementations that do not understand it? Is there a way to
negotiate or determine the capabilities of a peer?
draft-iesg-vendor-extensions-02.txt [Page 3]
INTERNET-DRAFT June 4, 2004
- being archtitecturally compatable with the base protocol. For
example, does the extension make use of features as envisioned
by the original protocol designers, or is a new mechanism being
invented?
- respecting underlying architectural or security assumptions
(including those that may not be well-documented, those that may
have arison as a result of operational experience, or those that
only became understood after the original protocol was
published).
- will the proposed extension (or its proposed usage)
operationally stress existing implementations or the underlying
protocol itself if widely deployed?
- some protocols have become critical components of the Internet
infrastructure. Does the proposed extension (or its proposed
usage) have the potential for negatively impacting such
infrastructure to the point where explicit steps would be
appropriate to firewall existing uses from new ones?
- does the proposed extension extend the data model in a major
way? Does the extension fundamentally change basic assumptions
about data handling within the protocol? For example, do the
extensions reverse the flow of data, allow formerly static
parameters to be changed on the fly, add new data types or
change assumptions relating to the frequency of reads/writes?
In practice, the only way to ensure that a proposed extension makes
sense and will result in good interoperability is to have the
extension reviewed by subject-matter experts familiar with the
technology.
Ideally, the document that defines a base protocol's extension
mechanisms will include guidance to future extension writers that
help them use extension mechanisms properly. It may also be possible
to define classes of extensions that need little or no review, while
other classes need wide review. The specific details will necessarily
be technology-specific.
3. Extensibility
The best defense against poorly thought-out extensions is review by
subject matter experts. Such experts can identify potential problems
early and suggest alternative approaches with fewer problems. To
improve interoperability, such review must take place before
significant deployment of an extension takes place. Once an extension
draft-iesg-vendor-extensions-02.txt [Page 4]
INTERNET-DRAFT June 4, 2004
is deployed and in use, it becomes difficult or impossible to
deprecate the extension or otherwise recall implementations.
Protocols that permit easy extensions with minimal or no review, make
it likely that unreviewed extensions will be deployed and used in
practice. Consequently, protocols should not be made more extensible
than clearly necessary at inception, and the process for defining new
extensibility mechanisms must ensure that adequate review of proposed
extensions will take place before widespread adoption. In practice,
this means First Come First Served [IANA-CONSID] and similar policies
should be used very carefully, as they imply minimal or no review.
3.1. Minor Extensions
The amount and type of review necessary for a proposed extension can
vary considerably. For example, many protocols are designed to carry
opaque data, without examining or acting on the data at all. For
example, DHCP [DHC] transports options, but the contents of an
individual option is generally of no concern to the DHCP protocol
itself. Many other protocols provide such a capability, including
OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc. A new
extension may be nothing more than having an existing protocol carry
a different kind of opaque data. In such cases, minimal review may be
adequate.. For the purposes of this document, we call such extensions
"Minor Extensions". Important points to note about Minor Extensions
include:
o The protocol is designed to carry such opaque data and no
changes to the underlying base protocol are needed to carry a
new type of data. Moreover, no changes are required to existing
and currently deployed implementations of the underlying
protocol unless they want to make use of the new data type.
o Using the existing protocol to carry a new type of opaque data
will not impact existing implementations or cause operational
problems.
Examples of minor extensions include the DHC vendor-specific option,
the enterprise OID tree for MIB modules, vnd. MIME types, and some
classes of (non-critical) certification extensions. Such extensions
can safely be made with minimal IETF coordination and are indicated
by having an IANA Considerations that allows assignments of code
points with minimal overhead (e.g., First Come First Served) [IANA-
CONSID].
In order to increase the likelyhood that minor extensions are truly
minor, protocol documents should provide guidelines explaining how
draft-iesg-vendor-extensions-02.txt [Page 5]
INTERNET-DRAFT June 4, 2004
they should be done. For example, even though DHCP carries opaque
data, defining a new option using completely unstructured data may
lead to an option that is (unnecessarily) hard for clients and
servers to process. In contrast, using widely-supported encoding
formats leads to better interoperability [XXX need ref]. Similarly,
SNMP MIB guidelines exist for defining the MIB objects that SNMP
carries [MIB-GUIDELINES].
3.2. Major Extensions
Some extensions change the protocol itself (e.g, the bits-on-the-
wire), change the interpretation of previously defined Protocol Data
Units (PDUs), or require protocol-specific changes in the client,
server, or other intermediate nodes. Such changes can be both subtle
and significant, and generally warrant careful review. Examples here
would include new protocol message types. For the purposes of this
document, we call such extensions Major Extensions.
Major extensions have some or all of the following characteristics:
o Change or extend the way in which the basic underlying protocol
works, e.g., by changing the semantics of existing PDUs or
defining new message types that require implementation changes
in existing and deployed implementations of the protocols, even
if they do not want to make use of the new functions or data
types.
o Change basic architectural assumptions about the protocol that
have been an assumed part of the protocol and its
implementations.
o Lead to new uses of the protocol in ways not originally intended
or investigated, potentially leading to operational and other
difficulties when deployed, even in cases where the "on-the-
wire" format has not changed. For example, the overall quantity
of traffic the protocol is expected to carry might go up
substantially, typical packet sizes may increase compared to
existing deployments, simple implementation algorithms that are
widely deployed may not scale sufficiently or otherwise be up to
the new task at hand, etc.
3.3. Classification of Major vs. Minor Extensions
Exactly what is considered to be a major extension and what is
considered normal usage will depend on the specific protocol and the
proposed extension at issue. Even for protocols designed to carry
draft-iesg-vendor-extensions-02.txt [Page 6]
INTERNET-DRAFT June 4, 2004
opaque data, whether a proposed usage qualifies as a major extension
may involve considerable debate. For example, RADIUS is designed to
carry AVPs and allow definition of new AVPs. But it is important
that such discussion involve the IETF community of experts
knowledgeable about the protocol's architecture and existing usage in
order to fully understand the implications of a proposed extension.
4. Review of Proposed Protocol Extensions
Major extensions to IETF protocols should be well, and publicly,
documented and reviewed by the IETF community to be sure that the
extension does not undermine basic assumptions and safeguards
designed into the protocol, such as security functions, or undermine
its architectural integrity.
5. Recommendation
The following principles are the main guiding principles concerning
extensions to IETF protocols:
o Extensibility features in IETF protocols should be limited to
providing just the amount of extensibility that is seen as
required. Protocols should not be extensible just for the sake
of being extensible.
o All major extensions to IETF protocols should be done with
adequate review by or direct involvement of the IETF.
o The decision on whether an extension is major or minor should be
done with the direct involvement of the IETF.
o Protocols should include IANA considerations section that ensure
that protocol code point assignments that are needed to deploy
extensions are not made until after a proposed extension has
received adequate review.
Ideally, extensions should be done by IETF working groups using
normal IETF processes or, if a working group does not consider a
proposed extension to be general enough, at least documented in an
IETF informational RFC that is reviewed by the working group and the
IESG. No individual, vendor, standards development organization or
forum should be able create what is viewed to be a major extension to
an IETF protocol on its own and be able to claim (or create the
appearance) that the extensions are part of the IETF protocol.
It should also be noted that the second bullet above leads to the
possibility of a denial-of-service issue, as it implies that any
draft-iesg-vendor-extensions-02.txt [Page 7]
INTERNET-DRAFT June 4, 2004
major extension must be done within or reviewed by the IETF, and that
the IETF is required to take on all such work. In practice, the IETF
may not have the resources to develop (or even review) every possible
extension and will need to prioritize the use of its resources. Thus,
it is important to be pragmatic in terms of what work can and will be
taken on by the IETF, and to set expectations accordingly. In those
cases where the IETF is unable to take on a particular work item, it
should be understood that the IETF will review extensions to its
technology that it is asked to publish, and may approve publication
only after changes are made, or may not agree to publish the
extension at all. Thus, anyone proposing extensions outside of the
IETF is advised to coordinate any such extensions with the IETF as
early as possible. Waiting until the last minute before consulting
with the IETF and then assuming quick publication of a finished
extension is not recommended.
It should also be noted that there are limits to what the IETF can do
to prevent others from improperly extending protocols outside of the
IETF. The IETF's leverage is limited to such actions as recommending
against publication of an extension or denying the assignment of an
IANA code point (e.g., when relevant IANA considerations guidelines
apply). There is also the real possibility that the development of a
poor extension will generate ill-will in the IETF community, which
can greatly complicate subsequent attempts by the offending group to
carry out future work in the IETF, whether directly related to the
particular extension or not.
6. Summary
IETF protocols should not be designed to encourage the definition of
major extensions outside the IETF process. Documents defining IETF
protocols should carefully analyze and identify which protocol
components can be extended safely with minimal or no community review
and which need community review, and then write appropriate IANA
considerations sections that ensure the appropriate level of
community review prior to the assignment of numbers. For example, the
definition of additional data formats that can be carried may require
no review, while the addition of new protocol message types might
require a Standards Track action [IANA-CONSID].
7. Examples
This section discusses some specific examples, as it is not always
immediately clear what constitutes a major extension.
[note: to be completed, are the following good and representative of
draft-iesg-vendor-extensions-02.txt [Page 8]
INTERNET-DRAFT June 4, 2004
some of the debates that have been had?]
7.1. RADIUS Extensions
The RADIUS [RFC2865] protocol was designed to be extensible via
addition of Attributes to a Data Dictionary on the server, without
requiring code changes. However, this extensibility model assumed
that Attributes would conform to a limited set of data types and that
vendor extensionns would be limited to use by vendors in situations
in which interoperability was not required. Recent developments have
stretched those assumptions.
[RFC2865] Section 6.2 defines a mechanism for Vendor-Specific
extensions (Attribute 26), and states that use:
"... should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of
RADIUS, where no interoperability is deemed useful."
However, in practice usage of Vendor-Specific Attributes (VSAs) has been
considerably broader than this; in particular, VSAs have been used by
SDOs to define their extensions to the RADIUS protocol.
This has caused a number of problems. Since the VSA mechanism was not
designed for interoperability, VSAs do not contain a "mandatory" bit.
As a result, RADIUS clients and servers may not know whether it is
safe to ignore unknown attributes. For example, [RFC2865] Section 5
states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
However, in the case where the VSAs pertain to security (e.g. Filters)
it may not be safe to ignore them, since [RFC2865] also states:
"A NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is
unable to offer ARAP service MUST NOT implement the RADIUS attributes
for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an
unavailable service as an access-reject instead."
Since it was not envisaged that multi-vendor VSA implementations
would need to interoperate, [RFC2865] does not define the data model
for VSAs, and allows multiple subattributes to be included within a
single Attribute of type 26. However, this enables VSAs to be
defined which would not be supportable by current implementations if
placed within the standard RADIUS attribute space. This has caused
draft-iesg-vendor-extensions-02.txt [Page 9]
INTERNET-DRAFT June 4, 2004
problems in standardizing widely deployed VSAs.
In addition to extending RADIUS by use of VSAs, SDOs have also
defined new values of the Service-Type attribute in order to create
new RADIUS commands. Since [RFC2865] defined Service-Type values as
being allocated First Come, First Served (FCFS), this essentially
enabled new RADIUS commands to be allocated without IETF review.
This oversight has since been fixed in [RFC3575].
7.2. RSVP Extensions
7.3. L2TP Extensions
L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs
having no semantics to the L2TP protocol itself. However, it should
be noted that L2TP message types are identified by a Message Type AVP
(Attribute Type 0) with specific AVP values indicating the actual
message type. Thus, extensions relating to Message Type AVPs would
likely be considered major extensions.
L2TP also provides for Vendor-Specific AVPs. Because everything in
L2TP is encoded using AVPs, it would be easy to define vendor-
specific AVPs that would be considered major extensions.
L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP
messages containing AVPs they do not understand but that have the
mandatory bit set, are expected to reject the message and terminate
the tunnel or session the message refers to. This leads to
interesting interoperability issues, because a sender can include a
vendor-specific AVP with the M-bit set, which then cause the
recipient to not interoperate with the sender. This sort of behavior
is counter to the IETF ideals, as implementations of the IETF
standard should interoperate successfully with other implementations
and not require the implementation of non-IETF extensions in order to
interoperate successfully. Section 4.2 of the L2TP specification
[L2TP] includes specific wording on this point, though there was
significant debate at the time as to whether such language was by
itself sufficient.
Fortunately, it does not appear that the above concerns have been a
problem in practice. At the time of this writing, the authors are
unaware of the existance of vendor-specific AVPs that also set the M-
bit.
draft-iesg-vendor-extensions-02.txt [Page 10]
INTERNET-DRAFT June 4, 2004
8. IANA Considerations
None.
9. Security Considerations
Insufficiently reviewed extensions can easily lead to protocols with
significant security vulnerabilities. In addition, a poorly designed
extension can circumvent strong security features that the IETF
designed into a protocol.
10. Acknowledgments
The initial version of this document was put together by the IESG in
2002. Since then, it has been reworked in response to feedback from
John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard
Aboba and others.
11. Informative References
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC
2661, August 1999.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[MIB-GUIDELINES] draft-ietf-ops-mib-review-guidelines-02.txt
[RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial
In User Service). B. Aboba. July 2003.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
12. Editor's Addresses
Scott Bradner
Harvard University
29 Oxford St
draft-iesg-vendor-extensions-02.txt [Page 11]
INTERNET-DRAFT June 4, 2004
Cambridge MA 02138
USA
Phone: +1 617-495-3864
EMail: sob@harvard.edu
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
draft-iesg-vendor-extensions-02.txt [Page 12]
INTERNET-DRAFT June 4, 2004
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
draft-iesg-vendor-extensions-02.txt [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-22 06:03:15 |