General Area O. Gudmundsson
Internet-Draft Shinkuro Inc.
Intended status: Standards Track S. Rose
Expires: April 22, 2010 NIST
October 19, 2009
Definitions for expressing standards requirements in IANA registries.
draft-ogud-iana-protocol-maintenance-words-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
RFC 2119 defines words that are used in IETF standards documents to
indicate standards compliance. These words are fine for defining new
Gudmundsson & Rose Expires April 22, 2010 [Page 1]
Internet-Draft Keywords IANA registry October 2009
protocols, but there are certain deficiencies in using them when it
comes to protocol maintainability. Protocols are maintained by
either updating the core specifications or via changes in protocol
registries.
For example, protocols often use external algorithms to to provide
security functionality such as cryptography. Cryptographic
algorithms frequently have limited lifecyles as new algorithms are
phased in to replace older algorithms.
This document proposes standard terms to use in protocol registries
and possibly in standards track documents to indicate the life cycle
support of protocol features and operations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Implementation vs. Operations requirements . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed requirement words for IANA protocol registries . . . . 4
3.1. MANDATORY . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OPTIONAL . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. OBSOLETE . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. ENCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. DISCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. RESERVED . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Registry maintenance . . . . . . . . . . . . . . . . . 6
5. Example registry . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Gudmundsson & Rose Expires April 22, 2010 [Page 2]
Internet-Draft Keywords IANA registry October 2009
1. Introduction
The RFC series have been the main way to define Internet protocols.
In the old days RFCxx00 contained a listing of all current protocol
parameters that were needed, RFC 3232 [RFC3232] obsoleted the RFCxx00
series and replaced them with on-line protocol registries maintained
by IANA. In many cases these registries are "write-once" i.e. new
things are added; in other cases the requirements of a protocol
implementation changes over time. This document is aimed at the
second case.
This document is motivated by the experiences of the editors in
trying to maintaining registries for DNS and DNSSEC. For example,
DNS defines a registry for hash algorithms used for a message
authentication scheme called TSIG [RFC2845], the first entry in that
registry was for HMAC-MD5. The DNSEXT working group decided to try
to decrease the number of algorithms listed in the registry and add a
column to the registry listing the requirements level for each one.
Upon reading that HMAC-MD5 was tagged as "OBSOLETE" a firestorm
started. It was interpreted as the DNS community making a statement
on the status of HMAC-MD5 for all uses. While the document was
definitely overreaching in its specification, the point remained
there was no standard way to tag different requirements levels in
protocol registries.
In the crypto community there has been some attempts to indicate
emerging and retiring algorithms by adding + or - to RFC2119 words
RFC4305 [RFC4305], SHOULD+ is to be interpreted as "SHOULD for now,
expected to be MUST soon". MUST- indicates that the currently
required algorithm or feature might be retired sometime in the near
future.
In this document when we say "registry" we mean both "IANA registry"
and possibly protocol specifying RFCs.
1.1. Implementation vs. Operations requirements
It is common that before a new technology is considered "useful" it
has to gain widespread deployment. Thus it makes sense to have
different levels of RFC2119 words requirement on implementations than
on operations.
In a world of protocol maintenance when something is being 'retired'
it is nice if operations can easily migrate to a newer functionality.
This document includes certain extra requirements on implementations
during the phase-out of a functionality.
Gudmundsson & Rose Expires April 22, 2010 [Page 3]
Internet-Draft Keywords IANA registry October 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
to be interpreted as described in RFC 2119 [RFC2119].
3. Proposed requirement words for IANA protocol registries
The words below are expected to be in a separate column in the
Registries indicating what support implementations are expected to
provide for each functionality.
3.1. MANDATORY
This is the strongest requirement and for an implementation to ignore
it there MUST be a valid reason.
Implementations: To be considered compliant all implementations MUST
support this registry entry.
Operations: To be considered compliant operations MUST use at least
one of the mandatory entries.
Note 1: There can be more than one MANDATORY requirement.
Note 2: The requirement applies only to new or future
implementations on the day the requirement is released. In many
cases existing implementations can become compliant via software
upgrade or point release.
3.2. OPTIONAL
Implementations: Any implementation MAY or MAY NOT support this
entry in the protocol registry. The presence or omission of this
MUST NOT be used to judge implementations on standards compliance.
Operations: Any use of this in operation is supported, ignoring or
rejecting requests using this protocol component MUST NOT be used
as bases for asserting lack of compliance.
Note 1: Optional is taken to mean that the given functionality MAY
or MAY NOT be supported by an implementation or a given
operational MAY or MAY NOT be used.
3.3. OBSOLETE
Implementations: New implementations SHOULD NOT support this
functionality.
Gudmundsson & Rose Expires April 22, 2010 [Page 4]
Internet-Draft Keywords IANA registry October 2009
Operations: Any use of this functionality in operation MUST be
phased out.
Note This is the most dangerous term of the requirements words as it
is easy to read too much into this term. The intent is to express
the following:
* This functionality is not needed/desired anymore by the given
protocol. This is not to say that this particular
functionality should be obsoleted by other protocols that use
the the same (or similar) functionality.
3.4. ENCOURAGED
This word is added to the registry entry when new functionality is
added and before it is safe to rely solely on it. Protocols that
have the ability to negotiate capabilities MAY NOT need this state.
Implementations: This functionality SHOULD be supported by
implementations.
Operations: This functionality SHOULD NOT be used in operations,
except for testing.
Note1: In broadcast protocols like BGP and DNS there is no way for
an originator of a message to know the capabilities of all
recipients. In these cases the requirement for support ought to
be placed on implementations before the functionality is used in
operations to guarantee maximum acceptance of the messages.
Note2: In some cases this requires having both "new" and "old"
algorithms in use at the same time. In this case the new
functionality can be used before a high percentage of deployment
of the new functionality has taken place.
Note3: In protocols that negotiate which functionality to use, there
is no reason to place different requirement on operations other
than list of accepted functionality SHOULD contain at least one
MANDATORY functionality.
3.5. DISCOURAGED
This requirement is placed on functionality that is being phased out.
Implementations: Implementations MUST support this functionality,
and SHOULD provide features to migrate to a MANDATORY
functionality. The use of this functionality SHOULD NOT be used
as default behavior.
Operations: Operations SHOULD phase out any use of this
functionality.
Gudmundsson & Rose Expires April 22, 2010 [Page 5]
Internet-Draft Keywords IANA registry October 2009
Note: This is the strongest signal to the community that this
functionality is no longer considered best practice. Some time
after the functionality enters this state, it will migrate to
OBSOLETE.
3.6. RESERVED
Sometimes there is a need to reserve certain values to avoid problems
such as values that have been used in implementations but were never
formally registered. In other cases reserved values are magic
numbers that may be used in the future as escape valves if the number
space becomes too small.
Implementations: Implementations MUST NOT use any RESERVED values
for implementation specific processing.
Operations: MUST NOT be used, any implementation in use that uses
this code SHOULD be upgraded/retired.
3.7. AVAILABLE
This is a value that can be allocated by IANA at any time.
Implementations: Implementations SHOULD NOT use these values for
implementation specific processing.
Operations: Any implementation claiming to know the meaning of this
unallocated code MUST NOT be used.
4. Protocol Registry maintenance
In theory the process to change the status of protocol field should
be the same as reserving a new field. In practice this is going to
be burdensome, as there is a chance the IESG will have to process
many documents that are simply saying "Value X in Registry Y is now
Mandatory" (or similar).
For this reason we propose that it be possible to make reservations
and have a change in that reservation to take place at defined date
in the future. For example, a document could say:
Value X in registry Y is "ENCOURAGED". On June 1st 2020 this
value is to become "MANDATORY".
or Value X in registry Y is "DISCOURAGED". On June 1st 2020 this
value is to become "OBSOLETE".
Gudmundsson & Rose Expires April 22, 2010 [Page 6]
Internet-Draft Keywords IANA registry October 2009
or Value X in registry Y is "RESERVED" until June 1st 2020 when this
value becomes "AVAILABLE".
5. Example registry
This is an example registry for protocol FOO that uses encrypted
channel for messages. The algorithms listed here are only for
illustration uses.
FOO
+--------+--------------------+-----------------+-------------------+
| Value | Algorithm name | Requirment | References |
+--------+--------------------+-----------------+-------------------+
| 0 | | Reserved> | RFCfoo |
| 1 | Rotating 13 chars | OBSOLETE | RFCfoo, RFCrot13 |
| | cypher | | |
| 2 | Data Encryption | DISCOURAGED | RFCfoo, RFCdes |
| | Standard | | |
| 3 | BlowFish | MANDATORY | RFCblowfish, |
| | | | RFCrot13 |
| 4 | | RESERVED until | RFCrot13 |
| | | 2022 | |
| 5 | AES | Encouraged | RFCfooaes |
| 6 - | | Available | RFCfoo |
| 255 | | | |
+--------+--------------------+-----------------+-------------------+
Allocation policy any RFC published on April 1'st.
Table 1
6. Security Considerations
This document specifies a set of terms to indicate the status of
features in protocol implementations and operations. It is not meant
to be a discussion on feature or operation superiority or provide a
means to measure the usefulness of a feature. It is hoped that by
extending the RFC2119 words to be more applicable for protocol
maintenance over all security of the Internet is improved.
7. IANA considerations
This document does not require any IANA actions.
Gudmundsson & Rose Expires April 22, 2010 [Page 7]
Internet-Draft Keywords IANA registry October 2009
This document does set rules for registrations of compliance
requirements in IANA registries.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
8.2. Informative References
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
Authors' Addresses
Olafur Gudmundsson
Shinkuro Inc.
4922 Fairmont Avenue, Suite 250
Bethesda, MD 20814
USA
Email: ogud@ogud.com
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
Email: scott.rose@nist.gov
Gudmundsson & Rose Expires April 22, 2010 [Page 8]