Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification
RFC 4278
Document | Type |
RFC - Informational
(January 2006; No errata)
Was draft-iesg-tcpmd5app (iesg)
|
|
---|---|---|---|
Authors | Steven Bellovin , Alex Zinin | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4278 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Alex Zinin | ||
Send notices to | shares@nexthop.com, yakov@juniper.net |
Network Working Group S. Bellovin Request for Comments: 4278 AT&T Labs Research Category: Informational A. Zinin Alcatel January 2006 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. 1. Introduction The IETF Standards Process [RFC2026] requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. Pursuant to that, it is considering publishing the updated BGP-4 specification [RFC4271] as Draft Standard, despite the normative reference to [RFC2385], "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain a Proposed Standard. (Note that although the title of [RFC2385] includes the word "signature", the technology described in it is commonly known as a Message Authentication Code or MAC, and should not be confused with digital signature technologies.) [RFC2385], which is widely implemented, is the only transmission security mechanism defined for BGP-4. Other possible mechanisms, such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used Bellovin & Zinin Informational [Page 1] RFC 4278 Standards Maturity Variance: RFC 2385 and BGP-4 January 2006 for this purpose. Given the long-standing requirement for security features in protocols, it is not possible to advance BGP-4 without a mandated security mechanism. The conflict of maturity levels between specifications would normally be resolved by advancing the specification being referred to along the standards track, to the level of maturity that the referring specification needs to achieve. However, in the particular case considered here, the IESG believes that [RFC2385], though adequate for BGP deployments at this moment, is not strong enough for general use, and thus should not be progressed along the standards track. In this situation, the IESG believes that variance procedure should be used to allow the updated BGP-4 specification to be published as Draft Standard. The following sections of the document give detailed explanations of the statements above. 2. Draft Standard Requirements The requirements for Proposed Standards and Draft Standards are given in [RFC2026]. For Proposed Standards, [RFC2026] warns that: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. In other words, it is considered reasonable for flaws to be discovered in Proposed Standards. The requirements for Draft Standards are higher: A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. In other words, any document that has known deficiencies should not be promoted to Draft Standard. Bellovin & Zinin Informational [Page 2] RFC 4278 Standards Maturity Variance: RFC 2385 and BGP-4 January 2006 3. The TCP MD5 Signature Option [RFC2385], despite its 1998 publication date, describes a Message Authentication Code (MAC) that is considerably older. It utilizes a technique known as a "keyed hash function", using MD5 [RFC1321] as the hash function. When the original code was developed, this was believed to be a reasonable technique, especially if the key was appended (rather than prepended) to the data being protected. ButShow full document text