Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 6039 IP Infusion
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
J. Jaeggli
Nokia Inc.
R. White
Cisco Systems
October 2010
Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 6039 IP Infusion
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
J. Jaeggli
Nokia Inc.
R. White
Cisco Systems
October 2010
Issues with Existing Cryptographic Protection Methods for Routing Protocols
路由协议的现有加密保护方法存在的问题
Abstract
摘要
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
路由协议随着时间的推移得到了扩展，以使用加密机制来确保从相邻路由器接收的数据在传输过程中没有被修改，并且实际上来自授权的相邻路由器。
The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.
迄今为止定义并在本文档中描述的加密机制依赖于应用于封装在路由协议分组中的有效载荷的哈希算法生成的摘要。
This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations.
本文档概述了当前机制的一些限制、这些加密算法的手动键控问题以及利用这些限制的可能向量。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6039.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6039.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Problem Statement ...............................................3
1.1. Pre-Image vs. Collision Attacks ............................4
1.2. Concerns about MD5 and the SHA-1 Algorithm .................4
2. Open Shortest Path First Version 2 (OSPFv2) .....................5
2.1. Management Issues with OSPFv2 ..............................5
2.2. Technical Issues with OSPFv2 ...............................6
3. Open Shortest Path First Version 3 (OSPFv3) .....................7
3.1. Management Issues with OSPFv3 ..............................7
3.2. Technical Issues with OSPFv3 ...............................8
4. Intermediate System to Intermediate System Routing
Protocol (IS-IS) ................................................9
4.1. Management Issues with IS-IS ...............................9
4.2. Technical Issues with IS-IS ...............................10
5. Border Gateway Protocol (BGP-4) ................................11
5.1. Management Issues with BGP-4 ..............................12
5.2. Technical Issues with BGP-4 ...............................13
6. The Routing Information Protocol (RIP) .........................13
6.1. Technical Issues with RIP .................................14
7. Bidirectional Forwarding Detection (BFD) .......................15
7.1. Technical Issues with BFD .................................15
8. Security Considerations ........................................17
9. Acknowledgements ...............................................17
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................18
11. Contributor's Address .........................................21
1. Problem Statement ...............................................3
1.1. Pre-Image vs. Collision Attacks ............................4
1.2. Concerns about MD5 and the SHA-1 Algorithm .................4
2. Open Shortest Path First Version 2 (OSPFv2) .....................5
2.1. Management Issues with OSPFv2 ..............................5
2.2. Technical Issues with OSPFv2 ...............................6
3. Open Shortest Path First Version 3 (OSPFv3) .....................7
3.1. Management Issues with OSPFv3 ..............................7
3.2. Technical Issues with OSPFv3 ...............................8
4. Intermediate System to Intermediate System Routing
Protocol (IS-IS) ................................................9
4.1. Management Issues with IS-IS ...............................9
4.2. Technical Issues with IS-IS ...............................10
5. Border Gateway Protocol (BGP-4) ................................11
5.1. Management Issues with BGP-4 ..............................12
5.2. Technical Issues with BGP-4 ...............................13
6. The Routing Information Protocol (RIP) .........................13
6.1. Technical Issues with RIP .................................14
7. Bidirectional Forwarding Detection (BFD) .......................15
7.1. Technical Issues with BFD .................................15
8. Security Considerations ........................................17
9. Acknowledgements ...............................................17
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................18
11. Contributor's Address .........................................21
Protocols, such as OSPF version 2 [RFC2328], version 3 [RFC5340], IS-IS [RFC1195], BGP-4 [RFC4271], and BFD [RFC5880], employ various mechanisms to create a cryptographic digest of each transmitted protocol packet. Traditionally, these digests are the results of a one-way hash algorithm, such as Message Digest 5 (MD5) [RFC1321], across the contents of the packet being transmitted. A secret key is used as the hash base (or seed). The digest is then recomputed by the receiving router, using the same key as the original router used to create the hash, then compared with the transmitted digest to verify:
诸如OSPF版本2[RFC2328]、版本3[RFC5340]、IS-IS[RFC1195]、BGP-4[RFC4271]和BFD[RFC5880]等协议采用各种机制来创建每个传输协议分组的密码摘要。传统上，这些摘要是单向散列算法的结果，例如消息摘要5（MD5）[RFC1321]，跨越正在传输的分组的内容。密钥用作哈希基（或种子）。然后，接收路由器使用与用于创建哈希的原始路由器相同的密钥重新计算摘要，然后与传输的摘要进行比较，以验证：
o That the router originating this packet is authorized via the shared key mechanism to peer with the local router and exchange routing data. The implicit trust of the routing protocol exchange protected by a shared secret is intended to protect against the injection of falsely generated routing data into the routing system by unauthorized systems.
o 发起此数据包的路由器通过共享密钥机制被授权与本地路由器对等并交换路由数据。受共享秘密保护的路由协议交换的隐式信任旨在防止未经授权的系统将错误生成的路由数据注入路由系统。
o That the data has not been altered in transit between the two neighboring routers.
o 数据在两个相邻路由器之间传输时未被更改。
Digest verification schemes are not intended to protect the confidentiality of information being exchanged between routers. The information (entries in the routing table) is potentially available through other mechanisms. Moreover, access to the physical media between two routers exchanging routing data will confer the ability to capture or otherwise discover the contents of the routing tables in those routers.
摘要验证方案并不旨在保护路由器之间交换的信息的机密性。信息（路由表中的条目）可能通过其他机制获得。此外，对交换路由数据的两个路由器之间的物理介质的访问将授予捕获或以其他方式发现这些路由器中路由表内容的能力。
Authentication mechanisms defined today have notable limitations:
目前定义的身份验证机制有明显的局限性：
o Manual configuration of shared secret keys, especially in large networks and between networks, poses a major management problem. In many cases, it is challenging to replace keys without significant coordination or disruption.
o 手动配置共享密钥，特别是在大型网络和网络之间，是一个主要的管理问题。在许多情况下，在没有重大协调或中断的情况下更换钥匙是一项挑战。
o In some cases, when manual keys are configured, some forms of replay protection are no longer possible, allowing the routing protocol to be attacked through the replay of captured routing messages.
o 在某些情况下，当配置手动密钥时，某些形式的重播保护不再可能，从而允许通过重播捕获的路由消息来攻击路由协议。
This document outlines some of the problems with manual keying of these cryptographic algorithms.
本文档概述了这些加密算法的手动键控的一些问题。
A pre-image attack (an attempt to find new data with the same hash value) would enable someone to find an input message that causes a hash function to produce a particular output. In contrast, a collision attack finds two messages with the same hash, but the attacker can't pick what the message will be. Feasible collision attacks against MD4, MD5, HAVAL-128, and RIPEMD have been documented in [Crypto2004].
预映像攻击（试图查找具有相同哈希值的新数据）将使某人能够查找导致哈希函数生成特定输出的输入消息。相反，冲突攻击会发现具有相同哈希的两条消息，但攻击者无法选择消息的内容。[Crypto2004]中记录了针对MD4、MD5、HAVAL-128和RIPEMD的可行碰撞攻击。
The ability to produce a collision does not currently introduce any obvious or known attacks on routing protocols. Pre-image attacks have the potential to cause problems in the future; however, due to the message length, there are serious limitations to the feasibility of mounting such an attack.
产生冲突的能力目前不会对路由协议引入任何明显或已知的攻击。图像前攻击有可能在将来造成问题；但是，由于消息长度的原因，发起此类攻击的可行性存在严重限制。
Protocols themselves have some built-in protection against collision attacks. This is because a lot of values for fields in a protocol packet are invalid or will produce an unusable packet. For example, in OSPF the Link State Advertisement (LSA) type can be from 1 to 11. Any other value in the field will result in the packet being discarded.
协议本身具有一些针对冲突攻击的内置保护。这是因为协议数据包中的许多字段值无效或将生成不可用的数据包。例如，在OSPF中，链路状态广告（LSA）类型可以是1到11。该字段中的任何其他值都将导致丢弃该数据包。
Assume two packets M and M' are generated and have the same hash. The above condition will further reduce the ability to produce a message that is also a correct message from the protocol perspective, as a lot of potential values are themselves not valid.
假设生成了两个数据包M和M’，并且具有相同的散列。上述情况将进一步降低生成从协议角度也是正确消息的消息的能力，因为许多潜在值本身无效。
There are published concerns about the overall strength of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those published concerns apply to the use of MD5 in other modes (e.g., use of MD5 X.509v3/PKIX digital certificates), they are not an attack upon Keyed MD5 and Hash-based Message Authentication Code MD5 (HMAC-MD5), which is what the current routing protocols have specified. There are also published concerns about the Secure Hash Algorithm (SHA) algorithm ([Wang05], [Philip01], [Prav01], [Prav02], [Arjen05]) and also concerns about the MD5 and SHA algorithms in the HMAC [RFC2104] mode ([RR07], [RR08]). The National Institute of Standards and Technology (NIST) will be supporting HMAC-SHA-1 even after 2010 [NISTHmacSHA], whereas it will drop support for SHA-1 in digital signatures. NIST also recommends application and protocol designers move to the SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) for all new applications and protocols.
有人对MD5算法的整体强度表示担忧（[Dobb96a]、[Dobb96b]、[Wang04]）。虽然这些公开的关注点适用于在其他模式下使用MD5（例如，使用MD5 X.509v3/PKIX数字证书），但它们不是对密钥MD5和基于散列的消息认证码MD5（HMAC-MD5）的攻击，这是当前路由协议所规定的。还发布了关于安全哈希算法（SHA）算法（[Wang05]、[Philip01]、[Prav01]、[Prav02]、[Arjen05]）的关注点，以及关于HMAC[RFC2104]模式下的MD5和SHA算法（[RR07]、[RR08]）。国家标准与技术研究所（NIST）将在2010年之后支持HMAC-SHA-1[NISTHmacSHA]，而它将在数字签名中放弃对SHA-1的支持。NIST还建议应用程序和协议设计者为所有新的应用程序和协议使用SHA-2系列散列函数（即SHA-224、SHA-256、SHA-384和SHA-512）。
However, as explained above, such attacks are currently not applicable to the routing protocols. Separately, some organizations (e.g., the US government) prefer NIST algorithms, such as the SHA family, over other algorithms (like MD5) for local policy reasons.
然而，如上所述，此类攻击目前不适用于路由协议。另外，出于当地政策原因，一些组织（如美国政府）更喜欢NIST算法，如SHA系列，而不是其他算法（如MD5）。
OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets. MD5 keys are manually configured. The OSPF packet header includes an authentication type field as well as 64 bits of data for use by the appropriate authentication scheme. OSPF also provides for a non-decreasing sequence number to be included in each OSPF protocol packet to protect against replay attacks.
OSPF[RFC2328]描述了对OSPF数据包使用MD5摘要。MD5密钥是手动配置的。OSPF分组报头包括认证类型字段以及供适当认证方案使用的64位数据。OSPF还为每个OSPF协议包提供了一个非递减序列号，以防止重播攻击。
"OSPF with Digital Signatures" [RFC2154] is an Experimental RFC that describes extensions to OSPF to digitally sign its Link State Advertisements (LSAs). It is believed that if stronger authentication and security is required, then OSPF (and the other routing protocols) must migrate to using full digital signatures. Doing this would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, and thereby provide much stronger integrity protection for the OSPF routing domain. However, since there have been no deployments, there is precious little operational experience with this specification, and hence it is not covered in this document.
“带数字签名的OSPF”[RFC2154]是一种实验性RFC，它描述了对OSPF的扩展，以对其链路状态广告（LSA）进行数字签名。人们认为，如果需要更强的身份验证和安全性，那么OSPF（和其他路由协议）必须迁移到使用完整的数字签名。这样做将能够精确地验证发起每个OSPF链路状态公告的OSPF路由器，从而为OSPF路由域提供更强的完整性保护。但是，由于没有部署，因此本规范的操作经验很少，因此本文档中没有介绍。
According to the OSPF specification [RFC2328], digests are applied to packets transmitted between adjacent neighbors, rather than being applied to the routing information originated by a router (digests are not applied at the LSA level, but rather at the packet level). [RFC2328] states that any set of OSPF routers adjacent across a single link may use a different key to build MD5 digests than the key used to build MD5 digests on any other link. Thus, MD5 keys may be configured, and changed, on a per-link basis in an OSPF network.
根据OSPF规范[RFC2328]，摘要应用于相邻邻居之间传输的分组，而不是应用于由路由器发起的路由信息（摘要不应用于LSA级别，而是应用于分组级别）。[RFC2328]指出，在单个链路上相邻的任何一组OSPF路由器可以使用不同的密钥来构建MD5摘要，而不是在任何其他链路上构建MD5摘要。因此，可以在OSPF网络中基于每条链路配置和更改MD5密钥。
OSPF does not specify a mechanism to negotiate keys, nor does it specify any mechanism to negotiate the hash algorithms to be used.
OSPF没有指定协商密钥的机制，也没有指定协商要使用的哈希算法的任何机制。
With the proliferation of the number of hash algorithms, as well as the need to continuously upgrade the algorithms, manually configuring the information becomes very tedious. It should also be noted that rekeying OSPF requires coordination among the adjacent routers.
随着散列算法数量的激增，以及算法不断升级的需要，手动配置信息变得非常繁琐。还应注意，重新设置OSPF密钥需要相邻路由器之间的协调。
While OSPF provides relatively strong protection through the inclusion of MD5 digests, with additional data and sequence numbers in transmitted packets, there are still attacks against OSPF:
虽然OSPF通过包含MD5摘要（在传输的数据包中包含额外的数据和序列号）提供了相对强大的保护，但仍然存在针对OSPF的攻击：
o The sequence number is initialized to zero when forming an adjacency with a newly discovered neighbor. When an adjacency is brought down, the sequence number is also set to zero. If the cryptographically protected packets of a router that is brought down (for administrative or other reasons) are replayed by a malicious router, traffic could be forced through the malicious router. A malicious router might then induce routing loops, or intercept or blackhole the traffic.
o 当与新发现的邻居形成邻接时，序列号初始化为零。当邻接关系降低时，序列号也设置为零。如果受到密码保护的路由器数据包（出于管理或其他原因）被恶意路由器重播，则流量可能会被迫通过恶意路由器。恶意路由器可能会导致路由循环，或拦截或堵塞流量。
o OSPF allows multiple packets with the same sequence number. This means that it's possible to replay the same packet many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received. The Hello interval, which is unknown, determines the attack window.
o OSPF允许具有相同序列号的多个数据包。这意味着在发送下一个合法数据包之前，可以多次重播同一数据包。攻击者可以重复重新发送相同的数据包，直到下一个Hello数据包被发送和接收。未知的Hello间隔决定了攻击窗口。
o OSPF does not require the use of any particular hash algorithm; however, only the use of MD5 digests for authentication and replay protection is specified in RFC 2328. Most OSPF implementations only support MD5 in addition to Null and Simple Password authentication.
o OSPF不需要使用任何特定的哈希算法；但是，RFC2328中只指定使用MD5摘要进行身份验证和重播保护。除了空密码和简单密码认证之外，大多数OSPF实现只支持MD5。
Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of MD5 in routing protocols, it is prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5709] adds support for using SHA-1 and SHA-2 with the HMAC construct for OSPF.
最近，MD5和SHA-1散列函数的抗冲突特性的局限性被发现；[RFC4270]总结了这些发现。有人攻击使用MD5作为散列；虽然这些攻击不直接适用于在路由协议中使用MD5，但谨慎的做法是提供其他选项。出于这个原因，不鼓励普遍使用这些算法，[RFC5709]增加了对使用SHA-1和SHA-2以及OSPF的HMAC构造的支持。
o OSPF on a broadcast network shares the same key between all neighbors on that broadcast network. Some OSPF packets are sent to a multicast address.
o 广播网络上的OSPF在该广播网络上的所有邻居之间共享相同的密钥。一些OSPF数据包被发送到多播地址。
Spoofing by any malicious neighbor possessing credentials or replayable packets is therefore very easy. Possession of the key itself is used as an identity validation, and no other identity check is used. A malicious neighbor could send a packet, forging the identity of the sender as being from another neighbor. There would be no way in which the victim could distinguish the identity of the packet sender.
因此，任何拥有凭据或可重放数据包的恶意邻居都很容易进行欺骗。拥有密钥本身被用作身份验证，不使用其他身份检查。恶意邻居可以发送数据包，伪造发送者的身份作为来自另一个邻居的身份。受害者无法识别数据包发送者的身份。
o In some OSPF implementations, neighbors on broadcast, non-broadcast multi-access (NBMA), and point-to-multipoint networks are identified by the IP address in the IP header. The IP header is not covered by the MAC in the cryptographic authentication scheme as described in RFC 2328, and an attack can be made to exploit this omission.
o 在一些OSPF实现中，广播、非广播多址（NBMA）和点对多点网络上的邻居由IP报头中的IP地址标识。如RFC 2328中所述，在加密身份验证方案中，IP报头不被MAC覆盖，可以进行攻击以利用此遗漏。
Assume the following scenario.
假设以下场景。
R1 sends an authenticated HELLO to R2. This HELLO is captured and replayed back to R1. The source IP in the IP header of the replayed packet is changed to that of R2.
R1向R2发送经过身份验证的HELLO。此HELLO被捕获并重放回R1。重播数据包的IP报头中的源IP更改为R2的源IP。
R1, not finding itself in the HELLO, would deduce that the connection is not bidirectional and would bring down the adjacency.
R1在HELLO中找不到自己，会推断连接不是双向的，并且会降低相邻性。
OSPFv3 [RFC5340] relies on the IP Authentication Header (AH) [RFC4302] and the IP Encapsulating Security Payload (ESP) [RFC4303] to cryptographically sign routing information passed between routers.
OSPFv3[RFC5340]依赖IP认证头（AH）[RFC4302]和IP封装安全有效负载（ESP）[RFC4303]对路由器之间传递的路由信息进行加密签名。
When using ESP, the null encryption algorithm [RFC2410] is used, so the data carried in the OSPFv3 packets is signed, but not encrypted. This provides data origin authentication for adjacent routers, and data integrity (which gives the assurance that the data transmitted by a router has not changed in transit). However, it does not provide confidentiality of the information transmitted; this is acceptable because the privacy of the information being carried in the routing protocols need not be kept secret.
当使用ESP时，使用空加密算法[RFC2410]，因此OSPFv3数据包中携带的数据被签名，但不加密。这为相邻路由器提供了数据源身份验证和数据完整性（确保路由器传输的数据在传输过程中未发生变化）。但是，它不为传输的信息保密；这是可以接受的，因为路由协议中携带的信息的隐私不需要保密。
"Authentication/Confidentiality for OSPFv3" [RFC4552] mandates the use of ESP with null encryption for authentication and also does encourage the use of confidentiality to protect the privacy of the routing information transmitted, using ESP encryption. However, it only specifies the use of manual keying of routing information as discussed in the following section.
“OSPFv3的身份验证/机密性”[RFC4552]强制使用带空加密的ESP进行身份验证，并鼓励使用机密性保护使用ESP加密传输的路由信息的隐私。但是，它仅指定对路由信息使用手动键控，如下一节所述。
The OSPFv3 security document ("Authentication/Confidentiality for OSPFv3" [RFC4552]) discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as IKEv2 [RFC4306]. The primary problem is the lack of a suitable key management mechanism, as OSPF adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the
OSPFv3安全文档（“OSPFv3的身份验证/机密性”[RFC4552]）详细讨论了使用手动配置密钥而不是像IKEv2[RFC4306]这样的自动密钥管理协议背后的原因。主要问题是缺乏合适的密钥管理机制，因为OSPF邻接是在一对多的基础上形成的，并且大多数密钥管理机制是为一对一通信模型设计的。这迫使
system administrator to use manually configured security associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services.
系统管理员使用手动配置的安全关联（SA）和加密密钥来提供身份验证和（如果需要）保密服务。
Regarding replay protection, [RFC4552] states that:
关于重播保护，[RFC4552]指出：
Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.
由于在使用手动键控时无法使用当前标准提供完整的重播保护，因此建议的解决方案将无法提供针对重播攻击的保护。
In the OSPFv3 case, the primary administrative issue with manually configured SAs and keys is the management issue -- maintaining shared sets of keys on all routers within a network. As with OSPFv2, rekeying is an infrequent event requiring coordination. [RFC4552] does not require that all OSPFv3 routers have the same key configured for every neighbor, so each set of neighbors connected to a given link could have a different key configured. While this makes it easier to change the keys (by forcing the system administrator to only change the keys on the routers on a single link), the process of manual configuration for all the routers in a network to change the keys used for OSPFv3 digests and confidentiality on a periodic basis can be difficult.
在OSPFv3案例中，手动配置的SA和密钥的主要管理问题是管理问题——在网络中的所有路由器上维护共享密钥集。与OSPFv2一样，密钥更新是一种不经常发生的需要协调的事件。[RFC4552]不要求所有OSPFv3路由器为每个邻居配置相同的密钥，因此连接到给定链路的每组邻居可以配置不同的密钥。虽然这使得更改密钥更容易（通过强制系统管理员仅更改单个链路上路由器上的密钥），但为网络中的所有路由器手动配置以定期更改用于OSPFv3摘要和机密性的密钥的过程可能会很困难。
The primary technical concern with the current specifications for OSPFv3 is that when manual SA and key management is used as specified in "Sequence Number Generation", Section 3.3.2 of [RFC4302]: "The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management". Replaying OSPFv3 packets can induce several failures in a network, including:
当前OSPFv3规范的主要技术问题是，当按照[RFC4302]第3.3.2节“序列号生成”中的规定使用手动SA和密钥管理时：“除非接收方另有通知，否则发送方假定默认启用了防重放（见第3.4.3节）或者如果SA是使用手动密钥管理配置的”。重放OSPFv3数据包可能会导致网络中出现多个故障，包括：
o Replaying Hello packets with an empty neighbor list can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
o 使用空邻居列表重放Hello数据包可能会导致与发送路由器的所有邻居邻接被重置，从而中断网络通信。
o Replaying Hello packets from early in the designated router election process on broadcast links can cause all the neighbor adjacencies with the sending router to be reset, disrupting network communications.
o 在广播链路上重播指定路由器选择过程早期的Hello数据包会导致与发送路由器的所有邻居邻接被重置，从而中断网络通信。
o Replaying database description (DB-Description) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
o 重放数据库描述（DB description）数据包可能会导致与发送路由器的所有完整邻居邻接被重置，从而中断网络通信。
o Replaying link state request (LS-Request) packets can cause all FULL neighbor adjacencies with the sending router to be reset, disrupting network communications.
o 重放链路状态请求（LS请求）数据包可能会导致与发送路由器的所有完整邻居邻接被重置，从而中断网络通信。
o Capturing a full adjacency process (from two-way all the way to FULL state), and then replaying this process when the router is no longer attached can cause a false adjacency to be formed, allowing an attacker to attract traffic.
o 捕获完全邻接过程（从双向一直到完全状态），然后在路由器不再连接时重播该过程可能导致形成虚假邻接，从而允许攻击者吸引流量。
o OSPFv3 on a broadcast network shares the same key between all neighbors on that network. Some OSPF packets are sent to a multicast address.
o 广播网络上的OSPFv3在该网络上的所有邻居之间共享相同的密钥。一些OSPF数据包被发送到多播地址。
Spoofing by a malicious neighbor is very easy. Possession of the key itself is used as an identity check. There is no other identity check used. A neighbor could send a packet specifying the packet came from some other neighbor and there would be no way in which the attacked router could figure out the identity of the packet sender.
恶意邻居的欺骗非常容易。拥有钥匙本身被用作身份检查。没有使用其他身份检查。邻居可以发送一个数据包，指定该数据包来自其他邻居，而被攻击的路由器无法识别数据包发送者的身份。
Integrated IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as described in [RFC5304], and has recently been extended to provide support for using the HMAC construct along with the SHA family of cryptographic hash functions [RFC5310]. There is no provision within IS-IS to encrypt the body of a routing protocol message.
集成IS-IS[RFC1195]使用HMAC-MD5身份验证和手动键控，如[RFC5304]中所述，并且最近已扩展为支持使用HMAC构造以及SHA系列加密哈希函数[RFC5310]。is-is中没有对路由协议消息体进行加密的规定。
[RFC5304] states that each Link State Protocol Data Unit (LSP) generated by an intermediate system is signed with the HMAC-MD5 algorithm using a key manually defined by the network administrator. Since authentication is performed on the LSPs transmitted by an intermediate system, rather than on the packets transmitted to a specific neighbor, it is implied that all the intermediate systems within a single flooding domain must be configured with the same key in order for authentication to work correctly.
[RFC5304]指出，中间系统生成的每个链路状态协议数据单元（LSP）都使用网络管理员手动定义的密钥，使用HMAC-MD5算法进行签名。由于认证是在由中间系统传输的lsp上执行的，而不是在传输到特定邻居的分组上执行的，这意味着单个泛洪域内的所有中间系统必须配置相同的密钥，以便认证能够正确工作。
The initial configuration of manual keys for authentication within an IS-IS network is simplified by a state where LSPs containing HMAC-MD5/HMAC-SHA authentication TLVs are accepted by intermediate systems without the keys, but the digest is not validated. Once keys are configured on all routers, changing those keys becomes much more difficult.
IS-IS网络内用于身份验证的手动密钥的初始配置简化为一种状态，即中间系统接受包含HMAC-MD5/HMAC-SHA身份验证TLV的LSP，但不验证摘要。一旦在所有路由器上配置了密钥，更改这些密钥就变得更加困难。
IS-IS [RFC1195] does not specify a mechanism to negotiate keys, nor does it specify any mechanism to negotiate the hash algorithms to be used.
IS-IS[RFC1195]未指定协商密钥的机制，也未指定协商要使用的哈希算法的任何机制。
With the proliferation of available hash algorithms, as well as the need to upgrade the algorithms, manual configuration requires coordination among intermediate systems, which can become tedious.
随着可用哈希算法的激增，以及算法升级的需要，手动配置需要中间系统之间的协调，这可能会变得单调乏味。
[RFC5304] states: "This mechanism does not prevent replay attacks; however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information".
[RFC5304]指出：“该机制不会阻止重播攻击；但是，在大多数情况下，此类攻击会触发IS-IS协议中的现有机制，从而有效地拒绝旧信息”。
The few cases where existing mechanisms in the IS-IS protocol would not effectively reject old information are: - the Hello packets or the IS-IS Hellos (IIHs) that are used to discover neighbors, and - the Sequence Number Packets (SNPs).
IS-IS协议中现有机制无法有效拒绝旧信息的少数情况是：-用于发现邻居的Hello数据包或IS-IS Hellos（IIHs），以及-序列号数据包（SNP）。
As described in IS-IS [RFC1195], a list of known neighbors is included in each Hello transmitted by an intermediate system to ensure two-way communications with any specific neighbor before exchanging link state databases.
如IS-IS[RFC1195]中所述，在中间系统传输的每个Hello中包括已知邻居的列表，以确保在交换链路状态数据库之前与任何特定邻居进行双向通信。
IS-IS does not provide a sequence number. IS-IS packets are vulnerable to replay attacks; any packet can be replayed at any point of time. So long as the keys used are the same, protocol elements that would not be rejected will affect existing sessions.
IS-IS不提供序列号。IS-IS数据包容易受到重播攻击；任何数据包都可以在任何时间点重播。只要使用的密钥相同，不会被拒绝的协议元素将影响现有会话。
A Hello packet containing a digest within a TLV and an empty neighbor list could be replayed, resulting in all adjacencies with the original transmitting intermediate system to be restarted.
包含TLV内摘要和空邻居列表的Hello数据包可以被重播，从而导致重新启动与原始传输中间系统的所有邻接。
A replay of an old Complete Sequence Number Packet (CSNP) could cause LSPs to be flooded, resulting in an LSP storm.
旧完整序列号数据包（CSNP）的重播可能导致LSP被淹没，从而导致LSP风暴。
IS-IS specifies the use of the HMAC-MD5 and HMAC-SHA-1 to protect IS-IS packets.
IS-IS指定使用HMAC-MD5和HMAC-SHA-1保护IS-IS数据包。
IS-IS does not have a notion of Key ID. During key rollover, each message received has to be checked for integrity against all keys that are valid. A denial-of-service (DoS) attack may be induced by sending IS-IS packets with random hashes. This will cause the IS-IS packet to be checked for authentication with all possible keys,
IS-IS没有密钥ID的概念。在密钥翻转期间，必须对照所有有效密钥检查收到的每条消息的完整性。通过使用随机散列发送IS-IS数据包可能会引发拒绝服务（DoS）攻击。这将导致使用所有可能的密钥检查IS-IS数据包的身份验证，
increasing the amount of processing required. This issue, however, has been fixed in the recent [RFC5310], which introduces the concept of Key IDs in IS-IS.
增加所需的处理量。然而，这个问题在最近的[RFC5310]中得到了解决，它在IS-IS中引入了密钥ID的概念。
Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of HMAC-MD5 in IS-IS, it is prudent to have other options available. For this reason, the general use of these algorithms should be discouraged, and [RFC5310] adds support for using HMAC-SHA with IS-IS.
最近，MD5和SHA-1散列函数的抗冲突特性的局限性被发现；[RFC4270]总结了这些发现。有人攻击使用MD5作为散列；虽然这些攻击不直接适用于IS-IS中HMAC-MD5的使用，但谨慎的做法是提供其他选项。出于这个原因，不鼓励普遍使用这些算法，[RFC5310]增加了对将HMAC-SHA与IS-IS结合使用的支持。
IS-IS on a broadcast network shares the same key between all neighbors on that network.
广播网络上的IS-IS在该网络上的所有邻居之间共享同一密钥。
This makes spoofing by a malicious neighbor easy since IS-IS packets are sent to a link-layer multicast address. Possession of the key itself is used as an authorization check. A neighbor could send a packet spoofing the identity of a neighbor, and there would be no way in which the attacked router could discern the identity of the malicious packet sender.
这使得恶意邻居很容易进行欺骗，因为IS-IS数据包被发送到链路层多播地址。拥有密钥本身被用作授权检查。邻居可以发送伪造邻居身份的数据包，而被攻击的路由器无法识别恶意数据包发送者的身份。
The Remaining Lifetime field in the LSP is not covered by the authentication. An IS-IS router can receive its own self-generated LSP segment with zero lifetime remaining. In that case, if it has a copy with non-zero lifetime, it purges that LSP, i.e., it increments the current sequence number and floods all the segments again. This is much worse in IS-IS than in OSPF because there is only one LSP other than the pseudonode LSPs for the LANs on which the IS-IS router is the Designated Intermediate System (DIS).
LSP中的剩余生存期字段不包含在身份验证中。IS-IS路由器可以接收其自己生成的LSP段，剩余寿命为零。在这种情况下，如果它有一个具有非零生存期的副本，它将清除该LSP，即，它增加当前序列号并再次泛洪所有段。is-is中的情况比OSPF中的情况更糟糕，因为对于is-is路由器是指定中间系统（DIS）的LAN，除了伪节点LSP之外，只有一个LSP。
In this way, an attacker can force the router to flood all segments -- potentially a large number if the number of routes is large. It also causes the sequence number of all the LSPs to increase fast. If the sequence number increases to the maximum (0xFFFFFFFF), the IS-IS process must shut down for around 20 minutes (the product of MaxAge + ZeroAgeLifetime) to allow the old LSPs to age out of all the router databases.
通过这种方式，攻击者可以强制路由器淹没所有段——如果路由数量很大，则可能是一个很大的数目。它还导致所有LSP的序列号快速增加。如果序列号增加到最大值（0xFFFFFF），IS-IS进程必须关闭约20分钟（MaxAge+ZeroAgeLifetime的乘积），以允许旧LSP从所有路由器数据库中老化。
BGP-4 [RFC4271] uses TCP [RFC0793] for transporting routing information between BGP speakers that have formed an adjacency.
BGP-4[RFC4271]使用TCP[RFC0793]在形成邻接的BGP扬声器之间传输路由信息。
[RFC2385] describes the use of the TCP MD5 digest option for providing packet origin authentication and data integrity protection of BGP packets. [RFC3562] provides suggestions for choosing the key
[RFC2385]描述了使用TCP MD5摘要选项来提供BGP数据包的数据源身份验证和数据完整性保护。[RFC3562]提供选择密钥的建议
length of the ad hoc Keyed MD5 mechanism specified in [RFC2385]. There is no provision for confidentiality for any of these BGP messages.
[RFC2385]中指定的特殊密钥MD5机制的长度。对于这些BGP消息，没有任何保密规定。
TCP MD5 [RFC2385] has recently been obsoleted by a new TCP Authentication Option (TCP-AO) [RFC5925]. [RFC5925] specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details than TCP-MD5 on the association of security with TCP connections. It allows rekeying during a TCP connection, assuming that an out-of-band protocol or manual mechanism provides the new keys. Note that TCP MD5 does not preclude rekeying during a connection, but does not require its support either. Further, TCP-AO supports key changes with zero segment loss, whereas key changes in TCP MD5 can lose segments in transit during the changeover or require trying multiple keys on each received segment during key use overlap because TCP MD5 lacks an explicit Key ID. Although TCP recovers lost segments through retransmission, loss can have a substantial impact on performance.
TCP MD5[RFC2385]最近被新的TCP身份验证选项（TCP-AO）[RFC5925]淘汰。[RFC5925]指定使用更强的消息身份验证码（MAC），即使对于长寿命的TCP连接也可以防止重播，并提供了比TCP-MD5更多的关于安全性与TCP连接关联的详细信息。它允许在TCP连接期间重新设置密钥，前提是带外协议或手动机制提供了新密钥。请注意，TCP MD5并不排除在连接过程中重新设置密钥，但也不需要它的支持。此外，TCP-AO支持零段丢失的密钥更改，而TCP MD5中的密钥更改可能会在转换过程中丢失段，或者在密钥使用重叠期间需要在每个接收段上尝试多个密钥，因为TCP MD5缺少明确的密钥ID。尽管TCP通过重传恢复丢失的段，损失可能会对性能产生重大影响。
However, this document covers only TCP MD5, as all current deployments are still using BGP with TCP MD5 and have not upgraded to [RFC5925]. There isn't enough operational experience present to evaluate the technical and management issues with this proposal yet.
但是，本文档仅涉及TCP MD5，因为所有当前部署仍然使用BGP和TCP MD5，并且尚未升级到[RFC5925]。目前还没有足够的运营经验来评估该提案的技术和管理问题。
Compared to previously described IGP protocols, BGP has additional exposure due to the nature of the environment where it is typically used -- namely, between autonomous networks (under different administrative control). While routers running interior gateway protocols may all be configured with the same administrative authority, two BGP peers may be in different administrative domains, having different policies for key strength, rollover frequency, etc. An autonomous system must often support a large number of keys at different BGP boundaries, as each connecting AS represents a different administrative entity. In practice, once set, shared secrets between BGP peers are rarely, if ever, changed.
与前面描述的IGP协议相比，由于BGP通常使用的环境的性质，即自治网络（在不同的管理控制下）之间，BGP具有额外的暴露。虽然运行内部网关协议的路由器可能都配置有相同的管理权限，但两个BGP对等点可能位于不同的管理域，具有不同的密钥强度、滚动频率等策略。自治系统通常必须在不同的BGP边界上支持大量密钥，每个连接as代表一个不同的管理实体。在实践中，一旦设置，BGP对等方之间的共享秘密几乎不会改变。
Each pair of BGP speakers forming a peering may have a different MD5 shared key that facilitates the independent configuration and changing of keys across a large-scale network. Manual configuration and maintenance of cryptographic keys across all BGP sessions is a challenge in any large-scale environment.
形成对等的每对BGP扬声器可以具有不同的MD5共享密钥，这有助于在大规模网络中独立配置和更改密钥。在任何大规模环境中，在所有BGP会话中手动配置和维护加密密钥都是一项挑战。
Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup, in order to allow for MD5 keys to be changed with minimal impact on
大多数BGP实现将接受具有坏摘要的BGP数据包，直到对等启动时BGP对等方之间协商的保持时间间隔为止，以便允许更改MD5密钥，而对
operation of the network. This technique does, however, allow some short period of time during which an attacker may inject BGP packets with false MD5 digests into the network and can expect those packets to be accepted, even though the MD5 digests are not valid.
网络的运作。然而，这种技术允许攻击者在短时间内将带有虚假MD5摘要的BGP数据包注入网络，并期望这些数据包被接受，即使MD5摘要无效。
BGP relies on TCP [RFC0793] for transporting data between BGP speakers. BGP can rely on TCP's protection against data corruption and replay to preclude replay attacks against BGP sessions. A great deal of research has gone into the feasibility of an attacker overcoming these protections, including [TcpWindow] and [Conv01]. Most router and operating system (OS) vendors have modified their TCP implementations to resolve the security vulnerabilities described in these references, where possible.
BGP依靠TCP[RFC0793]在BGP扬声器之间传输数据。BGP可以依靠TCP对数据损坏和重播的保护来防止针对BGP会话的重播攻击。许多研究都在探讨攻击者克服这些保护的可行性，包括[TcpWindow]和[Conv01]。大多数路由器和操作系统（OS）供应商已修改了其TCP实现，以尽可能解决这些参考资料中描述的安全漏洞。
As mentioned earlier, MD5 is vulnerable to collision attacks and can be attacked through several means, such as those explored in [Wang04].
如前所述，MD5易受碰撞攻击，可以通过多种方式进行攻击，如[Wang04]中所述。
Though it can be argued that the collision attacks do not have a practical application in this scenario, the use of MD5 should be discouraged.
虽然可以说碰撞攻击在这种情况下没有实际应用，但应该不鼓励使用MD5。
Routers performing cryptographic processing of packets in software may be exposed to additional opportunities for DoS attacks. An attacker may be able to transmit enough spoofed traffic with false digests that the router's processor and memory resources are consumed, causing the router to be unable to perform normal processing. This exposure is particularly problematic between routers not under unified administrative control.
在软件中对数据包进行加密处理的路由器可能会面临DoS攻击的额外机会。攻击者可能通过虚假摘要传输足够多的伪造流量，从而消耗路由器的处理器和内存资源，导致路由器无法执行正常处理。这种暴露在不受统一管理控制的路由器之间尤其有问题。
The initial version of RIP was specified in STD 34 [RFC1058]. This version did not provide for any authentication or authorization of routing data, and thus was vulnerable to any of a number of attacks against routing protocols. This limitation was one reason why this protocol was moved to Historic status [RFC1923].
标准34[RFC1058]中规定了RIP的初始版本。此版本不提供路由数据的任何身份验证或授权，因此容易受到针对路由协议的任何攻击。该限制是将该协议移至历史状态[RFC1923]的原因之一。
RIPv2, originally specified in [RFC1388], then [RFC1723], was finalized in STD 56 [RFC2453]. This version of the protocol provides for authenticating packets with a digest. The details thereof have initially been provided in "RIP-2 MD5 Authentication" [RFC2082]; "RIPv2 Cryptographic Authentication" [RFC4822] obsoletes [RFC2082] and adds details of how the SHA family of hash algorithms can be used to protect RIPv2. [RFC2082] only specified the use of Keyed MD5.
RIPv2最初在[RFC1388]中规定，然后在[RFC1723]中规定，最终在STD 56[RFC2453]中确定。此版本的协议提供了使用摘要对数据包进行身份验证的功能。其细节最初已在“RIP-2 MD5认证”[RFC2082]中提供；“RIPv2加密身份验证”[RFC4822]淘汰了[RFC2082]，并添加了有关如何使用SHA系列哈希算法来保护RIPv2的详细信息。[RFC2082]仅指定使用键控MD5。
o The sequence number used by a router is initialized to zero at startup, and is also set to zero whenever the neighbor is brought down. If the cryptographically protected packets of a router that is brought down (for administrative or other reasons) are stored by a malicious router, the new router could replay the packets from the previous session, thus forcing traffic through the malicious router. Dropping of such packets by the router could result in blackholes. Also, forwarding wrong packets could result in routing loops.
o 路由器使用的序列号在启动时被初始化为零，并且在邻居停机时也被设置为零。如果（出于管理或其他原因）被关闭的路由器的受密码保护的数据包被恶意路由器存储，则新路由器可能会重播上一个会话中的数据包，从而迫使流量通过恶意路由器。路由器丢弃这些数据包可能导致黑洞。此外，转发错误的数据包可能导致路由循环。
o RIPv2 allows multiple packets with the same sequence number. This could mean the same packet may be replayed many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received, which means the Hello interval therefore determines the attack window.
o RIPv2允许具有相同序列号的多个数据包。这可能意味着在发送下一个合法数据包之前，同一数据包可能会被重放多次。攻击者可以重复重新发送相同的数据包，直到下一个Hello数据包被发送和接收，这意味着Hello间隔因此决定了攻击窗口。
o RIPv2 [RFC2453] did not specify the use of any particular hash algorithm. RFC 4822 introduced HMAC-SHA1 as mandatory to implement, along with Keyed MD5 as specified in [RFC2082]. Support for Keyed MD5 was mandated to ensure compatability with legacy implementations.
o RIPv2[RFC2453]未指定任何特定哈希算法的使用。RFC 4822引入了HMAC-SHA1作为强制实施，以及[RFC2082]中规定的键控MD5。对键控MD5的支持是为了确保与遗留实现的兼容性。
o "RIPv2 Cryptographic Authentication" [RFC4822] does not cover the UDP and the IP headers. It is therefore possible for an attacker to modify some fields in the above headers without routers becoming aware of it.
o “RIPv2加密身份验证”[RFC4822]不包括UDP和IP头。因此，攻击者可以在路由器不知道的情况下修改上述报头中的某些字段。
There is limited exposure to modification of the UDP header, as the RIP protocol uses only it to compute the length of the RIP packet. Changes introduced in the UDP header would cause RIP authentication to fail the RIP authentication, thereby limiting exposure.
由于RIP协议仅使用UDP报头来计算RIP数据包的长度，因此修改UDP报头的风险有限。UDP报头中引入的更改将导致RIP身份验证失败，从而限制暴露。
RIP uses the source IP address from the IP header to determine which RIP neighbor it has learnt the RIP Update from. Changing the source IP address can be used by an attacker to disrupt the RIP routing sessions between two routers R1 and R2, as shown in the following examples.
RIP使用来自IP报头的源IP地址来确定它从哪个RIP邻居那里学习RIP更新。攻击者可以使用更改源IP地址来中断两个路由器R1和R2之间的RIP路由会话，如以下示例所示。
Scenario 1:
情景1：
R1 sends an authenticated RIP message to R2 with a cryptographic sequence number X.
R1向R2发送一条经过身份验证的RIP消息，其中包含加密序列号X。
The attacker then needs a packet with a higher sequence number originated by R2 either, from this session or from some earlier session.
然后，攻击者需要一个序列号更高的数据包，该数据包由R2从该会话或某个早期会话发起。
The attacker can then replay this packet to R2 by changing the source IP to that of R1.
然后，攻击者可以通过将源IP更改为R1的IP，将此数据包重播给R2。
R2 would then no longer accept any more RIP Updates from R1, as those would have a lower cryptographic sequence number. After 180 seconds (or less), R2 would consider R1 timed out and bring down the RIP session.
R2将不再接受来自R1的任何更多RIP更新，因为这些更新将具有更低的加密序列号。在180秒（或更少）之后，R2将考虑R1超时并降低RIP会话。
Scenario 2:
情景2：
R1 announces a route with cost C1 to R2. This packet can be captured by an attacker. Later, if this cost changes and R1 announces this with a different cost C2, the attacker can replay the captured packet, modifying the source IP to a new arbitrary IP address, thereby masquerading as a different router.
R1宣布成本为C1到R2的路线。攻击者可以捕获此数据包。稍后，如果该代价发生变化，并且R1以不同的代价C2宣布，则攻击者可以重播捕获的数据包，将源IP修改为新的任意IP地址，从而伪装成不同的路由器。
R2 will accept this route and the router as a new gateway, and R2 would then use the non-existent router as a next hop for that network. This would only be effective if the cost C1 is less than C2.
R2将接受此路由和路由器作为新网关，然后R2将使用不存在的路由器作为该网络的下一跳。这只有在成本C1小于C2时才有效。
BFD is specified in [RFC5880]. Extensions to BFD for multihop [RFC5883] and single hop [RFC5881] are defined for IPv4 and IPv6. It is designed to detect failure with the forwarding plane next hop.
[RFC5880]中规定了BFD。为IPv4和IPv6定义了多跳[RFC5883]和单跳[RFC5881]的BFD扩展。它被设计用于检测转发平面下一跳的故障。
The BFD base specification specifies an optional authentication mechanism that can be used by the receiver of a packet to be able to authenticate the source of the packet. It relies on the facts that the keys are shared between the peers and no mechanism is defined for the actual key generation.
BFD基本规范指定了一种可选的身份验证机制，该机制可由数据包的接收方使用，以便能够对数据包的源进行身份验证。它依赖于密钥在对等方之间共享的事实，并且没有为实际密钥生成定义任何机制。
o The level of security provided is based on the Authentication Type used. However, the authentication algorithms defined are MD5 or SHA-1 based. As mentioned earlier, MD5 and SHA-1 are both known to be vulnerable to collision attacks.
o 提供的安全级别取决于所使用的身份验证类型。但是，定义的身份验证算法是基于MD5或SHA-1的。如前所述，MD5和SHA-1都很容易受到碰撞攻击。
o The BFD specification mentions mechanisms to allow for the change of authentication state based on the state of a received packet. This can cause a denial-of-service attack where a malicious authenticated packet (stored from a past session) can be relayed
o BFD规范提到了允许基于所接收数据包的状态改变认证状态的机制。这可能会导致拒绝服务攻击，其中可以中继恶意的经过身份验证的数据包（存储自过去的会话）
over a session that does not use authentication. This causes one end to assume that authentication is enabled at the other end, and hence the BFD adjacency is dropped. This would be a harder attack to put forth when meticulously keyed authentication is in use.
通过不使用身份验证的会话。这导致一端假定在另一端启用了身份验证，因此BFD邻接被丢弃。在使用精心设置密钥的身份验证时，这将是更难发起的攻击。
o BFD works on microsecond timers. When malicious packets are sent at short intervals, with the authentication bit set, it can cause a DoS attack.
o BFD工作在微秒计时器上。当短时间间隔发送恶意数据包并设置身份验证位时，可能会导致DoS攻击。
o BFD allows a mode called the echo mode. Echo packets are not defined in the BFD specification, though they can keep the BFD session up. There are no guidelines on the properties of the echo packets beyond the choice of the source and destination addresses. While the BFD specification recommends applying security mechanisms to prevent spoofing of these packets, there are no guidelines on what type of mechanisms are appropriate.
o BFD允许一种称为回波模式的模式。BFD规范中没有定义回显数据包，尽管它们可以保持BFD会话正常。除了选择源地址和目标地址之外，没有关于回送数据包属性的指南。虽然BFD规范建议应用安全机制来防止对这些数据包的欺骗，但没有关于哪种类型的机制是合适的指导原则。
Any security issues in the echo mode will directly affect the BFD protocol and session states, and hence the network stability. The potential effects and remedies as understood today are somewhat limited, however. For instance, any replay attacks would be indistinguishable from normal forwarding of the tested router. An attack would still cause a faulty link to be believed to be up, but there is little that can be done about it. However, if the echo packets are guessable, it may be possible to spoof from an external source and cause BFD to believe that a one-way link is really bidirectional. As a result, it is important that the echo packets contain random material that is also checked upon reception.
回声模式下的任何安全问题都将直接影响BFD协议和会话状态，从而影响网络稳定性。然而，今天所理解的潜在影响和补救措施有些有限。例如，任何重播攻击都无法与测试路由器的正常转发区分开来。攻击仍然会导致错误链接被认为已启动，但对此几乎无能为力。然而，如果回声包是可猜测的，则可能会从外部源欺骗，并使BFD相信单向链路实际上是双向的。因此，重要的是回波数据包包含随机材料，在接收时也会进行检查。
o BFD packets can be sent at millisecond intervals (the protocol uses timers at microsecond intervals). When using authentication, this can cause frequent sequence number wrap-around as a 32-bit sequence number is used, thus considerably reducing the security of the authentication algorithms.
o BFD数据包可以以毫秒为间隔发送（协议以微秒为间隔使用计时器）。使用身份验证时，使用32位序列号时，这可能会导致频繁的序列号缠绕，从而大大降低身份验证算法的安全性。
o Recently, limitations in collision-resistance properties of the MD5 and SHA-1 hash functions have been discovered; [RFC4270] summarizes the discoveries. There have been attacks against the use of MD5 as a hash; while these attacks do not directly apply to the use of HMAC-MD5 and keyed SHA-1 in BFD, it is prudent to have other options available. Such attacks do not mean that BFD using SHA-1 for authentication is at risk. However, it does mean that SHA-1 should be replaced as soon as possible and should not be used for new applications.
o 最近，MD5和SHA-1散列函数的抗冲突特性的局限性被发现；[RFC4270]总结了这些发现。有人攻击使用MD5作为散列；虽然这些攻击不直接适用于在BFD中使用HMAC-MD5和键控SHA-1，但谨慎的做法是提供其他选项。此类攻击并不意味着BFD使用SHA-1进行身份验证存在风险。然而，这确实意味着应尽快更换SHA-1，并且不应用于新的应用。
It should be noted that if SHA-1 is used in the Hashed Message Authentication Code (HMAC) [RFC2104] construction, then collision attacks currently known against SHA-1 do not apply. The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1.
应该注意的是，如果在哈希消息认证码（HMAC）[RFC2104]构造中使用SHA-1，则目前已知的针对SHA-1的冲突攻击不适用。对SHA-1的新攻击对HMAC-SHA-1的安全没有影响。
There are already proposals [GenBFDAuth] that add support for HMAC with the SHA-1 and SHA-2 family of hash functions for BFD.
已经有建议[GenBFDAuth]为HMAC添加了对BFD的SHA-1和SHA-2哈希函数家族的支持。
This document outlines security issues arising from the current methodology for manual keying of various routing protocols. No specific changes to routing protocols are proposed in this document; likewise, no new security requirements result.
本文档概述了当前手动键入各种路由协议的方法所产生的安全问题。本文件中未提出对路由协议的具体变更；同样，也不会产生新的安全需求。
We would like to acknowledge Sam Hartman, Ran Atkinson, Stephen Kent and Brian Weis for their initial comments on this document. Thanks to Merike Kaeo and Alfred Hoenes for reviewing many sections of the document and providing lot of useful comments.
我们感谢Sam Hartman、Ran Atkinson、Stephen Kent和Brian Weis对本文件的初步评论。感谢Merike Kaeo和Alfred Hoenes审阅了文件的许多部分，并提供了许多有用的意见。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[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月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Kent, S., "IP Authentication Header",
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。Kent，S.，“IP认证头”，
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[Arjen05] Arjen K. Lenstra, "Further progress in Hashing cryptanalysis", Lucent Bell Laboratories, February 26, 2005.
[Arjen05]Arjen K.Lenstra，“哈希密码分析的进一步进展”，朗讯贝尔实验室，2005年2月26日。
[Conv01] Convery, et al., "BGP Vulnerability Testing: Separating Fact from FUD v1.00", NANOG 28, pp. 1-61, June 2003.
[Conv01]Convery等人，“BGP漏洞测试：从FUD v1.00中分离事实”，NANOG 28，第1-61页，2003年6月。
[Crypto2004] Xiaoyun Wang, Xuejia Lai, Dengguo Feng, and Hongbo Yu, "Collisions for hash functions MD4, MD5, HAVAL-128, and RIPEMD", Crypto 2004 Rump Session.
[Crypto2004]王晓云，赖学佳，冯登国，余洪波，“散列函数MD4，MD5，HAVAL-128和RIPEMD的冲突”，Crypto2004 Rump会话。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the Rump Session of EuroCrypt 1996.)
[Dobb96a]Dobbertin，H.，“MD5压缩的密码分析”，技术报告，1996年5月2日。（1996年在EuroCrypt的Rump会议上提出。）
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[Dobb96b]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes，第2卷，第2期，1996年夏季。
[GenBFDAuth] Bhatia, M. and V. Manral, "BFD Generic Cryptographic Authentication", Work in Progress, June 2010.
[GenBFDAuth]Bhatia，M.和V.Manral，“BFD通用密码认证”，正在进行的工作，2010年6月。
[NISTHmacSHA] "NIST's Policy on Hash Functions", 2006, http://csrc.nist.gov/groups/ST/hash/policy.html.
[NISTHmacSHA]“NIST哈希函数政策”，2006年，http://csrc.nist.gov/groups/ST/hash/policy.html.
[Philip01] Philip Hawkes, Michael Paddon, and Gregory G. Rose, "On Corrective Patterns for the SHA-2 Family", IACR ePrint Archive, 2004, http://eprint.iacr.org/2004/207.
[Philip01]Philip Hawkes、Michael Paddon和Gregory G.Rose，“关于SHA-2家族的纠正模式”，IACR ePrint档案，2004年，http://eprint.iacr.org/2004/207.
[Prav01] Praveen Gauravaram, et al., "Collision Attacks on MD5 and SHA-1: Is this the 'Sword of Domocles' for Electronic Commerce?", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
[Prav01] Praveen Gauravaram，等，“对MD5和SHA-1的碰撞攻击：这是用于电子商务的多摩克里斯之剑吗？”，信息安全研究所（ISI），昆士兰科技大学（QUT），澳大利亚。
[Prav02] Praveen Gauravaram, et al., "Some thoughts on Collision Attacks in the Hash Functions Md5, SHA-0 and SHA-1", Information Security Institue (ISI), Queensland University of Technology (QUT), Australia.
[Prav0] Praveen Gauravaram等人，“关于哈希函数MD5、SHA0和SHA-1中的碰撞攻击的一些想法”，信息安全研究所（ISI），昆士兰科技大学（QUT），澳大利亚。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]Hedrick，C.，“路由信息协议”，RFC10581988年6月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993.
[RFC1388]Malkin，G.，“RIP版本2包含附加信息”，RFC 1388，1993年1月。
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[RFC1723]Malkin，G.，“RIP版本2-携带附加信息”，RFC 17231994年11月。
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
[RFC1923]Halpern，J.和S.Bradner，“RIPv1历史地位适用性声明”，RFC 1923，1996年3月。
[RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[RFC2082]Baker，F.和R.Atkinson，“RIP-2 MD5认证”，RFC 2082，1997年1月。
[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月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[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月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 5709，2009年10月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年6月。
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC5883]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 5883，2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RR07] Rechberger, C. and V. Rijmen, "On Authentication with HMAC and Non-random Properties", Financial Cryptography and Data Security, Lecture Notes in Computer Science, Volume 4886/2008, Springer-Verlag, Berlin, December 2007.
[RR07]Rechberger，C.和V.Rijmen，“关于HMAC和非随机属性的身份验证”，金融密码学和数据安全，计算机科学课堂讲稿，第4886/2008卷，Springer Verlag，柏林，2007年12月。
[RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC when Instantiated with Popular Hash Functions", Journal of Universal Computer Science, Volume 14, Number 3, pp. 347-376, 1 February 2008.
[RR08]Rechberger，C.和V.Rijmen，“使用流行哈希函数实例化NMAC/HMAC时的新结果”，《通用计算机科学杂志》，第14卷，第3期，第347-376页，2008年2月1日。
[TcpWindow] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://cansecwest.com/csw04archive.html.
[TcpWindow]Watson，P.，“在窗口中滑动：TCP重置攻击”，在2004年CanSecWest上的演讲，http://cansecwest.com/csw04archive.html.
[Wang04] Wang, X., et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, IACR ePrint Archive, http://eprint.iacr.org/2004/199.
[Wang04]Wang，X.等人，“哈希函数MD4、MD5、HAVAL-128和RIPEMD的冲突”，2004年8月，IACR ePrint存档，http://eprint.iacr.org/2004/199.
[Wang05] Wang, X., et al., "Finding Collisions in the Full SHA-1", Proceedings of Crypto 2005, Lecture Notes in Computer Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, August 31, 2005.
[Wang05]Wang，X.，et al.，“在完整的SHA-1中发现碰撞”，《加密学报2005》，计算机科学课堂讲稿，第3621卷，第17-36页，柏林斯普林格·维拉格，2005年8月31日。
Sue Hares NextHop USA EMail: shares@nexthop.com
Sue Hares NextHop USA电子邮件：shares@nexthop.com
Authors' Addresses
作者地址
Vishwas Manral IP Infusion, Inc. 1188 E. Arques Ave. Sunnyvale, CA 94085 EMail: vishwas@ipinfusion.com
Vishwas Manral IP输液公司，地址：加利福尼亚州桑尼维尔阿克斯大道东1188号，邮编：94085电子邮件：vishwas@ipinfusion.com
Manav Bhatia Alcatel-Lucent Bangalore India EMail: manav.bhatia@alcatel-lucent.com
Manav Bhatia Alcatel Lucent Bangalore India电子邮件：Manav。bhatia@alcatel-朗讯网
Joel P. Jaeggli Nokia Inc. EMail: joel.jaeggli@nokia.com
Joel P.Jaeggli Nokia Inc.电子邮件：Joel。jaeggli@nokia.com
Russ White Cisco Systems RTP North Carolina USA EMail: riw@cisco.com
Russ White Cisco Systems RTP美国北卡罗来纳州电子邮件：riw@cisco.com