Network Working Group A. Heffernan
Request for Comments: 2385 cisco Systems
Category: Standards Track August 1998
Network Working Group A. Heffernan
Request for Comments: 2385 cisco Systems
Category: Standards Track August 1998
Protection of BGP Sessions via the TCP MD5 Signature Option
通过TCP MD5签名选项保护BGP会话
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
IESG Note
IESG注释
This document describes currrent existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks.
本文档描述了保护BGP免受某些简单攻击的现行做法。据了解，它在抵御协同攻击方面存在安全弱点。
Abstract
摘要
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP.
本备忘录描述了一个TCP扩展，以增强BGP的安全性。它定义了一个新的TCP选项，用于在TCP段中携带MD5[RFC1321]摘要。此摘要的作用类似于该段的签名，包含仅对连接端点已知的信息。由于BGP使用TCP作为其传输，因此以本文所述的方式使用此选项可显著降低BGP受到某些安全攻击的危险。
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
此选项的主要动机是允许BGP保护自己，防止将伪造的TCP段引入连接流。特别值得关注的是TCP重置。
To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change
要使用本文描述的方案欺骗连接，攻击者不仅必须猜测TCP序列号，还必须获得MD5摘要中包含的密码。此密码从未出现在连接流中，密码的实际形式取决于应用程序。它甚至可以改变
during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords).
在特定连接的生命周期内，只要此更改在两端同步（尽管在某些更改密码的TCP实现中，重新传输可能会出现问题）。
Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option.
最后，对于在连接中使用此选项没有任何协商，而是其连接是否使用此选项纯粹是站点策略的问题。
Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to these items in the following order:
在TCP连接上发送的每个要防止欺骗的段将包含16字节MD5摘要，该摘要是通过按以下顺序对这些项应用MD5算法生成的：
1. the TCP pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length) 2. the TCP header, excluding options, and assuming a checksum of zero 3. the TCP segment data (if any) 4. an independently-specified key or password, known to both TCPs and presumably connection-specific
1. TCP伪报头（顺序为：源IP地址、目标IP地址、零填充协议号和段长度）2。TCP标头，不包括选项，并假设校验和为0 3。TCP段数据（如果有）4。一种独立指定的密钥或密码，TCP和可能的特定连接都知道
The header and pseudo-header are in network byte order. The nature of the key is deliberately left unspecified, but it must be known by both ends of the connection. A particular TCP implementation will determine what the application may specify as the key.
报头和伪报头按网络字节顺序排列。故意不指定键的性质，但连接的两端都必须知道它。特定的TCP实现将决定应用程序可以指定什么作为密钥。
Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digest. A failing comparison must result in the segment being dropped and must not produce any response back to the sender. Logging the failure is probably advisable.
在接收到签名段后，接收方必须通过从相同数据（使用自己的密钥）计算自己的摘要并比较两个摘要来验证它。比较失败必须导致删除段，并且不能向发送方返回任何响应。记录故障可能是可取的。
Unlike other TCP extensions (e.g., the Window Scale option [RFC1323]), the absence of the option in the SYN,ACK segment must not cause the sender to disable its sending of signatures. This negotiation is typically done to prevent some TCP implementations from misbehaving upon receiving options in non-SYN segments. This is not a problem for this option, since the SYN,ACK sent during connection negotiation will not be signed and will thus be ignored. The connection will never be made, and non-SYN segments with options will never be sent. More importantly, the sending of signatures must be under the complete control of the application, not at the mercy of the remote host not understanding the option.
与其他TCP扩展（例如，窗口缩放选项[RFC1323]）不同，SYN、ACK段中没有该选项不得导致发送方禁用其签名发送。这种协商通常是为了防止某些TCP实现在接收非SYN段中的选项时出现错误行为。此选项没有问题，因为在连接协商期间发送的SYN、ACK不会被签名，因此将被忽略。永远不会建立连接，并且永远不会发送带有选项的非SYN段。更重要的是，签名的发送必须在应用程序的完全控制下进行，而不是任由不了解该选项的远程主机摆布。
The proposed option has the following format:
拟议方案的格式如下：
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| |
+---------------------------------------+
| |
+---------------------------------------+
| |
+-------------------+-------------------+
| |
+-------------------+
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| |
+---------------------------------------+
| |
+---------------------------------------+
| |
+-------------------+-------------------+
| |
+-------------------+
The MD5 digest is always 16 bytes in length, and the option would appear in every segment of a connection.
MD5摘要的长度始终为16字节，并且该选项将出现在连接的每个段中。
A connectionless reset will be ignored by the receiver of the reset, since the originator of that reset does not know the key, and so cannot generate the proper signature for the segment. This means, for example, that connection attempts by a TCP which is generating signatures to a port with no listener will time out instead of being refused. Similarly, resets generated by a TCP in response to segments sent on a stale connection will also be ignored. Operationally this can be a problem since resets help BGP recover quickly from peer crashes.
重置的接收者将忽略无连接重置，因为重置的发起人不知道密钥，因此无法为段生成正确的签名。这意味着，例如，TCP试图连接到一个没有侦听器的端口，而该端口正在生成签名，连接将超时，而不是被拒绝。同样，TCP为响应在陈旧连接上发送的段而生成的重置也将被忽略。在操作上，这可能是一个问题，因为重置有助于BGP从对等崩溃中快速恢复。
The performance hit in calculating digests may inhibit the use of this option. Some measurements of a sample implementation showed that on a 100 MHz R4600, generating a signature for simple ACK segment took an average of 0.0268 ms, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. These times would be applied to both the input and output paths, with the input path also bearing the cost of a 16-byte compare.
计算摘要时的性能影响可能会禁止使用此选项。对示例实现的一些测量表明，在100 MHz R4600上，为简单ACK段生成签名的平均时间为0.0268 ms，而为承载4096字节数据的数据段生成签名的平均时间为0.8776 ms。这些时间将应用于输入和输出路径，输入路径还承担16字节比较的成本。
As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger.
与添加到每个段的其他选项一样，在连接协商期间，MD5选项的大小必须考虑到提供给另一方的MSS中。具体而言，要从MTU中减去的头的大小（无论是传出接口的MTU还是IP的最小576字节MTU）现在至少要大18字节。
The total header size is also an issue. The TCP header specifies where segment data starts with a 4-bit field which gives the total size of the header (including options) in 32-byte words. This means that the total size of the header plus option must be less than or equal to 60 bytes -- this leaves 40 bytes for options.
标题的总大小也是一个问题。TCP标头指定段数据以4位字段开始的位置，该字段以32字节的字给出标头（包括选项）的总大小。这意味着header plus选项的总大小必须小于或等于60个字节——这将为选项保留40个字节。
As a concrete example, 4.4BSD defaults to sending window-scaling and timestamp information for connections it initiates. The most loaded segment will be the initial SYN packet to start the connection. With MD5 signatures, the SYN packet will contain the following:
作为一个具体的例子，4.4BSD默认为发送其启动的连接的窗口缩放和时间戳信息。加载最多的段将是启动连接的初始SYN数据包。对于MD5签名，SYN数据包将包含以下内容：
-- 4 bytes MSS option
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
-- 12 bytes for timestamp (4.4BSD pads the option as recommended
in RFC 1323 Appendix A)
-- 18 bytes for MD5 digest
-- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.
-- 4 bytes MSS option
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
-- 12 bytes for timestamp (4.4BSD pads the option as recommended
in RFC 1323 Appendix A)
-- 18 bytes for MD5 digest
-- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.
This sums to 40 bytes, which just makes it.
这总共是40个字节，这就足够了。
Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application.
自本备忘录首次发布（标题不同）以来，MD5算法已被发现容易受到碰撞搜索攻击[Dobb]，一些人认为该算法对于此类应用而言不够强大。
This memo still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original document did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space.
但是，此备忘录仍然指定了MD5算法，因为该选项已经在操作上部署，并且没有定义“算法类型”字段以允许使用相同的选项编号进行升级。原始文档没有指定类型字段，因为这将需要至少多一个字节，并且当时认为完整选项占用19个字节（在TCP实现中可能会填充为20个字节）会浪费已经有限的选项空间。
This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field.
这并不妨碍部署另一个使用另一个散列算法（如SHA-1）的类似选项。此外，如果大多数实现都将定义的18字节选项填充为20字节，那么最好定义一个包含算法类型字段的新选项。
This would need to be addressed in another document, however.
然而，这需要在另一份文件中加以说明。
It should be noted that the key configuration mechanism of routers may restrict the possible keys that may be used between peers. It is strongly recommended that an implementation be able to support at minimum a key composed of a string of printable ASCII of 80 bytes or less, as this is current practice.
应当注意，路由器的密钥配置机制可以限制对等方之间可能使用的密钥。强烈建议实现至少能够支持由80字节或更少的可打印ASCII字符串组成的密钥，因为这是当前的做法。
This document defines a weak but currently practiced security mechanism for BGP. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues.
本文件为BGP定义了一个薄弱但目前行之有效的安全机制。预计今后的工作将为处理这些问题提供不同的、更强有力的机制。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA
Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA
Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
Author's Address
作者地址
Andy Heffernan cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Andy Heffernan cisco Systems 170美国加利福尼亚州圣何塞西塔斯曼大道95134号
Phone: +1 408 526-8115
EMail: ahh@cisco.com
Phone: +1 408 526-8115
EMail: ahh@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。