INTERNET-DRAFT R. Housley Intended Status: Informational Vigil Security Expires: 10 November 2014 10 May 2014 Expectations of Implementers of IETF Protocols Abstract By choosing to implement an IETF protocol, one is expected to follow the specification, associated best current practices, and IANA registry practices. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Housley [Page 1] INTERNET-DRAFT 10 May 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction This document provides advice to implementers of IETF protocols to improve interoperability of their implementations. IETF protocols foster interoperability. This interoperability brings great benefits. IETF protocols are building blocks for many products and services, and they enable innovation. Yet, IETF standards are voluntary standards. No one is required to implement them. Implementation is a choice. By making this choice, an implementor is expected to: (1) Follow the protocol specification; (2) Follow associated Best Current Practices (BCPs); and (3) Follow associated IANA registry practices. When implementers meet these expectations, protocols interoperate as intended by the IETF. These expectations reflect the fundamental philosophy of the IETF. That is, interoperability is achieved when people choose to cooperate. By taking these actions one can expect to achieve greater interoperability with others. 2. First Expectation: Follow the Protocol Specification To repeat, IETF protocols foster interoperability, and this interoperability brings great benefits. If one does not follow the protocol specification, then interoperability is jeopardized. Of course, one should follow Postel's Law while implementing the specification: In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. [RFC760] Following Postel's Law simply increases interoperability. One should be careful to send well-formed protocol data units and carefully follow elements of procedure; which avoids surprises for communicating peers that use other implementations. On the other hand, one should accept any protocol data unit that can be interpreted, which heightens interoperability in the face of technical errors by others. Many protocol specifications are living documents; things that change Housley [Page 2] INTERNET-DRAFT 10 May 2014 over time. An implementer should plan to maintain their implementation. It is not sufficient to do an initial implementation of the protocol. One needs to apply changes as they come out. The most obvious and urgent example involves specification revisions that fix security issues that are found after the initial publication of a protocol specification. 3. Second Expectation: Follow Associated Best Current Practices Best Current Practices (BCPs) about IETF protocols (not the BCPs that define IETF processes and procedures) are intended to standardize practices. The Internet is composed of networks operated by a great variety of organizations, with diverse goals and rules. By following the BCPs, implementers, operators, and administrators are able to provide a common experience when using the protocol, regardless of their point of attachment to the Internet. Sometimes BCPs are referenced in the protocol specification. Often the implementer needs to look through the BCP index to find related BCPs. 4. Third Expectation: Follow Associated IANA Registry Practices Many IETF protocols use identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployed, new values may be needed. To ensure that such quantities have consistent values and interpretations across all implementations, assignment is administered by a central authority, the Internet Assigned Numbers Authority (IANA). In order to manage a namespace (which might also be called an assigned number, an assigned value, a code point, a a protocol constant, or a protocol parameter) in support of a particular IETF protocol, IANA is given instructions and conditions under which new values should be assigned or when modifications to existing values can be made. Implementers are expected to follow the IANA registry practices associated with the protocol, especially in the assignment of new values. By following these practices, other implementations will learn about new values and make the appropriate updates to handle them properly. Note that IP addresses and the top levels of the DNS name hierarchy are managed in IANA registries [RFC2860]. Please follow the IANA registry practices for the assignment of special IP addresses and top-level DNS names in the rare cases where such values are needed. Housley [Page 3] INTERNET-DRAFT 10 May 2014 5. Security Considerations This document calls for implementers to follow the protocol specification, follow associated best current practices, and follow IANA registry practices. These actions improve interoperability, and these actions may also reduce security incidents due to incomplete protocol implementations. It is not sufficient to do an initial implementation of the protocol. Maintenance is needed to apply changes as they come out in the future, especially to fix security issues that are found after the initial publication of a protocol specification. Security processing is an exception to Postel's Law. For example, a password that is close, but not exactly right, is not sufficient to gain access. Processing associated with integrity, authentication, access control, and confidentiality mechanisms cannot be forgiving. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements Thanks to the people that reviewed this document and suggested important improvements, including Bernard Aboba, Richard Barnes, Scott Brim, Randy Bush, John Curran, Lars Eggert, Adrian Farrel, Stephen Farrell, and Joel Jaeggli. 8. Normative References [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. 9. Informative References [RFC760] Postel, J., "DoD standard Internet Protocol", RFC 760, January 1980. Housley [Page 4] INTERNET-DRAFT 10 May 2014 Author's Address Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Housley [Page 5]