Network Working Group S. Bellovin
Request for Comments: 4278 AT&T Labs Research
Category: Informational A. Zinin
Alcatel
January 2006
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
关于TCP MD5签名选项（RFC 2385）和BGP-4规范的标准成熟度差异
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).
版权所有（C）互联网协会（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.
IETF标准过程要求文件的所有规范性参考文件应处于相同或更高的标准化水平。RFC 2026第9.1节允许IESG批准IETF标准实践的变更。本文件解释了IESG为什么考虑对BGP-4规范的修订版这样做，该规范参考了RFC 2385，“通过TCP MD5签名选项保护BGP会话”。RFC 2385将保持在提议的标准水平。
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.)
IETF标准过程[RFC2026]要求文件的所有规范性参考文件应处于相同或更高的标准化水平。RFC 2026第9.1节允许IESG批准IETF标准实践的变更。据此，它正在考虑将更新的BGP-4规范[RFC4271]作为标准草案发布，尽管规范性参考文献[RFC2385]，“通过TCP MD5签名选项保护BGP会话”。RFC 2385仍将是建议的标准。（注意，尽管[RFC2385]的标题包括“签名”一词，但其中描述的技术通常被称为消息认证码或MAC，不应与数字签名技术混淆。）
[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
广泛实施的[RFC2385]是为BGP-4定义的唯一传输安全机制。其他可能的机制，如IPsec[RFC2401]和TLS[RFC2246]很少使用
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.
为此目的。鉴于协议中对安全功能的长期需求，如果没有强制的安全机制，就不可能推进BGP-4。
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.
规范之间的成熟度级别冲突通常可以通过沿着标准轨道将引用的规范推进到引用规范需要达到的成熟度级别来解决。然而，在这里考虑的特殊情况下，IESG认为[RFC2385]虽然目前足以用于BGP部署，但不足以用于一般用途，因此不应沿着标准轨道前进。在这种情况下，IESG认为应使用变更程序，以允许更新后的BGP-4规范作为标准草案发布。
The following sections of the document give detailed explanations of the statements above.
本文件以下各节对上述陈述作了详细解释。
The requirements for Proposed Standards and Draft Standards are given in [RFC2026]. For Proposed Standards, [RFC2026] warns that:
[RFC2026]中给出了拟定标准和标准草案的要求。对于拟定标准，[RFC2026]警告：
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.
换句话说，任何已知存在缺陷的文件都不应提升为标准草案。
[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. But cryptographic hash functions were never intended for use as MACs, and later cryptanalytic results showed that the construct was not as strong as originally believed [PV1, PV2]. Worse yet, the underlying hash function, MD5, has shown signs of weakness [Dobbertin, Wang]. Accordingly, the IETF community has adopted Hashed Message Authentication Code (HMAC) [RFC2104], a scheme with provable security properties, as its standard MAC.
[RFC2385]尽管发布日期为1998年，但它描述了一种相当古老的消息身份验证码（MAC）。它使用一种称为“键控哈希函数”的技术，使用MD5[RFC1321]作为哈希函数。在开发原始代码时，这被认为是一种合理的技术，尤其是在将密钥附加（而不是预先添加）到受保护的数据时。但加密散列函数从未打算用作MAC，后来的密码分析结果表明，该构造并不像最初认为的那样强大[PV1，PV2]。更糟糕的是，底层的散列函数MD5已经显示出弱点[Dobbertin，Wang]。因此，IETF社区采用了哈希消息认证码（HMAC）[RFC2104]，一种具有可证明安全属性的方案，作为其标准MAC。
Beyond that, [RFC2385] does not include any sort of key management technique. Common practice is to use a password as a shared secret between pairs of sites, but this is not a good idea [RFC3562].
除此之外，[RFC2385]不包括任何类型的密钥管理技术。通常的做法是使用密码作为成对站点之间的共享秘密，但这不是一个好主意[RFC3562]。
Other problems are documented in [RFC2385] itself, including the lack of a type code or version number, and the inability of systems using this scheme to accept certain TCP resets.
[RFC2385]本身记录了其他问题，包括缺少类型代码或版本号，以及使用此方案的系统无法接受某些TCP重置。
Despite the widespread deployment of [RFC2385] in BGP deployments, the IESG has thus concluded that it is not appropriate for use in other contexts. [RFC2385] is not suitable for advancement to Draft Standard.
尽管在BGP部署中广泛部署了[RFC2385]，但IESG得出结论认为，它不适合在其他环境中使用。[RFC2385]不适合推进到标准草案。
Given the above analysis, it is reasonable to ask why [RFC2385] is still used for BGP. The answer lies in the deployment patterns peculiar to BGP.
鉴于上述分析，有理由问为什么[RFC2385]仍然用于BGP。答案在于BGP特有的部署模式。
BGP connections inherently tend to travel over short paths. Indeed, most external BGP links are one hop. Although internal BGP sessions are usually multi-hop, the links involved are generally inhabited only by routers rather than general-purpose computers; general-purpose computers are easier for attackers to use as TCP hijacking tools [Joncheray].
BGP连接天生倾向于在短路径上传输。事实上，大多数外部BGP链路都是单跳的。虽然内部BGP会话通常是多跳的，但所涉及的链路通常只由路由器而不是通用计算机占用；通用计算机更容易被攻击者用作TCP劫持工具[Joncheray]。
Also, BGP peering associations tend to be long-lived and static. By contrast, many other security situations are more dynamic.
此外，BGP对等关联往往是长期和静态的。相比之下，许多其他安全局势更具动态性。
This is not to say that such attacks cannot happen. (If they couldn't happen at all, there would be no point to any security measures.) Attackers could divert links at layers 1 or 2, or they
这并不是说这种袭击不会发生。（如果它们根本不可能发生，那么采取任何安全措施都没有意义。）攻击者可以转移第1层或第2层的链接，或者
could (in some situations) use Address Resolution Protocol (ARP) spoofing at Ethernet-based exchange points. Still, on balance, BGP is employed in an environment that is less susceptible to this sort of attack.
可能（在某些情况下）在基于以太网的交换点上使用地址解析协议（ARP）欺骗。不过，总的来说，BGP是在不太容易受到此类攻击的环境中使用的。
There is another class of attack against which BGP is extremely vulnerable: false route advertisements from more than one autonomous system (AS) hop away. However, neither [RFC2385] nor any other transmission security mechanism can block such attacks. Rather, a scheme such as S-BGP [Kent] would be needed.
BGP极易受到另一类攻击：来自多个自治系统（AS）的虚假路由广告。然而，[RFC2385]或任何其他传输安全机制都无法阻止此类攻击。相反，需要一个像S-BGP[Kent]这样的计划。
The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. Deployment practices for LDP are very similar to those of BGP: LDP connections are usually confined within a single autonomous system and most frequently span a single link between two routers. This makes the LDP threat environment very similar to BGP's. Given this, and a considerable installed base of LDP in service provider networks, we are not deprecating [RFC2385] for use with LDP.
标签分发协议（LDP）[RFC3036]也使用[RFC2385]。LDP的部署实践与BGP非常相似：LDP连接通常限制在一个单独的自治系统内，并且通常跨越两个路由器之间的单个链路。这使得自民党的威胁环境与BGP非常相似。考虑到这一点，以及服务提供商网络中LDP的大量安装基础，我们并不反对[RFC2385]与LDP一起使用。
The IESG believes that the variance described here will not adversely affect the security of the Internet.
IESG认为，此处描述的差异不会对互联网安全产生不利影响。
Given the above analysis, the IESG is persuaded that waiving the prerequisite requirement is the appropriate thing to do. [RFC2385] is clearly not suitable for Draft Standard. Other existing mechanisms, such as IPsec, would do its job better. However, given the current operational practices in service provider networks at the moment -- and in particular the common use of long-lived standard keys, [RFC3562] notwithstanding -- the marginal benefit of such schemes in this situation would be low, and not worth the transition effort. We would prefer to wait for a security mechanism tailored to the major threat environment for BGP.
鉴于上述分析，IESG认为放弃先决条件要求是恰当的做法。[RFC2385]显然不适用于标准草案。其他现有机制，如IPsec，将更好地发挥作用。然而，考虑到目前服务提供商网络中的当前操作实践——特别是长期标准密钥的普遍使用[RFC3562]，这种方案在这种情况下的边际效益将很低，不值得过渡。我们更愿意等待针对BGP的主要威胁环境定制的安全机制。
[Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
[Dobbertin]H.Dobbertin，“最近一次攻击后MD5的状态”，RSA实验室的CryptoBytes，第2卷第2期，1996年夏季。
[Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." Proceedings of the Fifth Usenix Unix Security Symposium, 1995.
对TCP的简单主动攻击〉，《第五届Usenix Unix安全研讨会论文集》，1995年。
[Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway Protocol (Secure-BGP)." IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, April, 2000, pp. 582-592.
[Kent]Kent，S.，C.Lynn和K.Seo。“安全边界网关协议（安全BGP）。《IEEE通信选定领域杂志》，第18卷，第4期，2000年4月，第582-592页。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building
fast MACs from hash functions," Advances in Cryptology
--- Crypto 95 Proceedings, Lecture Notes in Computer
Science Vol. 963, D. Coppersmith, ed., Springer-Verlag,
1995.
[PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building
fast MACs from hash functions," Advances in Cryptology
--- Crypto 95 Proceedings, Lecture Notes in Computer
Science Vol. 963, D. Coppersmith, ed., Springer-Verlag,
1995.
[PV2] B. Preneel and P. van Oorschot, "On the security of two
MAC algorithms," Advances in Cryptology --- Eurocrypt 96
Proceedings, Lecture Notes in Computer Science, U.
Maurer, ed., Springer-Verlag, 1996.
[PV2] B. Preneel and P. van Oorschot, "On the security of two
MAC algorithms," Advances in Cryptology --- Eurocrypt 96
Proceedings, Lecture Notes in Computer Science, U.
Maurer, ed., Springer-Verlag, 1996.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares编辑，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[Wang] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions." Proceedings of Eurocrypt '05, 2005.
[Wang]Wang，X.和H.Yu，“如何破解MD5和其他哈希函数”，《欧洲密码会议录》2005年5月。
Authors' Addresses
作者地址
Steven M. Bellovin Department of Computer Science Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027-7003
Steven M.Bellovin哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
加利福尼亚州米德尔菲尔德东路山景城701号亚历克斯·齐宁阿尔卡特，邮编94043
EMail: zinin@psg.com
EMail: zinin@psg.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。