< draft-carpenter-extension-recs-01.txt   draft-carpenter-extension-recs-02.txt >
Network Working Group B. Carpenter (ed) Network Working Group B. Carpenter (ed)
Internet-Draft IBM Internet-Draft IBM
Intended status: Informational March 3, 2007 Intended Status: Informational B. Aboba
Expires: September 4, 2007 Expires: December 25, 2007 Microsoft Corporation
12 June 2007
Design considerations for protocol extensions
draft-carpenter-extension-recs-01
Status of this Memo Design Considerations for Protocol Extensions
draft-carpenter-extension-recs-02
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on December 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document discusses issues related to the extensibility of This document discusses issues related to the extensibility of
Internet protocols, with a focus on the architectural design Internet protocols, with a focus on the architectural design
considerations involved. Concrete case study examples are included. considerations involved. Concrete case study examples are included.
It is intended to assist designers of both base protocols and It is intended to assist designers of both base protocols and
extensions. extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architectural Principles . . . . . . . . . . . . . . . . . . . 3
3. Specific Considerations for Robust Extensions . . . . . . . . 5 2.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 4
3.1. Checklist for Interoperability of Extensions . . . . . . . 5 2.2 Global Interoperability . . . . . . . . . . . . . . . . . 4
3.2. Use of Registered Values . . . . . . . . . . . . . . . . . 6 2.3 Protocol Variations . . . . . . . . . . . . . . . . . . . 5
3.3. When is an Extension Routine? . . . . . . . . . . . . . . 6 2.4 Extension Documentation . . . . . . . . . . . . . . . . . 5
3.4. Specific Issues with Major Extensions . . . . . . . . . . 7 2.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 6
4. Considerations for the Base Protocol . . . . . . . . . . . . . 7 2.6 Parameter Registration . . . . . . . . . . . . . . . . . . 6
4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 8 2.7 Extensions to Critical Infrastructure . . . . . . . . . . 7
4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 8 2.8 Architectural Compatibility . . . . . . . . . . . . . . . 7
4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 9 3. Specific Considerations for Robust Extensions . . . . . . . . 8
4.4. Avoiding Unnecessary Extensibility . . . . . . . . . . . . 9 3.1. Checklist for Interoperability of Extensions . . . . . . . 8
4.5. Documenting Extensibility . . . . . . . . . . . . . . . . 9 3.2. When is an Extension Routine? . . . . . . . . . . . . . . 9
5. Running Code Must Run Right . . . . . . . . . . . . . . . . . 10 3.3. What Constitutes a Major Extension? . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Considerations for the Base Protocol . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 12
9. Change log [RFC Editor: please remove this section] . . . . . 11 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Already documented cases . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 16 A.1. Already documented cases . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 17
A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 19
Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
For the origins of this draft, please see the Acknowledgements
section. Authorship will be updated.
When an initial protocol design is extended, there is always a risk
of introducing interoperability defects, security defects, etc.,
along with the additional functionality. This risk is especially
high if the extension is performed by a different team than the
original designers, who may stray outside implicit design constraints
or assumptions. This document aims to describe technical
considerations for protocol extensions that will minimize such risks.
Although written in general terms, it is largely aimed at people
considering extending an IETF protocol.
This document is intended to be technical. Formal procedures for
extending IETF protocols are discussed in BCP 125 [RFC4775].
IETF protocols typically include mechanisms whereby they can be IETF protocols typically include mechanisms whereby they can be
extended in the future. It is of course a good principle to design extended in the future. It is of course a good principle to design
extensiblity into protocols; one common definition of a successful extensibility into protocols; one common definition of a successful
protocol is one that becomes widely used in ways not originally protocol is one that becomes widely used in ways not originally
anticipated. Well-designed extensibility mechanisms facilitate the anticipated. Well-designed extensibility mechanisms facilitate the
evolution of protocols and help make it easier to roll out evolution of protocols and help make it easier to roll out
incremental changes in an interoperable fashion. At the same time, incremental changes in an interoperable fashion.
experience suggests that extensibility features should be limited to
what is clearly necessary when the protocol is developed and that any When an initial protocol design is extended, there is always a risk
later extensions should be done carefully and with a full of unintended consequences, such as interoperability problems or
understanding of the base protocol, existing implementations, and security vulnerabilities. This risk is especially high if the
current operational practice. extension is performed by a different team than the original
designers, who may stray outside implicit design constraints or
assumptions. As a result, extensions should be done carefully and
with a full understanding of the base protocol, existing
implementations, and current operational practice.
This is hardly a recent concern. "TCP Extensions Considered Harmful" This is hardly a recent concern. "TCP Extensions Considered Harmful"
[RFC1263] was published in 1991. "Extend" or "extension" occurs in [RFC1263] was published in 1991. "Extend" or "extension" occurs in
the title of more than 300 existing RFCs. Yet generic extension the title of more than 300 existing RFCs. Yet generic extension
considerations have not been documented previously. considerations have not been documented previously.
This document is intended to to assist designers of both base This document describes technical considerations for protocol
protocols and extensions. A good extension design depends on a good extensions, in order to minimize such risks. It is intended to
base protocol. Although Section 3 is aimed principally at extension assist designers of both base protocols and extensions. Formal
designers, and Section 4 at base protocol designers, readers are procedures for extending IETF protocols are discussed in BCP 125
advised to study the whole document, since the two sets of [RFC4775].
Section 2 describes architectural principles for protocol
extensibility. Section 3 is aimed principally at extension
designers, and Section 4 at base protocol designers. Nevertheless,
readers are advised to study the whole document, since the
considerations are closely linked. considerations are closely linked.
2. Interoperability 2. Architectural Principles
This Section describes basic principles of protocol extensibility:
1. Extensibility features should be limited to what is clearly
necessary when the protocol is developed.
2. Protocol extensions should be designed for global
interoperability.
3. Protocol extension mechanisms should not be used to create
incompatible protocol variations.
4. Extension mechanisms need to be fully documented.
5. Extension mechanisms need to be testable.
6. Protocol parameters should be registered and used for their
intended purpose.
7. Extensions to critical infrastructure should not impact the
security or reliability of the global Internet.
8. Extension mechanisms should be explicitly identified and should be
architecturally compatible with the base protocol design.
2.1. Limited Extensibility
Protocols that permit easy extensions may have the perverse side
effect of making it easy to construct incompatible extensions.
Consequently, protocols should not be made more extensible than
clearly necessary at inception, and the process for defining new
extensibility mechanisms should ensure that adequate review of
proposed extensions will take place before widespread adoption. In
practice, this means First Come First Served [RFC2434] and similar
policies that allow routine extensions should be used sparingly, as
they imply minimal or no review. In particular, they should be
limited to cases, such as allowing new opaque data elements, that are
unlikely to cause protocol failures.
In order to increase the likelihood that routine extensions are truly
routine, protocol documents should provide guidelines explaining how
they should be performed. 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.
2.2. Global Interoperability
Global interoperability is a primary goal of IETF protocol design. Global interoperability is a primary goal of IETF protocol design.
Experience shows that software is often used outside the particular Experience shows that software is often used outside the particular
special environment it was originally intended for, so extensions special environment it was originally intended for, so extensions
cannot be designed for an isolated environment. Designers of cannot be designed for an isolated environment. Designers of
extensions must assume the high likelihood of a system using the extensions must assume the high likelihood of a system using the
extension having to interoperate with systems on the global Internet. extension having to interoperate with systems on the global Internet.
For this reason, an extension may lead to interoperability failures For this reason, an extension may lead to interoperability failures
unless the extended protocol correctly supports all mandatory and unless the extended protocol correctly supports all mandatory and
optional features of the unextended base protocol, and optional features of the unextended base protocol, and
implementations of the base protocol operate correctly in the implementations of the base protocol operate correctly in the
presence of the extensions. Consider for example a "private" presence of the extensions.
extension installed on a work computer which, being portable, is
sometimes installed on a home network or in a hotel. If the
"private" extension is incompatible with an unextended version of the
same protocol, problems will occur.
Another aspect is that that mechanisms included to allow the Consider for example a "private" extension installed on a work
extension of protocols should not be used to create incompatible computer which, being portable, is sometimes installed on a home
forks in development instead. Ideally, the protocol mechanisms for network or in a hotel. If the "private" extension is incompatible
extension and versioning should be sufficiently well described that with an unextended version of the same protocol, problems will occur.
compatibility can be assessed on paper. Otherwise, when two
"private" extensions encounter each other on a public network, 2.3. Protocol Variations
unexpected interoperability problems may occur.
Protocol extension mechanisms should not be used to create
incompatible forks in development instead. Ideally, the protocol
mechanisms for extension and versioning should be sufficiently well
described that compatibility can be assessed on paper. Otherwise,
when two "private" extensions encounter each other on a public
network, unexpected interoperability problems may occur.
An example of what might go wrong is misuse of the X- mail headers An example of what might go wrong is misuse of the X- mail headers
originally defined in SMTP [RFC0822]. X-anything was a valid mail originally defined in SMTP [RFC0822]. X-anything was a valid mail
header; but it had no defined meaning in the standard. Suppose a header; but it had no defined meaning in the standard. Suppose a
mail implementation assigns specifc semantics to X-anything that mail implementation assigns specific semantics to X-anything that
causes it to take specific action, such as discarding a message as causes it to take specific action, such as discarding a message as
spam. If it encounters a message from a different implementation spam. If it encounters a message from a different implementation
that assigns different semantics, it may take quite inappropriate that assigns different semantics, it may take quite inappropriate
action, such as discarding a valid message. Thus, relying on the action, such as discarding a valid message. Thus, relying on the
implied semantics of an X- header automatically creates a risk of implied semantics of an X- header automatically creates a risk of
operational failures. X- headers were removed from [RFC2822]. Even operational failures. X- headers were removed from [RFC2822]. Even
when they are assigned semantics, as in [RFC4356], great care must be when they are assigned semantics, as in [RFC4356], great care must be
taken that implementations do not rely on such semantics in messages taken that implementations do not rely on such semantics in messages
that have crossed the open Internet. that have crossed the open Internet.
Thus we observe that a key requirement for interoperable extension Thus we observe that a key requirement for interoperable extension
design is that the base protocol must be well designed for design is that the base protocol must be well designed for
interoperability, and that extensions must have unambiguous interoperability, and that extensions must have unambiguous
semantics. semantics.
Additionally, it should be noted that protocol variations - Protocol variations - specifications that look very similar to the
specifications that look very similar to the original but are original but are actually different - are even more harmful to
actually different - are even more harmful to interoperability than interoperability than extensions. In general, such variations should
extensions. In general, such variations should be avoided. If they be avoided. If they cannot be avoided, as many of the following
cannot be avoided, as many of the following considerations as considerations as possible should be applied, to minimize the damage
possible should be applied, to minimize the damage to to interoperability.
interoperability.
3. Specific Considerations for Robust Extensions 2.4. Extension Documentation
This section makes explicit some design considerations based on the Some protocol components are designed with the specific intention of
community's experience with extensibility mechanisms. allowing extensibility. These should be clearly identified, with
specific and complete instructions on how to extend them, including
the process for adequate review of extension proposals: do they need
community review and if so how much and by whom? For example, the
definition of additional data elements that can be carried opaquely
may require no review, while the addition of new data types or new
protocol messages might require a Standards Track action. Guidance
on writing appropriate IANA Considerations text may be found in
[RFC2434].
3.1. Checklist for Interoperability of Extensions In a number of cases, there is a need for explicit guidance relating
to extensions beyond what is encapsulated in the IANA considerations
section of the base specification. The usefulness of [RFC4181] would
appear to suggest that protocols whose data model is likely to be
widely extended (particularly using vendor-specific elements) need a
Design Guidelines document specifically addressing extensions.
Good interoperability stems from a number of factors, including: 2.5. Testability
1. 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.
2. learning lessons from deployment, including understanding what
current implementations do and how a proposed extension will
interact with deployed systems.
3. having an adequate transition or coexistence 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?
4. being architecturally compatible 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?
5. 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).
6. will the proposed extension (or its proposed usage) operationally
stress existing implementations or the underlying protocol itself
if widely deployed?
7. 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 isolate existing uses from new ones?
8. 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?
9. can the extended protocol negotiate with an unextended partner to
find a common subset of useful functions?
3.2. Use of Registered Values Experience shows that it is insufficient to correctly specify
extensibility and backwards compatibility in an RFC. It is also
important that implementations respect the compatibility mechanisms;
if not, non-interoperable pairs of implementations may arise. The
TLS case study shows how important this can be.
In order to determine whether protocol extension mechanisms have been
properly implemented, testing is required. However, for this to be
possible, test cases need to be developed. If a base protocol
document specifies extension mechanisms but does not utilize them or
provide examples, it may not be possible to develop test cases based
on the base protocol specification alone. As a result, base protocol
implementations may not be properly tested and non-compliant
extension behavior may not be detected until these implementations
are widely deployed.
To encourage correct implementation of extension mechanisms, base
protocol specifications should clearly articulate the expected
behavior of extension mechanisms and should include examples of
correct and incorrect extension behavior.
2.6. Parameter Registration
An extension is often likely to make use of additional values added An extension is often likely to make use of additional values added
to an existing IANA registry (in many cases, simply by adding a new to an existing IANA registry (in many cases, simply by adding a new
"TLV" (type-length-value) field). To avoid conflicting usage of the "TLV" (type-length-value) field). To avoid conflicting usage of the
same value, it is essential that all new values are properly same value, it is essential that all new values are properly
registered by the applicable procedures. See BCP 26, [RFC2434] for registered by the applicable procedures. See BCP 26, [RFC2434] for
the general rules, and individual protocol RFCs, and the IANA web the general rules, and individual protocol RFCs, and the IANA web
site, for specfic rules and registries. If this is not done, there site, for specific rules and registries. If this is not done, there
is nothing to prevent two different extensions picking the same is nothing to prevent two different extensions picking the same
value. When these two extensions "meet" each other on the Internet, value. When these two extensions "meet" each other on the Internet,
failure is inevitable. failure is inevitable.
A surprisingly common case of this is misappropriation of assigned A surprisingly common case of this is misappropriation of assigned
TCP (or UDP) registered port numbers. This can lead to a client for TCP (or UDP) registered port numbers. This can lead to a client for
one service attempting to communicate with a server for another one service attempting to communicate with a server for another
service. Numerous cases could be cited, but not without embarassing service. Numerous cases could be cited, but not without embarrassing
specific implementors. specific implementors.
In some cases, it may be appropriate to use values designated as In some cases, it may be appropriate to use values designated as
"experimental" or "local use" in early implementations of an "experimental" or "local use" in early implementations of an
extension. For example, [RFC4727] discusses experimental values for extension. For example, [RFC4727] discusses experimental values for
IP and transport headers, and [RFC2474] defines experimental/local IP and transport headers, and [RFC2474] defines experimental/local
use ranges for differentiated services code points. Such values use ranges for differentiated services code points. Such values
should be used with care and only for their stated purpose: should be used with care and only for their stated purpose:
experiments and local use. They are unsuitable for Internet-wide experiments and local use. They are unsuitable for Internet-wide
use, since they may be used for conflicting purposes and thereby use, since they may be used for conflicting purposes and thereby
cause interoperability failures. Packets containing experimental or cause interoperability failures. Packets containing experimental or
local use values must not be allowed out of the domain in which they local use values must not be allowed out of the domain in which they
are meaningful. are meaningful.
3.3. When is an Extension Routine? 2.7. Extensions to Critical Infrastructure
An extension may be considered relatively routine if it basically Some protocols (such as DNS and BGP) have become critical components
amounts to a new data element that is opaque to the protocol itself of the Internet infrastructure. When such protocols are extended,
(i.e. does not substantially change the pattern of messages and the potential exists for negatively impacting the reliability and
responses). security of the global Internet.
For this to apply, the protocol must have been designed to carry As a result, special care needs to be taken with these extensions,
opaque data elements, so that no changes to the underlying base such as taking explicit steps to isolate existing uses from new ones.
protocol are needed to carry a new type of data. Moreover, no For example, this can be accomplished by requiring the extension to
changes are required to existing and currently deployed utilize a different port or multicast address, or by implementing the
extension within a separate process, without access to the data and
control structures of the base protocol.
2.8. Architectural Compatibility
Since protocol extension mechanisms may impact interoperability, it
is important that these mechanisms be architecturally compatible with
the base protocol. This implies that documents relying on extension
mechanisms need to explicitly identify them, rather than burying them
in the text in the hope that they will escape notice.
As part of the definition of new extension mechanisms, the authors
need to address whether the mechanisms make use of features as
envisaged by the original protocol designers, or whether a new
extension mechanism is being invented. If a new extension mechanism
is being invented, then architectural compatibility issues need to be
addressed.
For example, a document defining new data elements should not
implicitly define new data types or protocol operations without
explicitly describing those dependencies and discussing their impact.
3. Specific Considerations for Robust Extensions
This section makes explicit some design considerations based on the
community's experience with extensibility mechanisms.
3.1. Interoperability Checklist
Good interoperability stems from a number of factors, including:
1. Having a well-written specification. Does the specification
make clear what an implementor needs to support and does it define
the impact that individual operations (e.g. a message sent to a
peer) will have when invoked?
2. Learning lessons from deployment. This includes understanding
what current implementations do and how a proposed extension will
interact with deployed systems. Will a proposed extension (or its
proposed usage) operationally stress existing implementations or
the underlying protocol itself if widely deployed?
3. Having an adequate transition or coexistence story. 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? Can the extended protocol negotiate with
an unextended partner to find a common subset of useful functions?
4. Respecting underlying architectural or security assumptions.
This includes assumptions that may not be well-documented, those
that may have arisen as the result of operational experience, or
those that only became understood after the original protocol was
published. For example, do the extensions reverse the flow of
data, allow formerly static parameters to be changed on the fly,
or change assumptions relating to the frequency of reads/writes?
5. Minimizing impact on critical infrastructure. Does the
proposed extension (or its proposed usage) have the potential for
negatively impacting critical infrastructure to the point where
explicit steps would be appropriate to isolate existing uses from
new ones?
6. Data model extensions. Does the proposed extension extend the
data model in a major way? For example, are new data types
defined that may require code changes within existing
implementations?
3.2. When is an Extension Routine?
An extension may be considered routine if it amounts to a new data
element of a type that is already supported within the data model,
and if its handling is opaque to the protocol itself (e.g. does not
substantially change the pattern of messages and responses).
For this to apply, the protocol must have been designed to carry the
proposed data type, so that no changes to the underlying base
protocol or existing implementations are needed to carry the new data
element.
Moreover, no changes are required to existing and currently deployed
implementations of the underlying protocol unless they want to make implementations of the underlying protocol unless they want to make
use of the new data type. Using the existing protocol to carry a new use of the new data element. Using the existing protocol to carry a
type of opaque data should not impact existing implementations or new data element should not impact existing implementations or cause
cause operational problems. Typically this means that the protocol operational problems. This typically requires that the protocol
is specified to silently discard unknown data elements. silently discard unknown data elements.
Examples of routine extensions include the DHC vendor-specific Examples of routine extensions include the DHC vendor-specific
option, the enterprise OID tree for MIB modules, vendor MIME types, option, RADIUS Vendor-Specific Attributes compliant with [RFC2865],
and some classes of (non-critical) certification extensions. Such the enterprise OID tree for MIB modules, vendor MIME types, and some
extensions can safely be made with minimal discussion and are usually classes of (non-critical) certification extensions. Such extensions
indicated by having IANA Considerations that allow assignments of can safely be made with minimal discussion.
code points with minimal overhead (e.g., First Come First Served)
[RFC2434].
3.4. Specific Issues with Major Extensions 3.3. What Constitutes a Major Extension?
Major extensions may have some or all of the following Major extensions may have characteristics leading to a risk of
characteristics, each of which leads to a risk of interoperability interoperability failure. Where these characteristics are present,
failure: it is necessary to pay extremely close attention to backward
1. Change or extend the way in which the basic underlying protocol compatibility with implementations and deployments of the unextended
works, e.g., by changing the semantics of existing PDUs or protocol, and to the risk of inadvertent introduction of security or
defining new message types that may require implementation operational exposures. Extension designers should examine their
changes in existing and deployed implementations of the design for the following issues:
protocols, even if they do not want to make use of the new
functions or data types. (Note that a base protocol without a
"silent discard" rule for unknown data elements may automatically
enter this category, even for apparently minor extensions.)
2. Change basic architectural assumptions about the protocol that
have been an assumed part of the protocol and its
implementations. For example, add a requirement for session
state to a previously stateless protocol.
3. 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. A specific example would be a new DNS
RR type that is too big to fit into a single UDP packet.
Each of these leads directly to a need to pay extremely close 1. Modifications or extensions to the working of the underlying
attention to backward compatibility with implementations and protocol. This can include changing the semantics of existing
deployments of the unextended protocol, and to the risk of PDUs or defining new message types that may require implementation
inadvertent introduction of security or operational exposures. changes in existing and deployed implementations of the protocol,
Extension designers should examine their design for the above three even if they do not want to make use of the new functions or data
issues. types. A base protocol without a "silent discard" rule for
unknown data elements may automatically enter this category, even
for apparently minor extensions.
2. Changes to the basic architectural assumptions. This includes
architectural assumptions that are explicitly stated or those that
have been assumed by implementers. For example, this would
include adding a requirement for session state to a previously
stateless protocol.
3. New usage scenarios not originally intended or investigated.
This can potentially lead to operational difficulties when
deployed, even in cases where the "on-the-wire" format has not
changed. For example, the level of traffic carried by the
protocol may increase substantially, packet sizes may increase,
and implementation algorithms that are widely deployed may not
scale sufficiently or otherwise be up to the new task at hand.
For example, a new DNS Resource Record (RR) type that is too big
to fit into a single UDP packet could cause interoperability
problems with existing DNS clients and servers.
4. Considerations for the Base Protocol 4. Considerations for the Base Protocol
Ideally, the document that defines a base protocol's extension A good extension design depends on a good base protocol. Ideally,
mechanisms will include guidance to future extension writers that the document that defines a base protocol's extension mechanisms will
help them use extension mechanisms properly. It may also be possible include guidance to future extension writers that help them use
to define classes of extensions that need little or no review, while extension mechanisms properly. It may also be possible to define
other classes need wide review. The details will necessarily be classes of extensions that need little or no review, while other
classes need wide review. The details will necessarily be
technology-specific. technology-specific.
4.1. Version Numbers 4.1. Version Numbers
Any mechanism for extension by versioning must include provisions to Any mechanism for extension by versioning must include provisions to
ensure interoperability, or at least clean failure modes. Imagine ensure interoperability, or at least clean failure modes. Imagine
someone creating a protocol and using a "version" field and someone creating a protocol and using a "version" field and
populating it with a value (1, let's say), but giving no information populating it with a value (1, let's say), but giving no information
about what would happen when a new version number appears in it. about what would happen when a new version number appears in it.
That's bad protocol design and description; it should be clear what That's bad protocol design and description; it should be clear what
the expectation is and how you test it. For example, stating that the expectation is and how you test it. For example, stating that
1.X must be compatible with any version 1 code, but version 2 or 1.X must be compatible with any version 1 code, but version 2 or
greater is not expected to be compatible, has different implications greater is not expected to be compatible, has different implications
than stating that version 1 must be a proper subset of version 2. than stating that version 1 must be a proper subset of version 2.
An interesting example here is ROHC (Robust Header Compression). An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095]
ROHCv1 [RFC3095] supports a certain set of profiles for compression supports a certain set of profiles for compression algorithms. But
algorithms. But experience has shown that these profiles have experience has shown that these profiles have limitations, so the
limitations, so the ROHC WG is developing ROHCv2. A ROHCv1 ROHC WG is developing ROHCv2. A ROHCv1 implementation will not
implementation will not contain code for the ROHCv2 profiles. As the contain code for the ROHCv2 profiles. As the ROHC WG charter said at
ROHC WG charter said at the time of writing: the time of writing:
...It should be noted that the v2 It should be noted that the v2 profiles will thus not be
profiles will thus not be compatible with the original (ROHCv1) compatible with the original (ROHCv1) profiles, which means less
profiles, which means less complex ROHC implementations can be complex ROHC implementations can be realized by not providing
realized by not providing support for ROHCv1 (over links not yet support for ROHCv1 (over links not yet supporting ROHC, or by
supporting ROHC, or by shifting out support for ROHCv1 in the long shifting out support for ROHCv1 in the long run). Profile support
run). Profile support is agreed through the ROHC channel negotiation, is agreed through the ROHC channel negotiation, which is part of
which is part of the ROHC framework and thus not changed by ROHCv2. the ROHC framework and thus not changed by ROHCv2.
Thus in this case both backwards-compatible and backwards- Thus in this case both backwards-compatible and backwards-
incompatible deployments are possible. The important point is a incompatible deployments are possible. The important point is a
clearly thought out approach to the question of operational clearly thought out approach to the question of operational
compatibility. compatibility. In the past, protocols have utilized a variety of
strategies for versioning, many of which have proven problematic.
These include:
1. No versioning support. This approach is exemplified by EAP
[RFC3748] as well as RADIUS [RFC2865], both of which provide no
support for versioning. While lack of versioning support protects
against the proliferation of incompatible dialects, the need for
extensibility is likely to assert itself in other ways, so that
ignoring versioning entirely may not be the most forward thinking
approach.
2. Highest mutually supported version. In this approach,
implementations exchange the highest supported version, with the
negotiation agreeing on the highest mutually supported protocol
version. This approach implicitly assumes that later versions
provide improved functionality, and that advertisement of a higher
version number implies support for lower versions. Where these
assumptions are invalid, this approach breaks down, potentially
resulting in interoperability problems. An example of this issue
occurs in [PEAP] where implementations of higher versions may not
necessarily provide support for lower versions.
3. Assumed backward compatibility. In this approach,
implementations may send packets with higher version numbers to
legacy implementations supporting lower versions, but with the
assumption that the legacy implementations will interpret packets
with higher version numbers using the semantics and syntax defined
for lower versions. This is the approach taken by [IEEE-802.1X].
For this approach to work, legacy implementations need to be able
to accept packets of known type with higher protocol versions
without discarding them; protocol enhancements need to permit
silent discard of unsupported extensions; implementations
supporting higher versions need to refrain from mandating new
features when encountering legacy implementations.
4. Major/minor versioning. In this approach, implementations with
the same major version but a different minor version are assumed
to be backward compatible, but implementations are assumed to be
required to negotiate a mutually supported major version number.
This approach assumes that implementations with a lower minor
version number but the same major version can safely ignore
unsupported protocol messages.
4.2. Reserved Fields 4.2. Reserved Fields
Protocols commonly include one or more "reserved" fields, clearly Protocols commonly include one or more "reserved" fields, clearly
intended for future extensions. It is good practice to specify the intended for future extensions. It is good practice to specify the
value to be inserted in such a field by the sender (typically zero) value to be inserted in such a field by the sender (typically zero)
and the action to be taken by the receiver when seeing some other and the action to be taken by the receiver when seeing some other
value (typically no action). If this is not done, future value (typically no action). If this is not done, future
implementation of new values in the reserved field may break old implementation of new values in the reserved field may break old
software. Similarly, protocols should carefully specify how software. Similarly, protocols should carefully specify how
skipping to change at page 9, line 18 skipping to change at page 12, line 30
Using widely-supported encoding formats leads to better Using widely-supported encoding formats leads to better
interoperability and easier extensibility. An excellent example is interoperability and easier extensibility. An excellent example is
the SNMP SMI. Guidelines exist for defining the MIB objects that the SNMP SMI. Guidelines exist for defining the MIB objects that
SNMP carries [RFC4181]. Also, multiple textual conventions have been SNMP carries [RFC4181]. Also, multiple textual conventions have been
published, so that MIB designers do not have to reinvent the wheel published, so that MIB designers do not have to reinvent the wheel
when they need a commonly encountered construct. For example, the when they need a commonly encountered construct. For example, the
"Textual Conventions for Internet Network Addresses" [RFC4001] can be "Textual Conventions for Internet Network Addresses" [RFC4001] can be
used by any MIB designer needing to define objects containing IP used by any MIB designer needing to define objects containing IP
addresses, thus ensuring consistency as the body of MIBs is extended. addresses, thus ensuring consistency as the body of MIBs is extended.
4.4. Avoiding Unnecessary Extensibility 5. Security Considerations
Protocols that permit easy extensions may have the perverse side
effect of making it easy to construct incompatible extensions.
Consequently, protocols should not be made more extensible than
clearly necessary at inception, and the process for defining new
extensibility mechanisms should ensure that adequate review of
proposed extensions will take place before widespread adoption. In
practice, this means First Come First Served [RFC2434] and similar
policies that allow routine extensions should be used sparingly, as
they imply minimal or no review. In particular, they should be
limited to cases, such as allowing new opaque data elements, that are
unlikely to cause protocol failures.
In order to increase the likelihood that routine extensions are truly
routine, protocol documents should provide guidelines explaining how
they should be performed. 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.
4.5. Documenting Extensibility
Some protocol components are designed with the specific intention of
allowing extensibility. These should be clearly identified, with
specific and complete instructions on how to extend them, including
the process for adequate review of extension proposals: do they need
community review and if so how much and by whom? For example, the
definition of additional data formats that can be carried opaquely
may require no review, while the addition of new protocol message
types might require a Standards Track action. Guidance on writing
appropriate IANA Considerations text may be found in [RFC2434].
In a number of cases, there is a need for explicit guidance relating
to extensions beyond what is encapsulated in the IANA considerations
section of the base specification. The usefulness of [RFC4181] would
appear to suggest that protocols whose data model is likely to be
widely extended (particularly using vendor-specific elements) need a
Design Guidelines document specifically addressing extensions.
5. Running Code Must Run Right
Experience shows that it is insufficient to correctly specify
extensibility and backwards compatibility in an RFC. It is also of
importance that every implementation must fully respect the
compatibility mechanisms; if not, non-interoperable pairs of
implementations may arise. The TLS case study below shows how
important this may be.
6. Security Considerations
An extension must not introduce new security risks without also An extension must not introduce new security risks without also
providing adequate counter-measures, and in particular it must not providing adequate counter-measures, and in particular it must not
inadvertently defeat security measures in the unextended protocol. inadvertently defeat security measures in the unextended protocol.
Thus, the security analysis for an extension needs to be as thorough Thus, the security analysis for an extension needs to be as thorough
as for the original protocol - effectively it needs to be a as for the original protocol - effectively it needs to be a
regression analysis to check that the extension doesn't inadvertently regression analysis to check that the extension doesn't inadvertently
invalidate the original security model. invalidate the original security model.
This analysis may be simple (e.g. adding an extra opaque data element This analysis may be simple (e.g. adding an extra opaque data element
is unlikely to create a new risk) or quite complex (e.g. adding a is unlikely to create a new risk) or quite complex (e.g. adding a
handshake to a previously stateless protocol may create a completely handshake to a previously stateless protocol may create a completely
new opportunity for an attacker). new opportunity for an attacker).
7. IANA Considerations 6. IANA Considerations
This draft requires no action by IANA. This draft requires no action by IANA.
8. Acknowledgements 7. Acknowledgments
This document is heavily based on an earlier draft under a different This document is heavily based on an earlier draft under a different
title by Scott Bradner and Thomas Narten. title by Scott Bradner and Thomas Narten.
That draft stated: The initial version of this document was put That draft stated: The initial version of this document was put
together by the IESG in 2002. Since then, it has been reworked in together by the IESG in 2002. Since then, it has been reworked in
response to feedback from John Loughney, Henrik Levkowetz, Mark response to feedback from John Loughney, Henrik Levkowetz, Mark
Townsley, Randy Bush, Bernard Aboba and others. Townsley, Randy Bush, Bernard Aboba and others.
Valuable comments and suggestions on the current form of the document Valuable comments and suggestions on the current form of the document
were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla,
Bernard Aboba, Pekka Savola, and Leslie Daigle. Pekka Savola, and Leslie Daigle.
The text on TLS experience was contributed by Yngve Pettersen. The text on TLS experience was contributed by Yngve Pettersen.
This document was produced using the xml2rfc tool [RFC2629]. 8. References
9. Change log [RFC Editor: please remove this section]
draft-carpenter-extension-recs-01: 2007-03-04. Updated according to
comments, especially the wording about TLS, added various specific
examples.
draft-carpenter-extension-recs-00: original version, 2006-10-12. 8.1. Normative References
Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by
focussing on architectural issues; the more procedural issues in that
draft were moved to RFC 4775.
10. References [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
text messages", STD 11, RFC 822, August 1982. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
IANA Considerations Section in RFCs", BCP 26, RFC 2434, "Definition of the Differentiated Services Field (DS
October 1998. Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC
"Definition of the Differentiated Services Field (DS 2671, August 1999.
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
RFC 2671, August 1999. 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
April 2001. H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
Header Compression (ROHC): Framework and four profiles:
RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, and B. Rosen, "Change Process for the Session Initiation
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Protocol (SIP)", BCP 67, RFC 3427, December 2002.
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
and B. Rosen, "Change Process for the Session Initiation J., and T. Wright, "Transport Layer Security (TLS)
Protocol (SIP)", BCP 67, RFC 3427, December 2002. Extensions", RFC 3546, June 2003.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
and T. Wright, "Transport Layer Security (TLS) Schoenwaelder, "Textual Conventions for Internet Network
Extensions", RFC 3546, June 2003. Addresses", RFC 4001, February 2005.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Procedures", BCP 92, RFC 3932, October 2004. Documents", BCP 111, RFC 4181, September 2005.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging
Schoenwaelder, "Textual Conventions for Internet Network Service (MMS) and Internet Mail", RFC 4356, January 2006.
Addresses", RFC 4001, February 2005.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory
Documents", BCP 111, RFC 4181, September 2005. Access Protocol (LDAP) Extensions", BCP 118, RFC 4521,
June 2006.
[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
Service (MMS) and Internet Mail", RFC 4356, January 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4521] Zeilenga, K., "Considerations for Lightweight Directory [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures
Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, for Protocol Extensions and Variations", BCP 125, RFC
June 2006. 4775, December 2006.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 8.2. Informative References
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for [I-D.andersson-rtg-gmpls-change]
Protocol Extensions and Variations", BCP 125, RFC 4775, Andersson, L. and A. Farrel, "Change Process for
December 2006. Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Protocols and Procedures", draft-andersson-rtg-
gmpls-change-08 (work in progress), March 2007.
10.2. Informative References [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Port-Based Network Access
Control", IEEE Standard 802.1X-2004, December 2004.
[I-D.andersson-rtg-gmpls-change] [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G.
Andersson, L. and A. Farrel, "Change Process for and S. Josefsson, "Protected EAP Protocol (PEAP) Version
Multiprotocol Label Switching (MPLS) and Generalized MPLS 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet
(GMPLS) Protocols and Procedures", draft (work in progress), October 2004.
draft-andersson-rtg-gmpls-change-08 (work in progress),
March 2007.
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991. Harmful", RFC 1263, October 1991.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
June 1999. G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2661, August 1999. RFC 2865, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
"Remote Authentication Dial In User Service (RADIUS)", Authentication Dial In User Service)", RFC 3575, July
RFC 2865, June 2000. 2003.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
Authentication Dial In User Service)", RFC 3575, Provisioning Protocol (EPP)", RFC 3735, March 2004.
July 2003.
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Provisioning Protocol (EPP)", RFC 3735, March 2004. Lefkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006. RFC 4485, May 2006.
Appendix A. Examples Appendix A. Examples
This section discusses some specific examples, as case studies. This section discusses some specific examples, as case studies.
A.1. Already documented cases A.1. Already documented cases
There are certain documents that specify a change process or describe There are certain documents that specify a change process or describe
extension considerations for specific IETF protocols: extension considerations for specific IETF protocols:
The SIP change process [RFC3427], [RFC4485] The SIP change process [RFC3427], [RFC4485]
The (G)MPLS change process (mainly procedural) The (G)MPLS change process (mainly procedural)
[I-D.andersson-rtg-gmpls-change] [I-D.andersson-rtg-gmpls-change]
LDAP extensions[RFC4521] LDAP extensions[RFC4521]
EPP extensions[RFC3735] EPP extensions[RFC3735]
DNS extensions[RFC2671] DNS extensions[RFC2671]
It is relatively common for MIBs, which are all in effect
extensions of the SMI data model, to be defined or extended It is relatively common for MIBs, which are all in effect extensions
outside the IETF. BCP 111 [RFC4181] offers detailed guidance for of the SMI data model, to be defined or extended outside the IETF.
authors and reviewers. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers.
A.2. RADIUS Extensions A.2. RADIUS Extensions
The RADIUS [RFC2865] protocol was designed to be extensible via The RADIUS [RFC2865] protocol was designed to be extensible via
addition of Attributes to a Data Dictionary on the server, without addition of Attributes to a Data Dictionary on the server, without
requiring code changes. However, this extensibility model assumed requiring code changes. However, this extensibility model assumed
that Attributes would conform to a limited set of data types and that that Attributes would conform to a limited set of data types and that
vendor extensionns would be limited to use by vendors in situations vendor extensions would be limited to use by vendors, in situations
in which interoperability was not required. Subsequent developments in which interoperability was not required. Subsequent developments
have stretched those assumptions. have stretched those assumptions.
[RFC2865] Section 6.2 defines a mechanism for Vendor-Specific [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific
extensions (Attribute 26), and states that use: extensions (Attribute 26), and states that use:
"... should be encouraged instead of allocation of global attribute should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of types, for functions specific only to one vendor's implementation
RADIUS, where no interoperability is deemed useful." of RADIUS, where no interoperability is deemed useful.
However, in practice usage of Vendor-Specific Attributes (VSAs) has However, in practice usage of Vendor-Specific Attributes (VSAs) has
been considerably broader than this; in particular, VSAs have been been considerably broader than this; in particular, VSAs have been
used by SDOs to define their extensions to the RADIUS protocol. used by SDOs to define their extensions to the RADIUS protocol.
This has caused a number of problems. Since the VSA mechanism was This has caused a number of problems. Since the VSA mechanism was
not designed for interoperability, VSAs do not contain a "mandatory" not designed for interoperability, VSAs do not contain a "mandatory"
bit. As a result, RADIUS clients and servers may not know whether it bit. As a result, RADIUS clients and servers may not know whether it
is safe to ignore unknown attributes. For example, [RFC2865] Section is safe to ignore unknown attributes. For example, [RFC2865] Section
5 states: 5 states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type." RADIUS client MAY ignore Attributes with an unknown Type.
However, in the case where the VSAs pertain to security (e.g. However, in the case where the VSAs pertain to security (e.g.
Filters) it may not be safe to ignore them, since [RFC2865] also Filters) it may not be safe to ignore them, since [RFC2865] also
states: states:
"A NAS that does not implement a given service MUST NOT implement the A NAS that does not implement a given service MUST NOT implement
RADIUS attributes for that service. For example, a NAS that is the RADIUS attributes for that service. For example, a NAS that
unable to offer ARAP service MUST NOT implement the RADIUS attributes is unable to offer ARAP service MUST NOT implement the RADIUS
for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an attributes for ARAP. A NAS MUST treat a RADIUS access-accept
unavailable service as an access-reject instead." authorizing an unavailable service as an access-reject instead."
Since it was not envisaged that multi-vendor VSA implementations Since it was not envisaged that multi-vendor VSA implementations
would need to interoperate, [RFC2865] does not define the data model would need to interoperate, [RFC2865] does not define the data model
for VSAs, and allows multiple subattributes to be included within a for VSAs, and allows multiple sub-attributes to be included within a
single Attribute of type 26. However, this enables VSAs to be single Attribute of type 26. However, this enables VSAs to be
defined which would not be supportable by current implementations if defined which would not be supportable by current implementations if
placed within the standard RADIUS attribute space. This has caused placed within the standard RADIUS attribute space. This has caused
problems in standardizing widely deployed VSAs. problems in standardizing widely deployed VSAs.
In addition to extending RADIUS by use of VSAs, SDOs have also In addition to extending RADIUS by use of VSAs, SDOs have also
defined new values of the Service-Type attribute in order to create defined new values of the Service-Type attribute in order to create
new RADIUS commands. Since [RFC2865] defined Service-Type values as new RADIUS commands. Since [RFC2865] defined Service-Type values as
being allocated First Come, First Served (FCFS), this essentially being allocated First Come, First Served (FCFS), this essentially
enabled new RADIUS commands to be allocated without IETF review. enabled new RADIUS commands to be allocated without IETF review.
skipping to change at page 15, line 17 skipping to change at page 17, line 43
The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape
to be used to secure online transactions on the Internet. It was to be used to secure online transactions on the Internet. It was
later replaced by SSL v3, also developed by Netscape. SSL v3 was later replaced by SSL v3, also developed by Netscape. SSL v3 was
then further developed by the IETF as the Transport Layer Security then further developed by the IETF as the Transport Layer Security
(TLS) protocol. (TLS) protocol.
The SSL v3 protocol was not explicitly specified to be extended. The SSL v3 protocol was not explicitly specified to be extended.
Even TLS 1.0 did not define an extension mechanism explicitly. Even TLS 1.0 did not define an extension mechanism explicitly.
However, extension "loopholes" were available. Extension mechanisms However, extension "loopholes" were available. Extension mechanisms
were finally defined in [RFC3546]: were finally defined in [RFC3546]:
o New versions
o New cipher suites o New versions
o Compression o New cipher suites
o Expanded handshake messages o Compression
o New record types o Expanded handshake messages
o New handshake messages o New record types
o New handshake messages
The protocol also defines how implementations should handle unknown The protocol also defines how implementations should handle unknown
extensions. extensions.
Of the above extension methods, new versions and expanded handshake Of the above extension methods, new versions and expanded handshake
messages have caused the most interoperability problems. messages have caused the most interoperability problems.
Implementations are supposed to ignore unknown record types but to Implementations are supposed to ignore unknown record types but to
reject unknown handshake messages. reject unknown handshake messages.
The new version support in SSL/TLS includes a capability to define The new version support in SSL/TLS includes a capability to define
new versions of the protocol, while allowing newer implementations to new versions of the protocol, while allowing newer implementations to
communicate with older implementations. As part of this communicate with older implementations. As part of this
functionality some Key Exchange methods include functionality to functionality some Key Exchange methods include functionality to
prevent version rollback attacks. prevent version rollback attacks.
The experience with this upgrade functionality in SSL and TLS is The experience with this upgrade functionality in SSL and TLS is
decidedly mixed. decidedly mixed.
o SSL v2 and SSL v3/TLS are not compatible. It is possible to use
SSL v2 protocol messages to intiate a SSL v3/TLS connection, but
it is not possible to communicate with a SSL v2 implementation
using SSL v3/TLS protocol messages.
o There are implementations that refuse to accept handshakes using
newer versions of the protocol than they support.
o There are other implementations that accept newer versions, but
have implemented the version rollback protection clumsily.
The SSL v2 problem has forced clients to use SSL v3 and TLS clients o SSL v2 and SSL v3/TLS are not compatible. It is possible to use
to continue to use SSL v2 Client Hellos for their initial handshake SSL v2 protocol messages to initiate a SSL v3/TLS connection, but
with almost all servers until 2006, much longer than would have been it is not possible to communicate with a SSL v2 implementation
desirable, in order to interoperate with old servers. using SSL v3/TLS protocol messages.
o There are implementations that refuse to accept handshakes using
newer versions of the protocol than they support.
o There are other implementations that accept newer versions, but
have implemented the version rollback protection clumsily.
The SSL v2 problem has forced SSL v3 and TLS clients to continue to
use SSL v2 Client Hellos for their initial handshake with almost all
servers until 2006, much longer than would have been desirable, in
order to interoperate with old servers.
The problem with incorrect handling of newer versions has also forced The problem with incorrect handling of newer versions has also forced
many clients to actually disable the newer protocol versions, either many clients to actually disable the newer protocol versions, either
by default, or by automatically disabling the functionality, to be by default, or by automatically disabling the functionality, to be
able to connect to such servers. Effectively, this means that the able to connect to such servers. Effectively, this means that the
version rollback protection in SSL and TLS is non-existent if talking version rollback protection in SSL and TLS is non-existent if talking
to a fatally compromised older version. to a fatally compromised older version.
SSL v3 and TLS also permitted expansion of the Client Hello and SSL v3 and TLS also permitted expansion of the Client Hello and
Server Hello handshake messages. This functionality was fully Server Hello handshake messages. This functionality was fully
skipping to change at page 17, line 22 skipping to change at page 20, line 4
messages containing AVPs they do not understand but that have the messages containing AVPs they do not understand but that have the
mandatory bit set, are expected to reject the message and terminate mandatory bit set, are expected to reject the message and terminate
the tunnel or session the message refers to. This leads to the tunnel or session the message refers to. This leads to
interesting interoperability issues, because a sender can include a interesting interoperability issues, because a sender can include a
vendor-specific AVP with the M-bit set, which then cause the vendor-specific AVP with the M-bit set, which then cause the
recipient to not interoperate with the sender. This sort of behavior recipient to not interoperate with the sender. This sort of behavior
is counter to the IETF ideals, as implementations of the IETF is counter to the IETF ideals, as implementations of the IETF
standard should interoperate successfully with other implementations standard should interoperate successfully with other implementations
and not require the implementation of non-IETF extensions in order to and not require the implementation of non-IETF extensions in order to
interoperate successfully. Section 4.2 of the L2TP specification interoperate successfully. Section 4.2 of the L2TP specification
[RFC2661] includes specific wording on this point, though there was [RFC2661] includes specific wording on this point, though there was
significant debate at the time as to whether such language was by significant debate at the time as to whether such language was by
itself sufficient. itself sufficient.
Fortunately, it does not appear that the above concerns have been a Fortunately, it does not appear that the above concerns have been a
problem in practice. At the time of this writing, the authors are problem in practice. At the time of this writing, the authors are
unaware of the existance of vendor-specific AVPs that also set the unaware of the existence of vendor-specific AVPs that also set the M-
M-bit. bit.
Author's Address Change log [RFC Editor: please remove this section]
Brian Carpenter (ed) draft-carpenter-extension-rec-02: 2007-06-15. Reorganized Sections
2 and 3.
draft-carpenter-extension-recs-01: 2007-03-04. Updated according to
comments, especially the wording about TLS, added various specific
examples.
draft-carpenter-extension-recs-00: original version, 2006-10-12.
Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by
focusing on architectural issues; the more procedural issues in that
draft were moved to RFC 4775.
Authors' Addresses
Brian Carpenter
IBM IBM
8 Chemin de Blandonnet 8 Chemin de Blandonnet
1214 Vernier, 1214 Vernier,
Switzerland Switzerland
Email: brc@zurich.ibm.com Email: brian.e.carpenter@gmail.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 18, line 42 skipping to change at page 21, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 81 change blocks. 
374 lines changed or deleted 512 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/