Internet Engineering Task Force (IETF) M. Jethanandani
Request for Comments: 6952 Ciena Corporation
Category: Informational K. Patel
ISSN: 2070-1721 Cisco Systems, Inc
L. Zheng
Huawei Technologies
May 2013
Internet Engineering Task Force (IETF) M. Jethanandani
Request for Comments: 6952 Ciena Corporation
Category: Informational K. Patel
ISSN: 2070-1721 Cisco Systems, Inc
L. Zheng
Huawei Technologies
May 2013
Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
根据路由协议的密钥和认证（KARP）设计指南，分析BGP、LDP、PCEP和MSDP问题
Abstract
摘要
This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.
本文件根据本协议第4.2节规定的指南，分析基于TCP的路由协议、边界网关协议（BGP）、标签分发协议（LDP）、路径计算元素通信协议（PCEP）和多播源分发协议（MSDP）“路由协议设计指南的键控和认证”，RFC 6518。
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/rfc6952.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6952.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Current Assessment of BGP, LDP, PCEP, and MSDP . . . . . . . 5
2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying Mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.4.2. Denial-of-Service Attacks . . . . . . . . . . . . . . 8
2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transition and Deployment Considerations . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Current Assessment of BGP, LDP, PCEP, and MSDP . . . . . . . 5
2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying Mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.4.2. Denial-of-Service Attacks . . . . . . . . . . . . . . 8
2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transition and Deployment Considerations . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
In their "Report from the IAB Workshop on Unwanted Traffic March 9-10, 2006" [RFC4948], the Internet Architecture Board (IAB) described an attack on core routing infrastructure as an ideal attack that would inflict the greatest amount of damage and suggested steps to tighten the infrastructure against the attack. Four main steps were identified for that tightening:
互联网体系结构委员会（IAB）在其“2006年3月9日至10日IAB无用流量研讨会报告”[RFC4948]中描述了对核心路由基础设施的攻击，认为这是一种理想的攻击，会造成最大程度的破坏，并建议采取措施加强基础设施以抵御攻击。确定了拧紧的四个主要步骤：
1. Create secure mechanisms and practices for operating routers.
1. 创建操作路由器的安全机制和实践。
2. Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access, so that it can be used for routing verifications.
2. 清理Internet路由注册表（IRR）存储库，确保数据库和访问的安全，以便可以将其用于路由验证。
3. Create specifications for cryptographic validation of routing message content.
3. 为路由消息内容的加密验证创建规范。
4. Secure the routing protocols' packets on the wire.
4. 在线路上保护路由协议的数据包。
In order to secure the routing protocols, this document performs an initial analysis of the current state of four TCP-based protocols -- BGP [RFC4271], LDP [RFC5036], PCEP [RFC5440], and MSDP [RFC3618] -- according to the requirements of the KARP Design Guidelines [RFC6518]. Section 4.2 of that document uses the term "state", which will be referred to as the "state of the security method". Thus, a term like "Define Optimal State" would be referred to as "Define Optimal State of the Security Method".
为了确保路由协议的安全，本文件根据KARP设计指南[RFC6518]的要求，对四种基于TCP的协议——BGP[RFC4271]、LDP[RFC5036]、PCEP[RFC5440]和MSDP[RFC3618]的当前状态进行了初步分析。该文件第4.2节使用了“状态”一词，称为“安全方法状态”。因此，类似于“定义最佳状态”的术语将被称为“定义安全方法的最佳状态”。
This document builds on several previous efforts into routing security:
本文档建立在之前为路由安全所做的几项工作的基础上：
o "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039], describes issues with existing cryptographic protection methods for routing protocols.
o “路由协议现有加密保护方法的问题”[RFC6039]描述了路由协议现有加密保护方法的问题。
o Analysis of OSPF Security According to the KARP Design Guide [RFC6863] analyzes Open Shortest Path First (OSPF) security according to the KARP Design Guide.
o 根据KARP设计指南分析OSPF安全[RFC6863]根据KARP设计指南分析开放最短路径优先（OSPF）安全。
Section 2 of this document looks at the current state of the security method for the four routing protocols: BGP, LDP, PCEP, and MSDP. Section 3 examines what the optimal state of the security method would be for the four routing protocols according to the KARP Design Guidelines [RFC6518], and Section 4 does an analysis of the gap between the existing state of the security method and the optimal state of the security method for the protocols and suggests some areas where improvement is needed.
本文档第2节介绍四种路由协议（BGP、LDP、PCEP和MSDP）的安全方法的当前状态。第3节根据KARP设计指南[RFC6518]研究了四种路由协议的安全方法的最佳状态，第4节分析了安全方法的现有状态与协议安全方法的最佳状态之间的差距，并提出了需要改进的地方。
AES - Advanced Encryption Standard
高级加密标准
AO - Authentication Option
AO-身份验证选项
AS - Autonomous System
AS-自治系统
BGP - Border Gateway Protocol
边界网关协议
CMAC - Cipher-Based Message Authentication Code
基于CMAC密码的消息认证码
DoS - Denial of Service
拒绝服务
GTSM - Generalized Time-to-Live (TTL) Security Mechanism
GTSM-广义生存时间（TTL）安全机制
HMAC - Hash-Based MAC
基于哈希的MAC
KARP - Key and Authentication for Routing Protocols
KARP-路由协议的密钥和身份验证
KDF - Key Derivation Function
KDF-密钥派生函数
KEK - Key Encrypting Key
KEK密钥加密密钥
KMP - Key Management Protocol
密钥管理协议
LDP - Label Distribution Protocol
标签分发协议
LSR - Label Switching Routers
标签交换路由器
MAC - Message Authentication Code
MAC消息认证码
MKT - Master Key Table
MKT-主密钥表
MSDP - Multicast Source Distribution Protocol
多播源分发协议
MD5 - Message Digest Algorithm 5
MD5-消息摘要算法5
OSPF - Open Shortest Path First
开放最短路径优先
PCEP - Path Computation Element Communication Protocol
路径计算元件通信协议
PCC - Path Computation Client
路径计算客户端
PCE - Path Computation Element
路径计算元件
SHA - Secure Hash Algorithm
SHA-安全散列算法
TCP - Transmission Control Protocol
传输控制协议
TTL - Time-to-Live
TTL-生命的时刻
UDP - User Datagram Protocol
用户数据报协议
WG - Working Group
工作组-工作组
This section assesses the transport protocols for any authentication or integrity mechanisms used by the protocol. It describes the current security mechanisms, if any, used by BGP, LDP, PCEP, and MSDP.
本节评估传输协议使用的任何身份验证或完整性机制。它描述了BGP、LDP、PCEP和MSDP当前使用的安全机制（如果有）。
At the transport layer, routing protocols are subject to a variety of DoS attacks, as outlined in "Internet Denial-of-Service Considerations" [RFC4732]. Such attacks can cause the routing protocol to become congested, resulting in the routing updates being supplied too slowly to be useful. In extreme cases, these attacks prevent routers from converging after a change.
在传输层，路由协议受到各种DoS攻击，如“Internet拒绝服务注意事项”[RFC4732]所述。此类攻击可导致路由协议变得拥挤，导致路由更新提供得太慢而无法使用。在极端情况下，这些攻击会阻止路由器在更改后会聚。
Routing protocols use several methods to protect themselves. Those that use TCP as a transport protocol use access lists to accept packets only from known sources. These access lists also help protect edge routers from attacks originating outside the protected domain. In addition, for edge routers running the External Border Gateway Protocol (eBGP), TCP LISTEN is run only on interfaces on which its peers have been discovered or via which routing sessions are expected (as specified in router configuration databases).
路由协议使用多种方法来保护自己。那些使用TCP作为传输协议的人使用访问列表只接受来自已知来源的数据包。这些访问列表还有助于保护边缘路由器免受来自受保护域之外的攻击。此外，对于运行外部边界网关协议（eBGP）的边缘路由器，TCP侦听仅在已发现其对等点或预期通过其路由会话（如路由器配置数据库中所指定）的接口上运行。
"Generalized TTL Security Mechanism (GTSM)" [RFC5082] describes a generalized Time-to-Live (TTL) security mechanism to protect a protocol stack from CPU-utilization-based attacks. TCP Robustness [RFC5961] recommends some TCP-level mitigations against spoofing attacks targeted towards long-lived routing protocol sessions.
“通用TTL安全机制（GTSM）”[RFC5082]描述了一种通用生存时间（TTL）安全机制，用于保护协议栈免受基于CPU利用率的攻击。TCP健壮性[RFC5961]建议采取一些TCP级别的缓解措施，以防止针对长寿命路由协议会话的欺骗攻击。
Even when BGP, LDP, PCEP, and MSDP sessions use access lists, they are vulnerable to spoofing and man-in-the-middle attacks. Authentication and integrity checks allow the receiver of a routing protocol update to know that the message genuinely comes from the node that claims to have sent it and to know whether the message has been modified. Sometimes routers can be subjected to a large number of authentication and integrity requests, exhausting connection resources on the router in a way that could lead to the denial of genuine requests.
即使BGP、LDP、PCEP和MSDP会话使用访问列表，它们也容易受到欺骗和中间人攻击。身份验证和完整性检查允许路由协议更新的接收者知道消息确实来自声称已发送消息的节点，并知道消息是否已被修改。有时路由器可能会受到大量身份验证和完整性请求的影响，耗尽路由器上的连接资源，从而导致拒绝真正的请求。
TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However, it is still widely used to authenticate TCP-based routing protocols such as BGP. It provides a way for carrying a MD5 digest in a TCP segment. This digest is computed using information known only to the endpoints, and this ensures authenticity and integrity of messages. The MD5 key used to compute the digest is stored locally on the router. This option is used by routing protocols to provide for session-level protection against the introduction of spoofed TCP segments into any existing TCP streams, in particular, TCP Reset segments. TCP MD5 does not provide a generic mechanism to support key rollover. It also does not support algorithm agility.
TCP MD5[RFC2385]已被TCP-AO[RFC5925]淘汰。然而，它仍然被广泛用于验证基于TCP的路由协议，如BGP。它提供了一种在TCP段中承载MD5摘要的方法。此摘要是使用仅端点已知的信息计算的，这确保了消息的真实性和完整性。用于计算摘要的MD5密钥本地存储在路由器上。路由协议使用此选项提供会话级保护，以防止将伪造的TCP段引入任何现有TCP流，特别是TCP重置段。TCP MD5不提供支持密钥翻转的通用机制。它也不支持算法敏捷性。
The Message Authentication Codes (MACs) used by TCP MD5 are considered too weak both because of the use of the hash function and because of the way the secret key used by TCP MD5 is managed. Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO [RFC5925] and its companion document Cryptographic Algorithms for TCP-AO [RFC5926], describe steps towards correcting both the MAC weakness and the management of secret keys. Those steps require that two MAC algorithms be supported. They are HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that both these MAC algorithms are fairly secure. By supporting multiple MAC algorithms, TCP-AO supports algorithm agility. TCP-AO also allows additional MACs to be added in the future.
由于使用哈希函数和TCP MD5使用的密钥的管理方式，TCP MD5使用的消息身份验证码（MAC）被认为太弱。此外，TCP MD5不支持任何算法敏捷性。TCP-AO[RFC5925]及其配套文件TCP-AO加密算法[RFC5926]描述了纠正MAC弱点和密钥管理的步骤。这些步骤要求支持两种MAC算法。它们是HMAC[RFC2104]中规定的HMAC-SHA-1-96和NIST-SP800-38B[NIST-SP800-38B]中规定的AES-128-CMAC-96。密码研究表明，这两种MAC算法都相当安全。通过支持多种MAC算法，TCP-AO支持算法敏捷性。TCP-AO还允许将来添加其他MAC。
For TCP-AO [RFC5925], there is no Key Management Protocol (KMP) used to manage the keys that are employed to generate the MAC. TCP-AO talks about coordinating keys derived from the Master Key Table (MKT) between endpoints and allows for a master key to be configured manually or for it to be managed via an out-of-band mechanism.
对于TCP-AO[RFC5925]，没有用于管理用于生成MAC的密钥的密钥管理协议（KMP）。TCP-AO讨论在端点之间协调从主密钥表（MKT）派生的密钥，并允许手动配置主密钥或通过带外机制对其进行管理。
It should be noted that most routers configured with static keys have not seen the key changed ever. The common reason given for not changing the key is the difficulty in coordinating the change between pairs of routers when using TCP MD5. It is well known that the longer the same key is used, the greater the chance that it can be guessed or exposed, e.g., when an administrator with knowledge of the keys leaves the company.
应该注意的是，大多数配置了静态密钥的路由器从未见过密钥发生变化。给出的不更改密钥的常见原因是在使用TCP MD5时难以协调路由器对之间的更改。众所周知，使用同一密钥的时间越长，其被猜测或暴露的可能性就越大，例如，当了解密钥的管理员离开公司时。
For point-to-point key management, the IKEv2 protocol [RFC5996] provides for automated key exchange under a Security Association (SA) and can be used for a comprehensive KMP solution for routers. IKEv2 can be used for both IPsec SAs [RFC4301] and other types of SAs. For example, Fibre Channel SAs [RFC4595] are currently negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a possible option.
对于点对点密钥管理，IKEv2协议[RFC5996]提供了安全关联（SA）下的自动密钥交换，并可用于路由器的综合KMP解决方案。IKEv2可用于IPsec SAs[RFC4301]和其他类型的SAs。例如，光纤通道SAs[RFC4595]目前正在与IKEv2协商。使用IKEv2协商TCP-AO是一种可能的选择。
All BGP communications take place over TCP. Therefore, all security vulnerabilities for BGP can be categorized as relating to the security of the transport protocol itself, or to the compromising of individual routers and the data they handle. This document examines the issues for the transport protocol, while the SIDR Working Group (WG) looks at ways to sign and secure the data exchanged in BGP as described in "An Infrastructure to Support Secure Internet Protocol" [RFC6480].
所有BGP通信都通过TCP进行。因此，BGP的所有安全漏洞可归类为与传输协议本身的安全性有关，或与单个路由器及其处理的数据的危害有关。本文件探讨了传输协议的问题，而SIDR工作组（WG）则研究了签署和保护BGP中交换的数据的方法，如“支持安全互联网协议的基础设施”[RFC6480]所述。
"Security Framework for MPLS and GMPLS Networks" [RFC5920] outlines security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanism for detection and reporting.
“MPLS和GMPLS网络的安全框架”[RFC5920]概述了与MPLS和GMPLS相关的安全方面。它描述了安全威胁、相关防御技术以及检测和报告机制。
Section 5 of LDP [RFC5036] states that LDP is subject to two different types of attacks: spoofing and denial-of-service attacks.
LDP[RFC5036]第5节指出，LDP受到两种不同类型的攻击：欺骗和拒绝服务攻击。
A spoofing attack against LDP can occur both during the discovery phase and during the session communication phase.
在发现阶段和会话通信阶段都可能发生针对LDP的欺骗攻击。
Label Switching Routers (LSRs) indicate their willingness to establish and maintain LDP sessions by periodically sending Hello messages. Reception of a Hello message serves to create a new "Hello adjacency", if one does not already exist, or to refresh an existing one.
标签交换路由器（LSR）通过定期发送Hello消息来表示它们愿意建立和维护LDP会话。接收Hello消息可用于创建新的“Hello邻接”（如果尚未存在）或刷新现有的“Hello邻接”。
There are two variants of the discovery mechanism. A Basic Discovery mechanism is used to discover LSR neighbors that are directly connected at the link level, and an Extended Discovery mechanism is used by LSRs that are more than one hop away.
发现机制有两种变体。基本发现机制用于发现在链路级别直接连接的LSR邻居，扩展发现机制用于距离一个以上跳的LSR。
Unlike all other LDP messages, the Hello messages are sent using UDP. This means that they cannot benefit from the security mechanisms available with TCP. LDP [RFC5036] does not provide any security mechanisms for use with Hello messages except for some configuration that may help protect against bogus discovery events. These configurations include directly connected links and interfaces. Routers that do not use directly connected links have to use the Extended Discovery mechanism and will not be able to use configuration to protect against bogus discovery events.
与所有其他LDP消息不同，Hello消息使用UDP发送。这意味着它们无法从TCP可用的安全机制中获益。LDP[RFC5036]不提供任何用于Hello消息的安全机制，除了一些可能有助于防止虚假发现事件的配置。这些配置包括直接连接的链路和接口。不使用直接连接链路的路由器必须使用扩展发现机制，并且不能使用配置来防止虚假发现事件。
Spoofing a Hello packet for an existing adjacency can cause the adjacency to time out and result in termination of the associated session. This can occur when the spoofed Hello message specifies a small Hold Time, causing the receiver to expect Hello messages within this interval, while the true neighbor continues sending Hello messages at the lower, previously agreed to frequency.
欺骗现有邻接的Hello数据包可能导致邻接超时并导致相关会话终止。当伪造的Hello消息指定了一个很小的保持时间时，就会发生这种情况，这会导致接收者期望Hello消息在此间隔内，而真正的邻居继续以先前约定的较低频率发送Hello消息。
Spoofing a Hello packet can also cause the LDP session to be terminated. This can occur when the spoofed Hello specifies a different Transport Address from the previously agreed one between neighbors. Spoofed Hello messages are observed and reported as a real problem in production networks.
欺骗Hello数据包也会导致LDP会话终止。当伪造的Hello指定的传输地址与邻居之间先前约定的传输地址不同时，可能会发生这种情况。伪造的Hello消息在生产网络中被观察到并报告为一个实际问题。
LDP, like other TCP-based routing protocols, specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages. As stated in Section 2.1 of this document and in Section 2.9 of LDP [RFC5036], MD5 authentication is considered too weak for this application as outlined in MD5 and HMAC-MD5 Security Considerations [RFC6151]. It also does not support algorithm agility. A stronger hashing algorithm, e.g., SHA1, which is supported by TCP-AO [RFC5925], could be deployed to take care of the weakness.
与其他基于TCP的路由协议一样，LDP指定使用TCP MD5签名选项来提供会话消息的真实性和完整性。如本文件第2.1节和LDP[RFC5036]第2.9节所述，MD5认证对于MD5和HMAC-MD5安全注意事项[RFC6151]中所述的应用程序来说太弱。它也不支持算法敏捷性。可以部署TCP-AO[RFC5925]支持的更强大的散列算法，例如SHA1，以解决该弱点。
Alternatively, one could move to using TCP-AO, which provides for stronger MAC algorithms, makes it easier to set up manual keys, and protects against replay attacks.
或者，可以使用TCP-AO，它提供了更强的MAC算法，更容易设置手动密钥，并防止重播攻击。
LDP is subject to Denial-of-Service (DoS) attacks both in discovery mode and session mode. The potential targets are documented in Section 5.3 of LDP [RFC5036].
LDP在发现模式和会话模式下都会受到拒绝服务（DoS）攻击。潜在目标记录在LDP[RFC5036]第5.3节中。
For effective selection by Path Computation Clients (PCCs), a PCC needs to know the location of Path Computation Elements (PCEs) in its domain along with some information relevant for PCE selection. Such PCE information could be learned through manual configuration, on each PCC, along with the capabilities of the PCE or automatically through a PCE discovery mechanism as outlined in Requirements for PCE Discovery [RFC4674].
为了通过路径计算客户端（PCC）进行有效选择，PCC需要知道路径计算元素（PCE）在其域中的位置以及与PCE选择相关的一些信息。这些PCE信息可以通过在每个PCC上的手动配置以及PCE的功能来学习，或者通过PCE发现机制自动学习，如PCE发现要求[RFC4674]中所述。
Attacks on PCEP [RFC5440] may result in damage to active networks. These include computation responses, which if changed can cause protocols like RSVP-TE [RFC3209] to set up suboptimal or
对PCEP[RFC5440]的攻击可能会损坏活动网络。这些包括计算响应，如果更改这些响应，可能会导致RSVP-TE[RFC3209]等协议设置次优或错误
inappropriate LSPs. In addition, PCE itself can be a target for a variety of DoS attacks. Such attacks can cause path computations to be supplied too slowly to be of any value, particularly as it relates to recovery or establishment of LSPs.
不适当的LSP。此外，PCE本身可能成为各种DoS攻击的目标。此类攻击可能导致路径计算速度太慢，没有任何价值，特别是当它与LSP的恢复或建立相关时。
Finally, PCE discovery, as outlined in OSPF Protocol Extensions for PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE Discovery [RFC5089], is a significant feature for the successful deployment of PCEP in large networks. These mechanisms allow PCC to discover the existence of PCEs within the network. If the discovery mechanism is compromised, it will impair the ability of the nodes to function as described below.
最后，PCE发现，如用于PCE发现的OSPF协议扩展[RFC5088]和用于PCE发现的IS-IS协议扩展[RFC5089]所述，是在大型网络中成功部署PCEP的一个重要功能。这些机制允许PCC发现网络中是否存在PCE。如果发现机制受损，则会损害节点的功能，如下所述。
As RFC 5440 states, PCEP (which makes use of TCP as a transport) could be the target of the following attacks:
如RFC 5440所述，PCEP（利用TCP作为传输）可能成为以下攻击的目标：
o Spoofing (PCC or PCE implementation)
o 欺骗（PCC或PCE实施）
o Snooping (message interception)
o 窥探（消息截获）
o Falsification
o 伪造
o Denial of Service
o 拒绝服务
In inter-Autonomous System (inter-AS) scenarios where PCE-to-PCE communication is required, attacks may be particularly significant with commercial implications as well as service-level agreement implications.
在需要PCE到PCE通信的自治系统间（inter-AS）场景中，攻击可能特别严重，具有商业影响以及服务级别协议影响。
Additionally, snooping of PCEP requests and responses may give an attacker information about the operation of the network. By viewing the PCEP messages, an attacker can determine the pattern of service establishment in the network and can know where traffic is being routed, thereby making the network susceptible to targeted attacks and the data within specific LSPs vulnerable.
此外，窥探PCEP请求和响应可能会向攻击者提供有关网络操作的信息。通过查看PCEP消息，攻击者可以确定网络中的服务建立模式，并知道流量路由的位置，从而使网络容易受到目标攻击，并且特定LSP中的数据易受攻击。
Ensuring PCEP communication privacy is of key importance, especially in an inter-AS context, where PCEP communication endpoints do not reside in the same AS. An attacker that intercepts a PCE message could obtain sensitive information related to computed paths and resources.
确保PCEP通信隐私至关重要，特别是在AS间环境中，PCEP通信端点不位于AS内。拦截PCE消息的攻击者可能获得与计算路径和资源相关的敏感信息。
At the time PCEP was documented in [RFC5440], TCP-AO had not been fully specified. Therefore, [RFC5440] mandates that PCEP implementations include support for TCP MD5 and that use of the function should be configurable by the operator. [RFC5440] also describes the vulnerabilities and weaknesses of TCP MD5 as noted in this document. [RFC5440] goes on to state that PCEP implementations
在[RFC5440]中记录PCEP时，尚未完全指定TCP-AO。因此，[RFC5440]要求PCEP实现包括对TCP MD5的支持，并且该功能的使用应由操作员配置。[RFC5440]还描述了本文档中提到的TCP MD5的漏洞和弱点。[RFC5440]接着指出PCEP实施
should include support for TCP-AO as soon as that specification is complete. Since TCP-AO [RFC5925] has now been published, new PCEP implementations should fully support TCP-AO.
一旦该规范完成，就应该包括对TCP-AO的支持。由于TCP-AO[RFC5925]已经发布，新的PCEP实现应该完全支持TCP-AO。
Similar to BGP and LDP, the Multicast Source Distribution Protocol (MSDP) uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 option. But with a weak MD5 authentication, TCP MD5 is not considered strong enough for this application. It also does not support algorithm agility.
与BGP和LDP类似，多播源分发协议（MSDP）使用TCP MD5[RFC2385]通过TCP MD5选项保护TCP会话。但是，由于MD5身份验证较弱，因此认为TCP MD5对于该应用程序不够强大。它也不支持算法敏捷性。
MSDP advocates imposing a limit on the number of source address and group addresses (S,G) that can be cached within the protocol in order to mitigate state explosion due to any denial of service and other attacks.
MSDP主张对协议中可以缓存的源地址和组地址（S、G）的数量施加限制，以减轻由于拒绝服务和其他攻击而导致的状态爆炸。
The ideal state of the security method for BGP, LDP, PCEP, and MSDP protocols is when they can withstand any of the known types of attacks. The protocols also need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm.
BGP、LDP、PCEP和MSDP协议的安全方法的理想状态是它们能够抵御任何已知类型的攻击。协议还需要支持算法敏捷性，即它们不能将自己硬连接到一个算法。
Additionally, the KMP for the routing sessions should help negotiate unique, pair-wise random keys without administrator involvement. It should also negotiate Security Association (SA) parameters required for the session connection, including key lifetimes. It should keep track of those lifetimes and negotiate new keys and parameters before they expire and do so without administrator involvement. In the event of a breach, including when an administrator with knowledge of the keys leaves the company, the keys should be changed immediately.
此外，路由会话的KMP应该有助于在没有管理员参与的情况下协商唯一的、成对的随机密钥。它还应该协商会话连接所需的安全关联（SA）参数，包括密钥生存期。它应该跟踪这些生命周期，并在它们过期之前协商新的密钥和参数，这样做不需要管理员的参与。如果发生违规行为，包括知道钥匙的管理员离开公司时，应立即更换钥匙。
The DoS attacks for BGP, LDP, PCEP, and MSDP are attacks to the transport protocol -- TCP for the most part, and UDP in case of the discovery phase of LDP. TCP and UDP should be able to withstand any of the DoS scenarios by dropping packets that are attack packets in a way that does not impact legitimate packets.
对BGP、LDP、PCEP和MSDP的DoS攻击主要是对传输协议的攻击——TCP，LDP发现阶段的UDP。TCP和UDP应该能够以不影响合法数据包的方式丢弃属于攻击数据包的数据包，从而抵御任何DoS情况。
The routing protocols should provide a mechanism to authenticate the routing information carried within the payload, and administrators should enable it.
路由协议应该提供一种机制来验证负载中携带的路由信息，管理员应该启用它。
To mitigate LDP's current vulnerability to spoofing attacks, LDP needs to be upgraded such that an implementation is able to determine the authenticity of the neighbors sending the Hello message.
为了减轻LDP当前易受欺骗攻击的漏洞，LDP需要升级，以便实现能够确定发送Hello消息的邻居的真实性。
Labels are similar to routing information, which is distributed in the clear. However, there is currently no requirement that the labels be encrypted. Such a requirement is out of scope for this document.
标签类似于路由信息，它分布在clear中。但是，目前没有要求对标签进行加密。此类要求超出了本文件的范围。
Similarly, it is important to ensure that routers exchanging labels are mutually authenticated, and that there are no rogue peers or unauthenticated peers that can compromise the stability of the network.
同样，重要的是要确保交换标签的路由器是相互认证的，并且不存在可能危及网络稳定性的恶意对等点或未经认证的对等点。
This section outlines the differences between the current state of the security methods for routing protocols and the desired state of the security methods as outlined in Section 4.2 of the KARP Design Guidelines [RFC6518]. As that document states, these routing protocols fall into the category of one-to-one peering messages and will use peer keying protocols. This section covers issues that are common to the four protocols, leaving protocol-specific issues to sub-sections.
本节概述了路由协议安全方法的当前状态与KARP设计指南[RFC6518]第4.2节所述安全方法的期望状态之间的差异。正如该文件所述，这些路由协议属于一对一对等消息的范畴，将使用对等键控协议。本节涵盖四个协议的共同问题，将协议特定问题留给各小节处理。
At a transport level, these routing protocols are subject to some of the same attacks that TCP applications are subject to. These include DoS and spoofing attacks. "Internet Denial-of-Service Considerations" [RFC4732] outlines some solutions. "Defending TCP Against Spoofing Attacks" [RFC4953] recommends ways to prevent spoofing attacks. In addition, the recommendations in [RFC5961] should also be followed and implemented to strengthen TCP.
在传输级别上，这些路由协议受到的攻击与TCP应用程序受到的攻击相同。这些攻击包括拒绝服务攻击和欺骗攻击。“Internet拒绝服务注意事项”[RFC4732]概述了一些解决方案。“保护TCP免受欺骗攻击”[RFC4953]推荐了防止欺骗攻击的方法。此外，还应遵循并实施[RFC5961]中的建议，以加强TCP。
Routers lack comprehensive key management and keys derived that they can use to authenticate data. As an example, TCP-AO [RFC5925], talks about coordinating keys derived from the Master Key Table (MKT) between endpoints, but the MKT itself has to be configured manually or through an out-of-band mechanism. Also, TCP-AO does not address the issue of connectionless reset, as it applies to routers that do not store MKT across reboots.
路由器缺乏全面的密钥管理和可用于验证数据的派生密钥。例如，TCP-AO[RFC5925]谈到协调端点之间从主密钥表（MKT）派生的密钥，但MKT本身必须手动或通过带外机制进行配置。此外，TCP-AO没有解决无连接重置的问题，因为它适用于不跨重启存储MKT的路由器。
Authentication, integrity protection, and encryption all require the use of keys by sender and receiver. An automated KMP, therefore has to include a way to distribute key material between two endpoints with little or no administrative overhead. It has to cover automatic key rollover. It is expected that authentication will cover the packet, i.e., the payload and the TCP header, and will not cover the frame, i.e., the layer 2 header.
身份验证、完整性保护和加密都需要发送方和接收方使用密钥。因此，一个自动化的KMP必须包括一种在两个端点之间分配关键材料的方法，而不需要或很少需要管理开销。它必须覆盖自动钥匙翻转。预计认证将覆盖数据包，即有效负载和TCP报头，而不覆盖帧，即第2层报头。
There are two methods of automatic key rollover. Implicit key rollover can be initiated after a certain volume of data gets exchanged or when a certain time has elapsed. This does not require
有两种自动翻转钥匙的方法。隐式键翻转可以在交换一定量的数据后或在经过一定时间后启动。这不需要
explicit signaling nor should it result in a reset of the TCP connection in a way that the links/adjacencies are affected. On the other hand, explicit key rollover requires an out-of-band key signaling mechanism. It can be triggered by either side and can be done anytime a security parameter changes, e.g., an attack has happened, or a system administrator with access to the keys has left the company. An example of this is IKEv2 [RFC5996], but it could be any other new mechanisms also.
显式信令也不应以影响链路/邻接的方式导致TCP连接重置。另一方面，显式密钥翻转需要带外密钥信令机制。它可以由任何一方触发，并且可以在安全参数更改时执行，例如，发生攻击，或者有权访问密钥的系统管理员离开公司。IKEv2[RFC5996]就是一个例子，但它也可能是任何其他新机制。
As stated earlier, TCP-AO [RFC5925] and its accompanying document, Cryptographic Algorithms for TCP-AO [RFC5926], require that two MAC algorithms be supported, and they are HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility requirement.
如前所述，TCP-AO[RFC5925]及其随附文件TCP-AO加密算法[RFC5926]要求支持两种MAC算法，即HMAC[RFC2104]中规定的HMAC-SHA-1-96和NIST-SP800-38B[NIST-SP800-38B]中规定的AES-128-CMAC-96。因此，TCP-AO满足了算法敏捷性的要求。
There is a need to protect authenticity and validity of the routing/ label information that is carried in the payload of the sessions. However, that is outside the scope of this document and is being addressed by the SIDR WG. Similar mechanisms could be used for intra-domain protocols.
需要保护会话有效负载中承载的路由/标签信息的真实性和有效性。然而，这超出了本文件的范围，SIDR工作组正在解决这一问题。类似的机制可用于域内协议。
Finally, replay protection is required. The replay mechanism needs to be sufficient to prevent an attacker from creating a denial of service or disrupting the integrity of the routing protocol by replaying packets. It is important that an attacker not be able to disrupt service by capturing packets and waiting for replay state to be lost.
最后，需要重播保护。重播机制需要足以防止攻击者通过重播数据包来创建拒绝服务或破坏路由协议的完整性。重要的是，攻击者不能通过捕获数据包并等待重播状态丢失来中断服务。
As described in LDP [RFC5036], the threat of spoofed Basic Hellos can be reduced by only accepting Basic Hellos on interfaces that LSRs trust, employing GTSM [RFC5082], and ignoring Basic Hellos not addressed to the "all routers on this subnet" multicast group. Spoofing attacks via Targeted Hellos are potentially a more serious threat. An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting Hellos from sources permitted by access lists. However, performing the filtering using access lists requires LSR resources, and the LSR is still vulnerable to the IP source address spoofing. Spoofing attacks can be solved by being able to authenticate the Hello messages, and an LSR can be configured to only accept Hello messages from specific peers when authentication is in use.
如LDP[RFC5036]中所述，通过仅接受LSR信任的接口上的基本hello，使用GTSM[RFC5082]，并忽略未寻址到“此子网上的所有路由器”多播组的基本hello，可以减少欺骗基本hello的威胁。通过目标Hello进行的欺骗攻击可能是更严重的威胁。LSR可以通过过滤扩展Hello并从访问列表允许的源中接受Hello，从而降低欺骗扩展Hello的威胁。但是，使用访问列表执行过滤需要LSR资源，并且LSR仍然容易受到IP源地址欺骗的攻击。通过对Hello消息进行身份验证可以解决欺骗攻击，并且可以将LSR配置为在使用身份验证时仅接受来自特定对等方的Hello消息。
LDP Hello Cryptographic Authentication [HELLO-CRYPTO] suggest a new Cryptographic Authentication TLV that can be used as an authentication mechanism to secure Hello messages.
LDP Hello Cryptographic Authentication[Hello-CRYPTO]提出了一种新的加密身份验证TLV，可以用作保护Hello消息的身份验证机制。
Path Computation Element (PCE) discovery, according to [RFC5440], is a significant feature for the successful deployment of PCEP in large networks. This mechanism allows a Path Computation Client (PCC) to discover the existence of suitable PCEs within the network without the necessity of configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC cannot know the correct key to use. There are different approaches to retain some aspect of security, but all of them require use of a keys and a keying mechanism, the need for which has been discussed above.
根据[RFC5440]，路径计算元素（PCE）发现是在大型网络中成功部署PCEP的一个重要特征。该机制允许路径计算客户端（PCC）在不需要配置的情况下发现网络中是否存在合适的PCE。显然，在发现PCE且未配置PCE的情况下，PCC无法知道要使用的正确密钥。有不同的方法来保留某些方面的安全性，但所有这些方法都需要使用密钥和密钥机制，这方面的需要已经在上面讨论过了。
As stated in the KARP Design Guidelines [RFC6518], it is imperative that the new authentication, security mechanisms, and key management protocol support incremental deployment, as it is not feasible to deploy the new routing protocol authentication mechanism overnight.
正如KARP设计指南[RFC6518]所述，新的身份验证、安全机制和密钥管理协议必须支持增量部署，因为一夜之间部署新的路由协议身份验证机制是不可行的。
Typically, authentication and security in a peer-to-peer protocol requires that both parties agree to the mechanisms that will be used. If an agreement is not reached, the setup of the new mechanism will fail or will be deferred. Upon failure, the routing protocols can fall back to the mechanisms that were already in place, e.g., use static keys if that was the mechanism in place. The fallback should be configurable on a per-node or per-interface basis. It is usually not possible for one end to use the new mechanism while the other end uses the old. Policies can be put in place to retry upgrading after a said period of time, so that manual coordination is not required.
通常，对等协议中的身份验证和安全性要求双方同意将使用的机制。如果未能达成协议，新机制的建立将失败或推迟。一旦失败，路由协议可以退回到已经存在的机制，例如，如果该机制存在，则使用静态密钥。应在每个节点或每个接口的基础上配置回退。通常情况下，一端使用新机构，另一端使用旧机构是不可能的。可以制定策略，在所述时间段后重试升级，因此不需要手动协调。
If the automatic KMP requires use of Public Key Infrastructure Certificates [RFC5280] to exchange key material, the required Certificate Authority (CA) root certificates may need to be installed to verify the authenticity of requests initiated by a peer. Such a step does not require coordination with the peer, except to decide which CA authority will be used.
如果自动KMP需要使用公钥基础设施证书[RFC5280]来交换密钥资料，则可能需要安装所需的证书颁发机构（CA）根证书，以验证对等方发起的请求的真实性。这样的步骤不需要与对等方协调，除非决定将使用哪个CA权限。
This section describes security considerations that BGP, LDP, PCEP, and MSDP should try to meet.
本节描述了BGP、LDP、PCEP和MSDP应尽量满足的安全注意事项。
As with all routing protocols, they need protection from both on-path and off-path blind attacks. A better way to protect them would be with per-packet protection using a cryptographic MAC. In order to provide for the MAC, keys are needed.
与所有路由协议一样，它们需要防止路径上和路径外的盲攻击。更好的保护方法是使用加密MAC对每个数据包进行保护。为了提供MAC，需要密钥。
The routing protocols need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm.
路由协议需要支持算法敏捷性，即它们不能将自己硬连接到一个算法。
Once keys are used, mechanisms are required to support key rollover. They should cover both manual and automatic key rollover. Multiple approaches could be used. However, since the existing mechanisms provide a protocol field to identify the key as well as management mechanisms to introduce and retire new keys, focusing on the existing mechanism as a starting point is prudent.
使用钥匙后，需要使用机构来支持钥匙翻转。它们应包括手动和自动钥匙翻转。可以使用多种方法。然而，由于现有机制提供了一个协议字段来识别密钥以及引入和淘汰新密钥的管理机制，因此将现有机制作为起点是谨慎的。
Furthermore, it is strongly suggested that these routing protocols support algorithm agility. It has been proven that algorithms weaken over time. Supporting algorithm agility assists in smooth transitions from old to new algorithms.
此外，强烈建议这些路由协议支持算法敏捷性。事实证明，算法会随着时间的推移而减弱。支持算法敏捷性有助于从旧算法到新算法的平稳过渡。
We would like to thank Brian Weis for encouraging us to write this document, and thanks to Anantha Ramaiah and Mach Chen for providing comments on it.
我们要感谢Brian Weis鼓励我们编写本文件，并感谢Anantha Ramaiah和Mach Chen对本文件的评论。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，2010年6月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518]Lebovitz，G.和M.Bhatia，“路由协议的键控和认证（KARP）设计指南”，RFC 6518，2012年2月。
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6863]Hartman，S.和D.Zhang，“根据路由协议键控和认证（KARP）设计指南分析OSPF安全性”，RFC 6863，2013年3月。
[HELLO-CRYPTO] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, January 2013.
[HELLO-CRYPTO]Zheng，L.，Chen，M.，和M.Bhatia，“LDP HELLO加密认证”，正在进行的工作，2013年1月。
[NIST-SP800-38B] Dworking, , "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005.
[NIST-SP800-38B]Dworking，“分组密码操作模式的建议：认证的CMAC模式”，2005年5月。
[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月。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006.
[RFC4595]Maino，F.和D.Black，“在光纤通道安全关联管理协议中使用IKEv2”，RFC 45952006年7月。
[RFC4674] Le Roux, J.L., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.L.，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“IAB 2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，2007年8月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP。和JL。Le Roux，“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[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月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 59612010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039]Manral，V.，Bhatia，M.，Jaeggli，J.，和R.White，“路由协议现有加密保护方法的问题”，RFC 6039，2010年10月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，2012年2月。
Authors' Addresses
作者地址
Mahesh Jethanandani Ciena Corporation 1741 Technology Drive San Jose, CA 95110 USA
美国加利福尼亚州圣何塞市技术大道1741号马赫什·杰塔南达尼·西纳公司，邮编95110
Phone: +1 (408) 436-3313
EMail: mjethanandani@gmail.com
Phone: +1 (408) 436-3313
EMail: mjethanandani@gmail.com
Keyur Patel Cisco Systems, Inc 170 Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道170号凯尔帕特尔思科系统公司，邮编95134
Phone: +1 (408) 526-7183
EMail: keyupate@cisco.com
Phone: +1 (408) 526-7183
EMail: keyupate@cisco.com
Lianshu Zheng Huawei Technologies China
华为技术中国有限公司
Phone: +86 (10) 82882008
EMail: vero.zheng@huawei.com
Phone: +86 (10) 82882008
EMail: vero.zheng@huawei.com