Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7492 Ionos Networks
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei
M. Jethanandani
Ciena Corporation
March 2015
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7492 Ionos Networks
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei
M. Jethanandani
Ciena Corporation
March 2015
Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines
根据路由协议键控和认证（KARP）设计准则分析双向转发检测（BFD）安全性
Abstract
摘要
This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".
本文件根据RFC 6518第4.2节“路由协议的键控和认证（KARP）设计指南”中规定的指南分析双向转发检测（BFD）协议。
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/rfc7492.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7492.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements to Meet . . . . . . . . . . . . . . . . . . . . 3
3. Current State of Security Methods . . . . . . . . . . . . . . 3
4. Impacts of BFD Replays . . . . . . . . . . . . . . . . . . . 5
5. Impact of New Authentication Requirements . . . . . . . . . . 6
6. Considerations for Improvement . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements to Meet . . . . . . . . . . . . . . . . . . . . 3
3. Current State of Security Methods . . . . . . . . . . . . . . 3
4. Impacts of BFD Replays . . . . . . . . . . . . . . . . . . . 5
5. Impact of New Authentication Requirements . . . . . . . . . . 6
6. Considerations for Improvement . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
This document performs a gap analysis of the current state of Bidirectional Forwarding Detection [RFC5880] according to the requirements of KARP Design Guidelines [RFC6518]. Previously, the OPSEC working group has provided an analysis of cryptographic issues with BFD in "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039].
本文件根据KARP设计指南[RFC6518]的要求，对双向转发检测[RFC5880]的当前状态进行差距分析。此前，OPSEC工作组在“路由协议的现有加密保护方法问题”[RFC6039]中提供了对BFD的加密问题的分析。
The existing BFD specifications provide a basic security solution. Key ID is provided so that the key used in securing a packet can be changed on demand. Two cryptographic algorithms (MD5 and SHA-1) are supported for integrity protection of the control packets; the algorithms are both demonstrated to be subject to collision attacks. Routing protocols like "RIPv2 Cryptographic Authentication" [RFC4822], "IS-IS Generic Cryptographic Authentication" [RFC5310], and "OSPFv2 HMAC-SHA Cryptographic Authentication" [RFC5709] have started to use BFD for liveliness checks. Moving the routing
现有的BFD规范提供了基本的安全解决方案。提供密钥ID，以便可以根据需要更改用于保护数据包的密钥。支持两种加密算法（MD5和SHA-1）来保护控制数据包的完整性；这两种算法都被证明会受到碰撞攻击。诸如“RIPv2加密身份验证”[RFC4822]、“IS-IS通用加密身份验证”[RFC5310]和“OSPFv2 HMAC-SHA加密身份验证”[RFC5709]等路由协议已开始使用BFD进行活动性检查。移动路由
protocols to a stronger algorithm while using a weaker algorithm for BFD would allow the attacker to bring down BFD in order to bring down the routing protocol. BFD therefore needs to match the routing protocols in its strength of algorithm.
当对BFD使用较弱的算法时，将协议转换为更强的算法将允许攻击者关闭BFD以关闭路由协议。因此，BFD需要在算法强度上与路由协议相匹配。
While BFD uses a non-decreasing, per-packet sequence number to protect itself from intra-connection replay attacks, it still leaves the protocol vulnerable to the inter-session replay attacks.
虽然BFD使用非递减的每个数据包序列号来保护自己免受连接内重放攻击，但它仍然使协议容易受到会话间重放攻击。
There are several requirements described in Section 4 of [RFC6862] that BFD, as defined in BFD [RFC5880], does not currently meet:
[RFC6862]第4节中描述了BFD[RFC5880]中定义的BFD目前不满足的几个要求：
Replay Protection: BFD provides an incomplete intra-session and no inter-session replay attack protection; this creates significant denial-of-service opportunities.
重放保护：BFD提供不完整的会话内重放攻击保护，没有会话间重放攻击保护；这会造成严重的拒绝服务机会。
Strong Algorithms: The cryptographic algorithms adopted for message authentication in BFD are MD5 or SHA-1 based. However, both algorithms are known to be vulnerable to collision attacks. "BFD Generic Cryptographic Authentication" [BFD-CRYPTO] and "Authenticating BFD using HMAC-SHA-2 procedures" [BFD-HMAC] together propose a solution to support Hashed Message Authentication Code (HMAC) with the SHA-2 family of hash functions for BFD.
强算法：BFD中用于消息身份验证的加密算法基于MD5或SHA-1。然而，这两种算法都很容易受到碰撞攻击。“BFD通用加密身份验证”[BFD-CRYPTO]和“使用HMAC-SHA-2过程对BFD进行身份验证”[BFD-HMAC]共同提出了一种解决方案，用BHA-2系列哈希函数为BFD支持哈希消息身份验证码（HMAC）。
Preventing DoS Attacks: BFD packets can be sent at millisecond intervals (the protocol uses timers at microsecond intervals). When malicious packets are sent at short intervals, with the authentication bit set, it can cause a DoS attack. There is currently no lightweight mechanism within BFD to address this issue and is one of the reasons BFD authentication is still not widely deployed in the field.
防止DoS攻击：BFD数据包可以以毫秒的间隔发送（协议以微秒的间隔使用计时器）。当短时间间隔发送恶意数据包并设置身份验证位时，可能会导致DoS攻击。目前，BFD中没有轻量级机制来解决此问题，这也是BFD身份验证尚未在现场广泛部署的原因之一。
The remainder of this document explains the details of how these requirements fail to be met and proposes mechanisms for addressing them.
本文件的其余部分详细说明了这些要求如何未能得到满足，并提出了解决这些问题的机制。
BFD [RFC5880] describes five authentication mechanisms for the integrity protection of BFD control packets: Simple Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1, and Meticulous Keyed SHA-1. In the simple password mechanism, every control packet is associated with a password transported in plain text; attacks eavesdropping the network traffic can easily learn the password and compromise the security of the corresponding BFD session. In the
BFD[RFC5880]描述了用于BFD控制数据包完整性保护的五种身份验证机制：简单密码、键控MD5[RFC1321]、精心键控MD5、精心键控SHA-1和精心键控SHA-1。在简单密码机制中，每个控制包都与明文传输的密码相关联；窃听网络流量的攻击可以很容易地学习密码并危及相应BFD会话的安全性。在
Keyed MD5 and the Meticulous Keyed MD5 mechanisms, BFD nodes use shared secret keys to generate Keyed MD5 digests for control packets. Similarly, in the Keyed SHA-1 and the Meticulous Keyed SHA-1 mechanisms, BFD nodes use shared secret keys to generate Keyed SHA-1 digests for control packets. Note that in the keyed authentication mechanisms, every BFD control packet is associated with a non-decreasing, 32-bit sequence number to resist replay attacks. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the sequence member is only required to increase occasionally. However, in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms, the sequence member is required to increase with each successive packet.
BFD节点使用密钥MD5和精心设置密钥的MD5机制，使用共享密钥为控制数据包生成密钥MD5摘要。类似地，在键控SHA-1和精细键控SHA-1机制中，BFD节点使用共享密钥为控制分组生成键控SHA-1摘要。注意，在密钥认证机制中，每个BFD控制数据包都与一个非递减的32位序列号相关联，以抵抗重放攻击。在键控MD5和键控SHA-1机制中，序列成员只需要偶尔增加。然而，在精细键控MD5和精细键控SHA-1机制中，序列成员需要随着每个连续分组而增加。
Additionally, limited key updating functionality is provided. There is a Key ID in every authenticated BFD control packet indicating the key used to hash the packet. However, there is no mechanism described to provide a smooth key rollover that the BFD routers can use when moving from one key to the other.
此外，还提供了有限的密钥更新功能。每个经过身份验证的BFD控制数据包中都有一个密钥ID，指示用于散列数据包的密钥。然而，当BFD路由器从一个密钥移动到另一个密钥时，没有描述提供平滑密钥翻转的机制。
The BFD session timers are defined with the granularity of microseconds, and it is common in practice to send BFD packets at millisecond intervals. Since the cryptographic sequence number space is only 32 bits, a sequence number used in a BFD session may reach its maximum value and roll over within a limited period. For instance, if a sequence number is increased by one every 3.3 milliseconds, then it will reach its maximum value in less than 24 weeks. This can result in potential inter-session replay attacks, especially when BFD uses the non-meticulous authentication modes.
BFD会话计时器的粒度定义为微秒，在实践中，通常以毫秒间隔发送BFD数据包。由于加密序列号空间仅为32位，BFD会话中使用的序列号可能会达到其最大值，并在有限的时间内滚动。例如，如果序列号每3.3毫秒增加一个，那么它将在不到24周内达到最大值。这可能会导致潜在的会话间重播攻击，尤其是当BFD使用非细致的身份验证模式时。
Note that when using authentication mechanisms, BFD drops all packets that fall outside the limited range (3 times the Detection Time multiplier). Therefore, when meticulous authentication modes are used, a replayed BFD packet will be rejected if it cannot fit into a relatively short window (3 times the detection interval of the session). This introduces some difficulties for replaying packets. However, in a non-meticulous authentication mode, such windows can be large (as sequence numbers are only increased occasionally), thus making it easier to perform replay attacks .
请注意，在使用身份验证机制时，BFD会丢弃超出限制范围（检测时间乘数的3倍）的所有数据包。因此，当使用仔细的身份验证模式时，如果重放的BFD数据包无法放入相对较短的窗口（会话检测间隔的3倍），则将拒绝该数据包。这给重放数据包带来了一些困难。但是，在非仔细验证模式下，此类窗口可能很大（因为序列号只是偶尔增加），因此更容易执行重播攻击。
In a BFD session, each node needs to select a 32-bit discriminator to identify itself. Therefore, a BFD session is identified by two discriminators. If a node randomly selects a new discriminator for a new session and uses authentication mechanisms to secure the control packets, inter-session replay attacks can be mitigated to some extent. However, in existing BFD demultiplexing mechanisms, the discriminators used in a new BFD session may be predictable. In some deployment scenarios, the discriminators of BFD routers may be decided by the destination and source addresses. So, if the sequence number of a BFD router rolls over for some reason (e.g., reboot), the
在BFD会话中，每个节点需要选择一个32位鉴别器来识别自己。因此，BFD会话由两个鉴别器识别。如果节点为新会话随机选择新的鉴别器并使用身份验证机制来保护控制数据包，则会话间重放攻击可以在一定程度上得到缓解。然而，在现有BFD解复用机制中，在新BFD会话中使用的鉴别器可能是可预测的。在某些部署场景中，BFD路由器的鉴别器可能由目标和源地址决定。因此，如果BFD路由器的序列号由于某种原因（例如，重新启动）翻转，则
discriminators used to identify the new session will be identical to the ones used in the previous session. This makes performing a replay attack relatively simple.
用于识别新会话的鉴别器将与前一会话中使用的鉴别器相同。这使得执行重放攻击相对简单。
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. The format of the echo packet is local to the sending side, and there are no guidelines on the properties of these 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.
BFD允许一种称为回波模式的模式。BFD规范中没有定义回显数据包，尽管它们可以保持BFD会话正常。回送数据包的格式是发送端本地的，除了选择源地址和目标地址之外，没有关于这些数据包属性的指南。虽然BFD规范建议应用安全机制来防止对这些数据包的欺骗，但没有关于哪种类型的机制是合适的指导原则。
As discussed, BFD cannot meet the requirements of inter-session or intra-session replay protection. This section discusses the impacts of BFD replays.
如前所述，BFD不能满足会话间或会话内重播保护的要求。本节讨论BFD重播的影响。
When cryptographic authentication mechanisms are adopted for BFD, a non-decreasing, 32-bit-long sequence number is used. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the sequence member is not required to increase for every packet. Therefore, an attacker can keep replaying the packets with the latest sequence number until the sequence number is updated. This issue is eliminated in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms. However, note that a sequence number may reach its maximum and be rolled over in a session. In this case, without the support from a automatic key management mechanism, the BFD session will be vulnerable to replay attacks performed by sending the packets before the roll over of the sequence number. For instance, an attacker can replay a packet with a sequence number that is larger than the current one. If the replayed packet is accepted, the victim will reject the legal packets whose sequence members are less than the one in the replayed packet. Therefore, the attacker can get a good chance to bring down the BFD session. This kind of attack assumes that the attacker has access to the link when the BFD session is on a point-to-point link or can inject packets for a BFD session with multiple hops.
当BFD采用加密身份验证机制时，将使用非递减的32位长序列号。在键控MD5和键控SHA-1机制中，不需要为每个数据包增加序列成员。因此，攻击者可以不断重放具有最新序列号的数据包，直到序列号更新。这个问题在精细键控MD5和精细键控SHA-1机制中被消除。但是，请注意，序列号可能会达到其最大值，并在会话中滚动。在这种情况下，如果没有自动密钥管理机制的支持，BFD会话将容易受到通过在序列号滚动之前发送数据包而执行的重播攻击。例如，攻击者可以重播序列号大于当前序列号的数据包。如果重播数据包被接受，受害者将拒绝序列成员小于重播数据包中序列成员的合法数据包。因此，攻击者有很好的机会关闭BFD会话。此类攻击假设当BFD会话位于点到点链路上时，攻击者可以访问该链路，或者可以为具有多跳的BFD会话注入数据包。
Additionally, the BFD specification allows for the change of authentication state based on the state of a received packet. For instance, according to BFD [RFC5880], if the state of an accepted packet is down, the receiver of the packet needs to transfer its state to down as well. Therefore, a carefully selected replayed packet can cause a serious denial-of-service attack.
此外，BFD规范允许基于接收到的分组的状态来改变认证状态。例如，根据BFD[RFC5880]，如果接受的数据包的状态为down，则数据包的接收器也需要将其状态转移到down。因此，精心选择的重播数据包可能会导致严重的拒绝服务攻击。
BFD does not provide any solution to deal with inter-session replay attacks. If two subsequent BFD sessions adopt an identical discriminator pair and use the same cryptographic key to secure the control packets, it is intuitive to use a malicious authenticated packet (stored from the past session) to perform interconnection replay attacks.
BFD不提供任何解决方案来处理会话间重播攻击。如果两个后续BFD会话采用相同的鉴别器对，并使用相同的加密密钥保护控制数据包，则可以直观地使用恶意认证数据包（存储自上一个会话）执行互连重播攻击。
Any security issues in the BFD echo mode will directly affect the BFD protocol and session states, and hence the network stability. 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协议和会话状态，从而影响网络稳定性。例如，任何重播攻击都无法与测试路由器的正常转发区分开来。攻击仍然会导致错误链接被认为已启动，但对此几乎无能为力。然而，如果回声包是可猜测的，则可能会从外部源欺骗，并使BFD相信单向链路实际上是双向的。因此，重要的是回波数据包包含随机材料，在接收时也会进行检查。
BFD can be run in software or hardware. Hardware implementations run BFD at a much smaller timeout, typically in the order of few milliseconds. For instance, with a timeout of 3.3 milliseconds, a BFD session is required to send or receive 3 packets every 10 milliseconds. Software implementations typically run with a timeout in hundreds of milliseconds.
BFD可以在软件或硬件中运行。硬件实现以更小的超时时间运行BFD，通常为几毫秒。例如，超时为3.3毫秒时，BFD会话需要每10毫秒发送或接收3个数据包。软件实现通常以数百毫秒的超时时间运行。
Additionally, it is not common to find hardware support for computing the authentication data for the BFD session in hardware or software. In the Keyed MD5 and Keyed SHA-1 implementation where the sequence number does not increase with every packet, software can be used to compute the authentication data. This is true if the time between the increasing sequence number is long enough to compute the data in software. The ability to compute the hash in software is difficult with Meticulous Keyed MD5 and Meticulous Keyed SHA-1 if the time interval between transmits or between receives is small. The computation problem becomes worse if hundred or thousands of sessions require the hash to be recomputed every few milliseconds.
此外，在硬件或软件中不常见计算BFD会话的身份验证数据的硬件支持。在键控MD5和键控SHA-1实现中，序列号不会随着每个数据包的增加而增加，可以使用软件来计算认证数据。如果增加序列号之间的时间足够长，可以在软件中计算数据，则这是正确的。如果发送之间或接收之间的时间间隔很小，则使用精细键控MD5和精细键控SHA-1很难在软件中计算哈希。如果数百或数千个会话要求每隔几毫秒重新计算一次哈希，则计算问题会变得更糟。
Smaller and cheaper boxes that have to support a few hundred BFD sessions are boxes that also use a slower CPU. The CPU is used for running the entire control plane software in addition to supporting the BFD sessions. As a general rule, no more than 40-45% of the CPU can be dedicated towards supporting BFD. Adding computation of the hash for every BFD session can easily cause the CPU to exceed the 40-45% limit even with a few tens of sessions. On higher-end boxes with faster and more CPU cores, the expectation is that the number of
必须支持几百个BFD会话的更小、更便宜的设备也是使用较慢CPU的设备。除了支持BFD会话外，CPU还用于运行整个控制平面软件。一般来说，不超过40-45%的CPU用于支持BFD。为每个BFD会话添加哈希计算很容易导致CPU超过40-45%的限制，即使只有几十个会话。在具有更快、更多CPU内核的高端机箱上，期望的是
sessions that need to be supported are in the thousands, but the number of BFD sessions with authentication that CPU can support is still in the hundreds.
需要支持的会话有数千个，但CPU可以支持的具有身份验证的BFD会话数量仍有数百个。
Implementors should assess the impact of authenticating BFD sessions on their platform.
实现者应该评估在其平台上验证BFD会话的影响。
This section suggests changes that can be adopted to improve the protection of BFD.
本节建议可采取的变更，以改善BFD的保护。
The security risks brought by SHA-1 and MD5 have been well understood. However, when using a stronger digest algorithm, e.g., SHA-2, the imposed computing overhead will seriously affect the performance of BFD implementation. In order to make the trade-off between the strong algorithm requirement and the imposed overhead, Galois Message Authentication Code (GMAC) can be a candidate option. This algorithm is relatively effective and has been supported by IPsec for data origin authentication. More detailed information can be found in "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH" [RFC4543].
SHA-1和MD5带来的安全风险已被充分理解。然而，当使用更强的摘要算法（如SHA-2）时，强加的计算开销将严重影响BFD实现的性能。为了在强大的算法要求和强加的开销之间进行权衡，Galois消息认证码（GMAC）可以作为候选选项。该算法相对有效，并得到了IPsec对数据源身份验证的支持。更详细的信息可以在“在IPsec ESP和AH中使用Galois消息身份验证码（GMAC）”[RFC4543]中找到。
There has been some hallway conversation around the idea of using BFD cryptographic authentication only when some data in the BFD payload changes. The other BFD packets can be transmitted and received without authentication enabled. The bulk of the BFD packets that are transmitted and received have no state change associated with them. Limiting authentication to BFD packets that affect a BFD session state allows for more sessions to be supported for authentication. This change can significantly help the routers since they don't have to compute and verify the authentication digest for the BFD packets coming at the millisecond intervals. This proposal needs some more discussion in the BFD working group and is certainly a direction that BFD could look at.
关于仅当BFD有效负载中的某些数据发生更改时才使用BFD加密身份验证的想法，已经有一些过道上的对话。可以在不启用身份验证的情况下发送和接收其他BFD数据包。发送和接收的大部分BFD数据包没有与之相关的状态变化。将身份验证限制为影响BFD会话状态的BFD数据包可以支持更多会话进行身份验证。这一变化可以极大地帮助路由器，因为它们不必计算和验证以毫秒间隔出现的BFD数据包的身份验证摘要。这项建议需要在BFD工作组中进行更多的讨论，这当然是BFD可以考虑的方向。
This document discusses vulnerabilities in the existing BFD protocol and suggests possible mitigations.
本文件讨论了现有BFD协议中的漏洞，并提出了可能的缓解措施。
In analyzing the improvements for BFD, the ability to repel a replay attack is discussed. For example, increasing the sequence number to a 64-bit value makes the wrap-around time much longer, and a replay attack can be easily prevented.
在分析BFD的改进时，讨论了击退重放攻击的能力。例如，将序列号增加到64位值会使环绕时间更长，并且可以轻松防止重播攻击。
Mindful of the impact that stronger algorithms can have on the performance of BFD, the document suggests GMAC as a possible candidate for MAC function.
考虑到更强的算法可能对BFD性能产生的影响，该文件建议GMAC作为MAC功能的可能候选。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月<http://www.rfc-editor.org/info/rfc1321>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月<http://www.rfc-editor.org/info/rfc5880>.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010, <http://www.rfc-editor.org/info/rfc6039>.
[RFC6039]Manral，V.，Bhatia，M.，Jaeggli，J.，和R.White，“路由协议现有加密保护方法的问题”，RFC 6039，2010年10月<http://www.rfc-editor.org/info/rfc6039>.
[BFD-CRYPTO] Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, "BFD Generic Cryptographic Authentication", Work in Progress, draft-ietf-bfd-generic-crypto-auth-06, April 2014.
[BFD-CRYPTO]Bhatia，M.，Manral，V.，Zhang，D.，和M.Jethanandani，“BFD通用密码认证”，正在进行的工作，草稿-ietf-BFD-Generic-CRYPTO-auth-062014年4月。
[BFD-HMAC] Zhang, D., Bhatia, M., Manral, V., and M. Jethanandani, "Authenticating BFD using HMAC-SHA-2 procedures", Work in Progress, draft-ietf-bfd-hmac-sha-05, July 2014.
[BFD-HMAC]Zhang，D.，Bhatia，M.，Manral，V.，和M.Jethanandani，“使用HMAC-SHA-2程序认证BFD”，在建工程，草案-ietf-BFD-HMAC-SHA-052014年7月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006, <http://www.rfc-editor.org/info/rfc4543>.
[RFC4543]McGrew，D.和J.Viega，“在IPsec ESP和AH中使用Galois消息认证码（GMAC）”，RFC 4543，2006年5月<http://www.rfc-editor.org/info/rfc4543>.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007, <http://www.rfc-editor.org/info/rfc4822>.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月<http://www.rfc-editor.org/info/rfc4822>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月<http://www.rfc-editor.org/info/rfc5310>.
[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, <http://www.rfc-editor.org/info/rfc5709>.
[RFC5709]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 57092009年10月<http://www.rfc-editor.org/info/rfc5709>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012, <http://www.rfc-editor.org/info/rfc6518>.
[RFC6518]Lebovitz，G.和M.Bhatia，“路由协议的键控和认证（KARP）设计指南”，RFC 6518，2012年2月<http://www.rfc-editor.org/info/rfc6518>.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.
[RFC6862]Lebovitz，G.，Bhatia，M.和B.Weis，“路由协议的密钥和认证（KARP）概述，威胁和要求”，RFC 68622013年3月<http://www.rfc-editor.org/info/rfc6862>.
Acknowledgements
致谢
We would like to thank Alexander Vainshtein for his comments on this document.
我们要感谢Alexander Vainstein对本文件的评论。
Authors' Addresses
作者地址
Manav Bhatia Ionos Networks Bangalore India
印度班加罗尔Manav Bhatia Ionios网络
EMail: manav@ionosnetworks.com
EMail: manav@ionosnetworks.com
Dacheng Zhang Huawei
张大成华为
EMail: dacheng.zhang@gmail.com
EMail: dacheng.zhang@gmail.com
Mahesh Jethanandani Ciena Corporation 3939 North 1st Street San Jose, CA 95134 United States
Mahesh Jethanandani Ciena Corporation美国加利福尼亚州圣何塞北第一街3939号，邮编95134
Phone: 408.904.2160 Fax: 408.436.5582 EMail: mjethanandani@gmail.com
电话：408.904.2160传真：408.436.5582电子邮件：mjethanandani@gmail.com