Network Working Group S. Bellovin
Request for Comments: 4808 Columbia University
Category: Informational March 2007
Network Working Group S. Bellovin
Request for Comments: 4808 Columbia University
Category: Informational March 2007
Key Change Strategies for TCP-MD5
TCP-MD5的关键变更策略
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes.
TCP-MD5选项最常用于保护路由器之间的BGP会话。但是，更改长期密钥很困难，因为更改需要在不同的组织之间同步。我们描述了允许（大部分）非同步关键更改的单端策略。
The TCP-MD5 option [RFC2385] is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. Worse yet, if the keys are out of sync, it may break the connection between the two routers, rendering repair attempts difficult.
TCP-MD5选项[RFC2385]最常用于保护路由器之间的BGP会话。但是，更改长期密钥很困难，因为更改需要在不同的组织之间同步。更糟糕的是，如果密钥不同步，可能会中断两个路由器之间的连接，导致修复尝试困难。
The proper solution involves some sort of key management protocol. Apart from the complexity of such things, RFC 2385 was not written with key changes in mind. In particular, there is no KeyID field in the option, which means that even a key management protocol would run into the same problem.
正确的解决方案涉及某种密钥管理协议。除了这些事情的复杂性，RFC2385的编写并没有考虑到关键的变化。特别是，选项中没有KeyID字段，这意味着即使是密钥管理协议也会遇到相同的问题。
Fortunately, a heuristic permits key change despite this protocol deficiency. The change can be installed unilaterally at one end of a connection; it is fully compatible with the existing protocol.
幸运的是，尽管存在这种协议缺陷，启发式允许密钥更改。可在连接件的一端单侧安装变更件；它与现有协议完全兼容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Separate algorithms are necessary for transmission and reception. Reception is easier; we explain it first.
传输和接收需要单独的算法。接收更容易；我们先解释一下。
A receiver has a list of valid keys. Each key has a (conceptual) timestamp associated with it. When a segment arrives, each key is tried in turn. The segment is discarded if and only if it cannot be validated by any key in the list.
接收者有一个有效密钥列表。每个键都有一个与之关联的（概念）时间戳。当一个段到达时，依次尝试每个键。当且仅当无法通过列表中的任何键验证该段时，才会丢弃该段。
In principle, there is no need to test keys in any particular order. For performance reasons, though, a simple most-recently-used (MRU) strategy -- try the last valid key first -- should work well. More complex mechanisms, such as examining the TCP sequence number of an arriving segment to see whether it fits in a hole, are almost certainly unnecessary. On the other hand, validating that a received segment is putatively legal, by checking its sequence number against the advertised window, can help avoid denial of service attacks.
原则上，不需要按任何特定顺序测试密钥。不过，出于性能原因，一个简单的最近使用（MRU）策略——首先尝试最后一个有效键——应该可以很好地工作。更复杂的机制，如检查到达段的TCP序列号以确定其是否适合孔，几乎肯定是不必要的。另一方面，通过对照公布的窗口检查其序列号，验证接收到的段是否合法，可以帮助避免拒绝服务攻击。
The newest key that has successfully validated a segment is marked as the "preferred" key; see below.
成功验证段的最新密钥标记为“首选”密钥；见下文。
Implicit in this scheme is the assumption that older keys will eventually be unneeded and can be removed. Accordingly, implementations SHOULD provide an indication of when a key was last used successfully.
该方案中隐含的假设是，旧密钥最终将不再需要，并且可以删除。因此，实现应该提供密钥上次成功使用的时间指示。
Transmission is more complex, because the sender does not know which keys can be accepted at the far end. Accordingly, the conservative strategy is to delay using any new keys for a considerable amount of time, probably measured in days. This time interval is the amount of asynchronicity the parties wish to permit; it is agreed upon out of band and configured manually.
传输更加复杂，因为发送方不知道远端可以接受哪些密钥。因此，保守的策略是延迟使用任何新密钥相当长的时间，可能以天为单位。该时间间隔是双方希望允许的异步量；在带外商定并手动配置。
Some automation is possible, however. If a key has been used successfully to validate an incoming segment, clearly the other side knows it. Accordingly, any key marked as "preferred" by the receiving part of a stack SHOULD be used for transmissions.
然而，有些自动化是可能的。如果密钥已成功用于验证传入段，则另一方显然知道它。因此，堆栈的接收部分标记为“首选”的任何密钥都应用于传输。
A sophisticated implementation could try alternate keys if the TCP retransmission counter gets too high. (This is analogous to dead gateway detection.) In particular, if a key change has just been attempted but such segments are not acknowledged, it is reasonable to fall back to the previous key and issue an alert of some sort. Similarly, an implementation with a new but unused key could occasionally try to use it, much in the way that TCP implementations probe closed windows. Doing this avoids the "silent host" problem discussed in Section 3.1. This should be done at a moderately slow rate.
如果TCP重传计数器过高，复杂的实现可以尝试使用备用密钥。（这类似于死机网关检测。）特别是，如果刚刚尝试更改密钥但未确认这些段，则返回到前一个密钥并发出某种警报是合理的。类似地，具有新的但未使用的密钥的实现可能偶尔尝试使用它，就像TCP实现探测关闭的窗口一样。这样做可以避免第3.1节中讨论的“静默主机”问题。这应该以适度缓慢的速度完成。
Note that there is an ambiguity when an acknowledgment is received for a segment transmitted with two different keys. The TCP Timestamp option [RFC1323] can be used for disambiguation.
请注意，当接收到使用两个不同密钥传输的段的确认时，存在歧义。TCP时间戳选项[RFC1323]可用于消除歧义。
Suppose only one end of the connection has this algorithm implemented. The new key is provisioned on that system, with a start time far in the future -- sufficiently far, in fact, that it will not be used spontaneously. After the key is ready, the other end is notified, out-of-band, that a key change can commence.
假设只有连接的一端实现了该算法。新密钥是在该系统上配置的，其启动时间在未来很长的一段时间内——事实上，它的启动时间足够长，不会自动使用。密钥准备好后，另一端会收到带外通知，可以开始密钥更改。
At some point, the other end is upgraded. Because it does not have multiple keys available, it will start using the new key immediately for its transmission, and will drop all segments that use the old key. As soon as it tries to transmit, the upgraded side will
在某些情况下，另一端会升级。因为它没有多个可用的密钥，它将立即开始使用新密钥进行传输，并删除所有使用旧密钥的段。一旦它尝试传输，升级的一方将
designate the new key as preferred, and will use it for all of its transmissions. Note specifically that this will include retransmissions of any segments rejected because they used the old key.
将新钥匙指定为首选钥匙，并将其用于所有传输。请特别注意，这将包括由于使用旧密钥而被拒绝的任何段的重新传输。
There is a problem if the unchanged machine is a "silent host" -- a host that has nothing to say, and hence does not transmit. The best way to avoid this is for an upgraded machine to try a variety of keys in the event of repeated unacknowledged packets, and to probe for new unused keys during silent periods, as discussed in Section 2.2. Alternatively, application-level KeepAlive messages may be used to ensure that neither end of the connection is completely silent. See, for example, Section 4.4 of [RFC4271] or Section 3.5.4 of [RFC3036].
如果未更改的计算机是一个“静默主机”——一个无话可说的主机，因此不传输数据，则会出现问题。避免这种情况的最佳方法是，升级后的机器在重复出现未确认的数据包时尝试各种密钥，并在静默期探测新的未使用密钥，如第2.2节所述。或者，可以使用应用程序级别的KeepAlive消息来确保连接的两端都不是完全静默的。例如，参见[RFC4271]第4.4节或[RFC3036]第3.5.4节。
Double-ended operations are similar, save that both sides deploy the new key at about the same time. One should be configured to start using the new key at a point where it is reasonably certain that the other side would have it installed, too. Assuming that has in fact happened, the new key will be marked "preferred" on both sides.
双端操作类似，只是双方几乎同时部署新密钥。一方应配置为在合理确定另一方也将安装新密钥的位置开始使用新密钥。假设事实上已经发生了这种情况，那么新密钥的两边都将标记为“首选”。
As noted, implementations should monitor when a key was last used for transmission or reception. Any monitoring mechanism can be used; most likely, it will be one or both of a MIB object or objects and the vendor's usual command-line mechanism for displaying data of this type. Regardless, the network operations center should keep track of this. When a new key has been used successfully for both transmission and reception for a reasonable amount of time -- the exact value isn't crucial, but it should probably be longer than twice the maximum segment lifetime -- the old key can be marked for deletion. There is an implicit assumption here that there will not be substantial overlap in the usage period of such keys; monitoring systems should look for any such anomalies, of course.
如前所述，实施应监控钥匙最后一次用于传输或接收的时间。可以使用任何监测机制；最有可能的情况是，它将是一个或多个MIB对象和供应商用于显示此类数据的常用命令行机制中的一个或两个。无论如何，网络运营中心应该对此进行跟踪。当一个新密钥在合理的时间段内成功地用于传输和接收时（确切的值并不重要，但它可能会超过最大段生存期的两倍），可以将旧密钥标记为删除。这里有一个隐含的假设，即在这些密钥的使用期间不会有实质性的重叠；当然，监控系统应该寻找任何此类异常。
As implied in Section 1, this is an interim strategy, intended to make TCP-MD5 operationally usable today. We do not suggest or recommend it as a long-term solution. In this section, we make some suggestions about the design of a future TCP authentication option.
正如第1节所暗示的，这是一个临时策略，旨在使TCP-MD5在今天的操作上可用。我们不建议或建议将其作为长期解决方案。在本节中，我们对未来TCP身份验证选项的设计提出一些建议。
The first and most obvious change is to replace keyed MD5 with a stronger MAC [RFC4278]. Today, HMAC-SHA1 [RFC4634] is the preferred choice, though others such as UMAC [RFC4418] should be considered as well.
第一个也是最明显的变化是用更强的MAC取代键控MD5[RFC4278]。如今，HMAC-SHA1[RFC4634]是首选，但也应考虑UMAC[RFC4418]等其他产品。
A new authentication option should contain some form of a Key ID field. Such an option would permit unambiguous identification of which key was used to create the MAC for a given segment, sparing the receiver the need to engage in the sort of heuristics described here. A Key ID is useful with both manual and automatic key management. (Note carefully that we do not prescribe any particular Key ID mechanism here. Rather, we are stating a requirement: there must be a simple, low-cost way to select a particular key, and it must be possible to rekey without tearing down long-lived connections.)
新的身份验证选项应包含某种形式的密钥ID字段。这样的选项将允许明确地识别用于为给定段创建MAC的密钥，从而使接收方无需参与此处描述的那种启发式。密钥ID对于手动和自动密钥管理都很有用。（请注意，我们在这里没有规定任何特定的密钥ID机制。相反，我们提出了一个要求：必须有一种简单、低成本的方法来选择特定的密钥，并且必须能够在不破坏长期连接的情况下重新设置密钥。）
Finally, an automated key management mechanism should be defined. The general reasoning for that is set forth in [RFC4107]; specific issues pertaining to BGP and TCP are given in [RFC3562].
最后，应该定义一个自动密钥管理机制。[RFC4107]中阐述了这方面的一般理由；[RFC3562]中给出了与BGP和TCP相关的具体问题。
In theory, accepting multiple keys simultaneously makes life easier for an attacker. In practice, if the recommendations in [RFC3562] are followed, this should not be a problem.
理论上，同时接受多个密钥可以让攻击者的生活更轻松。实际上，如果遵循[RFC3562]中的建议，这应该不是问题。
New keys must be communicated securely. Specifically, new key messages must be kept confidential and must be properly authenticated.
新钥匙必须安全地传递。特别是，新的关键消息必须保密，并且必须经过适当的身份验证。
Having multiple keys makes CPU denial-of-service attacks easier. This suggests that keeping the overlap period reasonably short is a good idea. In addition, the Generalized TTL Security Mechanism [RFC3682], if applicable to the local topology, can help. Note that most of the time, only one key will exist; virtually all of the remaining time there will be only two keys in existence.
拥有多个密钥使CPU拒绝服务攻击更容易。这表明保持重叠期合理地短是一个好主意。此外，通用TTL安全机制[RFC3682]如果适用于本地拓扑，也会有所帮助。请注意，大多数情况下，只有一个键存在；在剩下的时间里，几乎只有两把钥匙存在。
There are no IANA actions required. The TCP-MD5 option number is defined in [RFC2385], and is currently listed by IANA.
不需要IANA操作。TCP-MD5选项编号在[RFC2385]中定义，目前由IANA列出。
I'd like to thank Ron Bonica, Randy Bush, Ross Callon, Rob Evans, Eric Rescorla, and Sam Weiler for their comments and inspiration.
我要感谢Ron Bonica、Randy Bush、Ross Callon、Rob Evans、Eric Rescorla和Sam Weiler的评论和灵感。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[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月。
[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月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]Gill，V.，Heasley，J.，和D.Meyer，“广义TTL安全机制（GTSM）”，RFC 3682，2004年2月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[RFC4278]Bellovin，S.和A.Zinin，“关于TCP MD5签名选项（RFC 2385）和BGP-4规范的标准成熟度差异”，RFC 4278，2006年1月。
[RFC4418] Krovetz, T., "UMAC: Message Authentication Code using Universal Hashing", RFC 4418, March 2006.
[RFC4418]Krovetz，T.，“UMAC：使用通用哈希的消息身份验证代码”，RFC4418，2006年3月。
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006.
[RFC4634]Eastlake，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年8月。
Author's Address
作者地址
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
Steven M.Bellovin哥伦比亚大学阿姆斯特丹大道1214号MC 0401美国纽约州纽约市10027
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。