Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6862
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
B. Weis
Cisco Systems
March 2013
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6862
Category: Informational M. Bhatia
ISSN: 2070-1721 Alcatel-Lucent
B. Weis
Cisco Systems
March 2013
Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
路由协议的密钥和身份验证（KARP）概述、威胁和要求
Abstract
摘要
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.
不同的路由协议采用不同的机制来保护线路上的协议包。虽然大多数已经有了一些实现加密消息身份验证的方法，但在许多情况下，现有的方法已经过时，容易受到攻击，并且使用了不推荐使用的加密算法。“路由协议的键控和认证”（KARP）工作旨在彻底检查和改进这些机制。本文件不包含协议规范。相反，它定义了需要协议规范工作的领域。本文件是RFC 6518“路由协议的密钥和认证（KARP）设计指南”的配套文件；它们共同构成了KARP设计团队用于审查和检修路由协议传输安全性的指导和说明。
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/rfc6862.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6862.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. KARP Effort Overview . . . . . . . . . . . . . . . . . . . . . 7
2.1. KARP Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Incremental Approach . . . . . . . . . . . . . . . . . . . 8
2.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Threat Sources . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. OUTSIDERS . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Unauthorized Key Holder . . . . . . . . . . . . . . . 14
3.1.2.1. Terminated Employee . . . . . . . . . . . . . . . 15
3.1.3. BYZANTINE . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Threat Actions In Scope . . . . . . . . . . . . . . . . . 16
3.3. Threat Actions Out of Scope . . . . . . . . . . . . . . . 17
4. Requirements for KARP Work Phase 1: Update to a Routing
Protocol's Existing Transport Security . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. KARP Effort Overview . . . . . . . . . . . . . . . . . . . . . 7
2.1. KARP Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Incremental Approach . . . . . . . . . . . . . . . . . . . 8
2.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Threat Sources . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1. OUTSIDERS . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Unauthorized Key Holder . . . . . . . . . . . . . . . 14
3.1.2.1. Terminated Employee . . . . . . . . . . . . . . . 15
3.1.3. BYZANTINE . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Threat Actions In Scope . . . . . . . . . . . . . . . . . 16
3.3. Threat Actions Out of Scope . . . . . . . . . . . . . . . 17
4. Requirements for KARP Work Phase 1: Update to a Routing
Protocol's Existing Transport Security . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic "Unwanted Internet Traffic". The report from that workshop is documented in [RFC4948]. Section 8.1 of that document states, "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure". Section 8.2 calls for "[t]ightening the security of the core routing infrastructure". Four main steps were identified for that tightening:
2006年3月，互联网架构委员会（IAB）举办了一次关于“不必要的互联网流量”主题的研讨会。该研讨会的报告记录在[RFC4948]中。该文件第8.1节指出，“简单的风险分析表明，成本最低但中断最大的理想攻击目标是核心路由基础设施”。第8.2节要求“加强核心路由基础设施的安全性”。确定了拧紧的四个主要步骤：
o Create secure mechanisms and practices for operating routers.
o 创建操作路由器的安全机制和实践。
o Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access to it, so that it can be used for routing verification.
o 清理Internet路由注册表（IRR）存储库，确保数据库及其访问的安全，以便将其用于路由验证。
o Create specifications for cryptographic validation of routing message content.
o 为路由消息内容的加密验证创建规范。
o Secure the routing protocols' packets on the wire
o 在线路上保护路由协议的数据包
The first bullet is being addressed in the OPSEC working group. The second bullet should be addressed through liaisons with those running the IRR's globally. The third bullet is being addressed in other efforts within the IETF. For example, BGP message content validity is being addressed in the SIDR working group.
OPSEC工作组正在处理第一个问题。第二个问题应该通过与那些在全球运行IRR的人联系来解决。IETF内的其他工作正在解决第三个问题。例如，SIDR工作组正在处理BGP消息内容有效性问题。
This document addresses the last item in the list above, securing the transmission of routing protocol packets on the wire. More precisely, it focuses on securing the transport systems employed by routing protocols, including any mechanisms built into the protocols themselves to authenticate packets. This effort is referred to as Keying and Authentication for Routing Protocols, or "KARP". KARP is concerned with issues and techniques for protecting the messages between directly communicating peers. This type of protection may overlap with, but is strongly distinct from, protection designed to ensure that routing information is properly authorized relative to the source of the information. Such assurances are provided by other mechanisms and are outside the scope of this document.
本文档介绍了上面列表中的最后一项，即保护路由协议数据包在线路上的传输。更准确地说，它关注于保护路由协议所使用的传输系统，包括协议本身内置的用于验证数据包的任何机制。这项工作被称为路由协议的密钥和身份验证，或“KARP”。KARP关注的是保护直接通信的对等方之间的消息的问题和技术。这种类型的保护可能与旨在确保路由信息相对于信息源得到适当授权的保护重叠，但与之截然不同。此类保证由其他机制提供，不在本文件范围内。
This document is one of two that together form the guidance and instructions for KARP design teams working to overhaul routing protocol transport security. The other document is the KARP Design Guide [RFC6518].
本文件是两份文件之一，共同构成了KARP设计团队致力于彻底检查路由协议传输安全性的指南和说明。另一份文件是KARP设计指南[RFC6518]。
This document does not contain protocol specifications. Instead, its goal is to define the areas where protocol specification work is needed and to provide a set of requirements for KARP design teams to follow as they update a routing protocol's existing transport security (see Work Phase 1 in Section 4.1 of [RFC6518]).
本文件不包含协议规范。相反，其目标是定义需要协议规范工作的领域，并为KARP设计团队在更新路由协议的现有传输安全性时提供一系列要求（见[RFC6518]第4.1节中的工作阶段1）。
This document has three main parts. The first part, found in Section 2, provides an overview of the KARP effort. The second part, in Section 3, lists the threats from "Generic Threats To Routing Protocols" [RFC4593] that are in scope for per-packet authentication for routing protocol transport systems. Therefore, this document does not contain a complete threat model; it simply points to the parts of the governing threat model that KARP design teams must address and explicitly states which parts are out of scope for KARP design teams. The third part, in Section 4, enumerates the requirements that routing protocol specifications must meet when addressing the threats related to KARP's Work Phase 1, the update to a routing protocol's existing transport security. ("Work Phase 2", a framework and usage of a Key Management Protocol (KMP), will be addressed in a future document[s]).
本文件有三个主要部分。第一部分（见第2节）概述了KARP工作。第二部分，在第3节中，列出了“路由协议的一般威胁”[RFC4593]的威胁，这些威胁属于路由协议传输系统的每包身份验证的范围。因此，本文件不包含完整的威胁模型；它简单地指出了KARP设计团队必须解决的主要威胁模型部分，并明确指出哪些部分超出了KARP设计团队的范围。第三部分在第4节中列举了路由协议规范在解决与KARP工作阶段1（路由协议现有传输安全的更新）相关的威胁时必须满足的要求。（“工作阶段2”是密钥管理协议（KMP）的框架和用法，将在未来的文件中讨论）。
This document uses the terminology "on the wire" to refer to the information used by routing protocols' transport systems. This term is widely used in RFCs, but is used in several different ways. In this document, it is used to refer both to information exchanged between routing protocol instances and to underlying protocols that may also need to be protected in specific circumstances. Individual protocol analysis documents will need to be more specific in their use of this phrase.
本文档使用术语“在线”来指代路由协议传输系统使用的信息。该术语在RFC中广泛使用，但有几种不同的用法。在本文档中，它既指路由协议实例之间交换的信息，也指在特定情况下可能需要保护的底层协议。个别协议分析文件在使用该短语时需要更加具体。
Additionally, within the scope of this document, the following words, when beginning with a capital letter, or spelled in all capital letters, hold the meanings described in this section. If the same word is used uncapitalized, then it is intended to have its common English definition.
此外，在本文件范围内，以下词语以大写字母开头或以所有大写字母拼写时，具有本节所述含义。如果同一个单词没有大写，那么它将有其通用的英语定义。
Identifier The type and value used by a peer of an authenticated message exchange to signify who it is to another peer. The Identifier is used by the receiver as an index into a table containing further information about the peer that is required to continue processing the message, for example a Security Association (SA) or keys.
标识符经过身份验证的消息交换的对等方使用的类型和值，用于向另一个对等方表示该对等方是谁。接收方将该标识符用作表的索引，该表包含继续处理该消息所需的关于对等方的进一步信息，例如安全关联（SA）或密钥。
Identity Authentication Once the identity is verified, there must be a cryptographic proof of that identity, to ensure that the peer really is who it asserts to be. Proof of identity can be arranged among peers in a few ways, for example, symmetric and asymmetric pre-shared keys, or an asymmetric key contained in a certificate. Certificates can be used in ways that require no additional supporting systems external to the routers themselves. An example of this is using self-signed certificates and a flat file list of "approved thumbprints". The different identity verification mechanisms vary in ease of deployment, ease of ongoing management, startup effort, security strength, and consequences from loss of secrets from one part of the system to the rest of the system. For example, they differ in resistance to a security breach, and the effort required to recover in the event of such a breach. The point here is that there are options, many of which are quite simple to employ and deploy.
身份验证身份验证后，必须有该身份的加密证明，以确保对等方确实是其声称的身份。可以通过几种方式在对等方之间安排身份证明，例如，对称和非对称预共享密钥，或者证书中包含的非对称密钥。证书的使用方式不需要路由器本身之外的额外支持系统。例如，使用自签名证书和“已批准指纹”的平面文件列表。不同的身份验证机制在部署的易用性、日常管理的易用性、启动工作、安全强度以及从系统的一部分到系统的其余部分丢失机密的后果等方面都有所不同。例如，它们在对安全漏洞的抵抗力以及在发生此类漏洞时恢复所需的努力方面有所不同。这里的要点是有一些选项，其中许多选项的使用和部署都非常简单。
KDF (Key Derivation Function) A KDF is a function in which an input key and other input data are used to generate keying material that can be employed by cryptographic algorithms. The key that is input to a KDF is called a key derivation key. KDFs can be used to generate one or more keys from (i) a random or pseudorandom seed value, or (ii) the result of the Diffie-Hellman exchange, or (iii) a non-uniform random source (e.g., from a non-deterministic random bit generator), or (iv) a pre-shared key that may or may not be memorable by a human.
KDF（密钥派生函数）KDF是一种函数，其中输入密钥和其他输入数据用于生成可由加密算法使用的密钥材料。输入到KDF的密钥称为密钥派生密钥。KDF可用于从（i）随机或伪随机种子值，或（ii）Diffie-Hellman交换的结果，或（iii）非均匀随机源（例如，来自非确定性随机比特生成器），或（iv）人类可能会或可能不会记住的预共享密钥生成一个或多个密钥。
KMP (Key Management Protocol) KMP is a protocol that establishes a shared symmetric key between a pair (or among a group) of users. It determines how secret keys are made available to the users, and in some cases also determines how the secret keys are generated. In some routing protocols, the routing protocol derives the traffic keys from a master key. In this case, KMP is responsible for the master-key generation and for determining when the master key should be renewed. In other cases, there are only traffic keys (and no master key); in such a case, KMP is responsible for the traffic key generation and renewal mechanism.
KMP（密钥管理协议）KMP是在一对（或一组）用户之间建立共享对称密钥的协议。它确定如何向用户提供密钥，在某些情况下还确定如何生成密钥。在某些路由协议中，路由协议从主密钥派生流量密钥。在这种情况下，KMP负责生成主密钥，并确定主密钥应在何时更新。在其他情况下，只有交通钥匙（没有主钥匙）；在这种情况下，KMP负责流量密钥的生成和更新机制。
KMP Function Any KMP used in the general KARP solution framework.
KMP函数通用KARP解决方案框架中使用的任何KMP。
Peer Key Peer keys are keys that are used among peers as a basis for identifying one another. These keys may or may not be connection specific, depending on how they were established, and what forms
对等密钥对等密钥是在对等方之间用作相互识别基础的密钥。这些键可能是特定于连接的，也可能不是特定于连接的，这取决于它们是如何建立的，以及它们的形式
of identity and identity authentication mechanism are used in the system. A peer key generally would be provided by a KMP and would later be used to derive fresh traffic keys.
系统采用了身份认证和身份认证机制。对等密钥通常由KMP提供，稍后将用于派生新的流量密钥。
PSK (Pre-Shared Key) A PSK is a key used to communicate with one or more peers in a secure configuration. It is always distributed out of band prior to a first connection.
PSK（预共享密钥）PSK是用于在安全配置中与一个或多个对等方通信的密钥。在第一次连接之前，它始终分布在带外。
Replayed Messages Replayed messages are genuine messages that have been re-sent by an attacker. Messages may be replayed within a session (i.e., intra-session) or replayed from a different session (i.e., inter-session). For non-TCP-based protocols like OSPF [RFC2328] and IS-IS [RFC1195], two routers are said to have a session up if they are able to exchange protocol packets (i.e., the peers have an adjacency). Messages replayed during an adjacency are intra-session replays, while a message replayed between two peers who re-establish an adjacency after a reboot or loss of connectivity are inter-session replays.
重播消息重播消息是攻击者重新发送的真实消息。消息可以在会话内（即，会话内）重播，也可以从不同会话（即，会话间）重播。对于OSPF[RFC2328]和IS-IS[RFC1195]等基于非TCP的协议，如果两个路由器能够交换协议包（即，对等点具有邻接性），则称它们具有会话启动。邻接期间重播的消息是会话内重播，而在重新启动或失去连接后重新建立邻接的两个对等方之间重播的消息是会话间重播。
Routing Protocol This term refers to a Routing Protocol on which a KARP team is working to improve the security of its packets on the wire.
路由协议这一术语指的是一种路由协议，KARP团队正致力于改善其数据包在线路上的安全性。
SA (Security Association) An SA is a relationship established between two or more entities to enable them to protect the data they exchange. Examples of attributes that may be associated with an SA include Identifier, PSK, Traffic Key, cryptographic algorithms, and key lifetimes.
SA（安全关联）SA是两个或多个实体之间建立的关系，使它们能够保护它们交换的数据。可与SA相关联的属性的示例包括标识符、PSK、业务密钥、加密算法和密钥寿命。
Threat Source A threat source is a motivated, capable adversary.
威胁源威胁源是一个有动力、有能力的对手。
Traffic Key A Traffic Key is the key (or one of a set of keys) used for protecting the routing protocol traffic. A traffic key should not be a fixed value in a device configuration. A traffic key should be known only to the participants in a connection, so that a compromise of a stored key (possibly available to a terminated or turned employee) does not result in disclosure of traffic keys. If a server or other data store is stolen or compromised, the attackers gain no access to current traffic keys. They may gain access to key-derivation material, like a PSK, but not traffic keys currently in use.
流量密钥流量密钥是用于保护路由协议流量的密钥（或一组密钥中的一个）。在设备配置中，流量密钥不应是固定值。通信密钥应仅为连接中的参与者所知，以便存储密钥的泄露（可能对终止或转职的员工可用）不会导致通信密钥的泄露。如果服务器或其他数据存储被盗或受损，攻击者将无法访问当前的通信密钥。他们可以访问密钥派生材料，如PSK，但不能访问当前使用的流量密钥。
Additional terminology specific to threats are listed and defined below in Section 3.
下文第3节列出并定义了特定于威胁的其他术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC 2119.
当以小写形式使用时，这些词以通用语言表达其典型用法，不应按照RFC 2119中所述进行解释。
Three basic principles can be used to secure any piece of data as it is transmitted over the wire: confidentiality, authenticity, and integrity. The focus for the KARP working group will be message authentication and message integrity only. At this time, this work explicitly excludes confidentiality. Non-repudiation is also excluded as a goal at this time. Since the objective of most routing protocols is to broadly advertise the routing topology, routing protocol packets are commonly sent in the clear; confidentiality is not normally required for routing protocols. However, ensuring that routing peers are authentically identified and that no rogue peers or unauthenticated packets can compromise the stability of the routing environment are critical and thus in scope. Confidentiality and non-repudiation may be addressed in future work.
当数据通过线路传输时，可以使用三个基本原则来保护数据：机密性、真实性和完整性。KARP工作组的重点将仅限于消息身份验证和消息完整性。目前，这项工作明确排除了保密性。不可抵赖性也是目前的一个目标。由于大多数路由协议的目标是广泛宣传路由拓扑，因此路由协议包通常以清晰的方式发送；路由协议通常不需要保密。然而，确保路由对等点被真实地识别，并且没有恶意对等点或未经验证的数据包会损害路由环境的稳定性是至关重要的，因此在范围内也是如此。保密性和不可否认性可能会在未来的工作中得到解决。
OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP [RFC2453] [RFC4822] already incorporate mechanisms for cryptographically authenticating and integrity checking the messages on the wire. Products and code that incorporate these mechanisms have been produced and have been optimized for these existing security mechanisms. Rather than turn away from these mechanisms, this document aims to enhance them, updating them to modern and more secure levels.
OSPF[RFC5709]、IS-IS[RFC5310]、LDP[RFC5036]和RIP[RFC2453][RFC4822]已经整合了用于加密验证和完整性检查在线消息的机制。已经生成了包含这些机制的产品和代码，并针对这些现有安全机制进行了优化。本文件旨在加强这些机制，将其更新到现代和更安全的水平，而不是放弃这些机制。
Therefore, the scope of KARP's roadmap of work includes:
因此，KARP工作路线图的范围包括：
o Making use of existing routing protocol transport security mechanisms, where they have been specified, and enhancing or updating them as necessary for modern cryptographic best practices. [RFC6518], Section 4.1 labels this KARP's Work Phase 1.
o 利用现有的路由协议传输安全机制（已指定），并根据现代密码最佳实践的需要对其进行增强或更新。[RFC6518]，第4.1节标记了该KARP的工作阶段1。
o Developing a framework for using automatic key management in order to ease deployment, lower cost of operation, and allow for rapid responses to security breaches. [RFC6518], Section 4.1 labels this KARP's Work Phase 2.
o 开发一个使用自动密钥管理的框架，以简化部署、降低操作成本，并允许对安全漏洞做出快速响应。[RFC6518]，第4.1节标记了KARP的第2阶段工作。
o Specifying an automated key management protocol that may be combined with Routing Protocol mechanisms. [RFC6518], Section 4.1 labels this KARP's Work Phase 2.
o 指定可与路由协议机制相结合的自动密钥管理协议。[RFC6518]，第4.1节标记了KARP的第2阶段工作。
Neither this document nor [RFC6518] contains protocol specifications. Instead, they define the areas in which protocol specification work is needed, and they set a direction, a set of requirements, and priorities for addressing that specification work.
本文件和[RFC6518]均不包含协议规范。相反，它们定义了需要协议规范工作的领域，并为解决该规范工作设定了方向、需求集和优先级。
There are a set of threats to routing protocols that are considered in scope for KARP, and a set considered out of scope. These are described in detail in Section 3.
有一组对路由协议的威胁被认为是KARP的范围内的，还有一组被认为是范围外的。第3节详细描述了这些问题。
This document serves as an agreement between the Routing Area and the Security Area about the priorities and work plan for incrementally delivering the work described in the KARP roadmap above. The principle of "crawl, walk, run" will be employed. Thus routing protocol authentication mechanisms may not go immediately from their current state to a state reflecting the best possible, most modern security practices. This point is important as there will be times when the best security possible will give way to security that is vastly improved over current security but that is admittedly not the best security possible, in order that incremental progress toward a more secure Internet may be achieved. As such, this document will call out places where agreement has been reached on such trade-offs.
本文件作为路由区域和安全区域之间关于优先级和工作计划的协议，以逐步交付上述KARP路线图中所述的工作。将采用“爬、走、跑”的原则。因此，路由协议认证机制可能不会立即从其当前状态变为反映最佳、最现代安全实践的状态。这一点很重要，因为有时，最好的安全性将让位给比当前安全性大大提高的安全性，但不可否认，这并不是最好的安全性，以便朝着更安全的互联网取得渐进的进展。因此，本文件将指出就此类权衡达成协议的地方。
Incremental steps will need to be taken for a few very practical reasons. First, there are a considerable number of deployed routing devices in operating networks that will not be able to run the most modern cryptographic mechanisms without significant and unacceptable performance penalties. The roadmap for any routing protocol MUST allow for incremental improvements on existing operational devices. Second, current routing protocol performance on deployed devices has been achieved over the last 20 years through extensive tuning of software and hardware elements, and is a constant focus for improvement by vendors and operators alike. The introduction of new security mechanisms affects this performance balance. The performance impact of any incremental security improvement will need to be weighed by the community and introduced in such a way that allows the vendor and operator community a path to adoption that upholds reasonable performance metrics. Therefore, certain specification elements may be introduced carrying the "SHOULD" guidance, with the intention that the same mechanism will carry a "MUST" in a future release of the specification. This approach gives the vendors and implementors the guidance they need to tune their software and hardware appropriately over time. Last, some security
出于一些非常实际的原因，需要采取渐进的步骤。首先，在操作网络中有大量已部署的路由设备，如果没有重大且不可接受的性能损失，将无法运行最现代的加密机制。任何路由协议的路线图都必须允许对现有操作设备进行增量改进。第二，在过去20年中，通过广泛调整软件和硬件元素，在已部署设备上实现了当前路由协议性能，这是供应商和运营商不断改进的重点。引入新的安全机制会影响这种性能平衡。社区需要权衡任何增量安全改进对性能的影响，并以允许供应商和运营商社区采用合理性能指标的方式引入。因此，可能引入带有“应该”指导的某些规范元素，目的是在规范的未来版本中，相同的机制将带有“必须”。这种方法为供应商和实现人员提供了所需的指导，以便随着时间的推移适当地调整其软件和硬件。最后，一些安全措施
mechanisms require the build-out of other operational support systems, which will take time.
机制需要建立其他业务支持系统，这需要时间。
An example where these three steps were at play in an incremental improvement roadmap was the improvement of BGP's [RFC4271] security via the TCP Authentication Option (TCP-AO) [RFC5925] effort. It would have been ideal, and would have reflected best common security practice, to have a fully specified key management protocol for negotiating the TCP-AO keying material, e.g., using certificates for peer authentication. However, in the spirit of incremental deployment, the IETF first addressed issues like cryptographic algorithm agility, replay attacks, and the resetting of TCP sessions in the base TCP-AO protocol, and then later began work to layer key management on top of these.
这三个步骤在增量改进路线图中起作用的一个例子是通过TCP认证选项（TCP-AO）[RFC5925]努力改进BGP的[RFC4271]安全性。如果有一个完全指定的密钥管理协议来协商TCP-AO密钥材料（例如，使用证书进行对等身份验证），这将是理想的，并且反映了最佳的通用安全实践。然而，本着增量部署的精神，IETF首先解决了诸如加密算法敏捷性、重放攻击和在基本TCP-AO协议中重置TCP会话等问题，然后开始在这些问题之上分层密钥管理。
The goals and general guidance for the KARP work follow:
KARP工作的目标和一般指导如下：
1. Provide authentication and integrity protection for messages on the wire for existing routing protocols.
1. 为现有路由协议的在线消息提供身份验证和完整性保护。
2. Define a path to incrementally improve security of the routing infrastructure as explained in Section 2.2.
2. 如第2.2节所述，定义一条路径，以逐步提高路由基础设施的安全性。
3. Ensure that the improved security solutions are deployable on current routing infrastructure. This requires consideration of the current state of processing power available on routers in the network today.
3. 确保改进的安全解决方案可部署在当前路由基础架构上。这需要考虑当前网络中路由器上可用的处理能力的状态。
4. Operational deployability - A solution's acceptability also will be measured by how deployable the solution is by operator teams, with consideration for their deployment processes and infrastructures. Specifically, KARP design teams will try to make these solutions fit as well as possible into current operational practices and router deployment methodologies. Doing so will depend heavily on operator input during KARP design efforts. Hopefully, operator input will lead to a more deployable solution, which will, in turn, lead to more production deployments. Deployment of incrementally more secure routing infrastructure in the Internet is the final measure of success. We would like to see an increase in the number of respondents to surveys such as [ISR2008] to report deployment of the updated authentication and integrity mechanisms in their networks, as well as see a sharp rise in usage of these mechanisms across a greater percentage of their network's routers.
4. 运营可部署性-解决方案的可接受性还将通过运营商团队部署解决方案的方式来衡量，并考虑其部署流程和基础设施。具体而言，KARP设计团队将努力使这些解决方案尽可能适合当前的运营实践和路由器部署方法。这样做在很大程度上取决于KARP设计工作期间的操作员输入。希望运营商的投入将带来一个更具可部署性的解决方案，从而带来更多的生产部署。在互联网上部署越来越安全的路由基础设施是成功的最终衡量标准。我们希望看到[ISR2008]等调查的受访者人数有所增加，以报告在其网络中部署了更新的身份验证和完整性机制，并且这些机制在其网络路由器中的使用率大幅上升。
Interviews with operators show several points about routing security. First, according to [ISR2008], over 70% of operators have deployed transport connection protection via TCP MD5 [RFC3562] on their External Border Gateway Protocol (eBGP) sessions. Over 55% also deploy TCP MD5 on their Internal Border Gateway Protocol (iBGP) connections, and 50% make use of TCP MD5 offered on some other internal gateway protocol (IGP). The same survey states that "a considerable increase was observed over previous editions of the survey for use of TCP MD5 with external peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs." Though the data is not captured in the report, the authors believe anecdotally that of those who have deployed TCP MD5 somewhere in their network, only about 25-30% of the routers in their network are deployed with the authentication enabled. None report using IPsec [RFC4301] to protect the routing protocol, which was a decline from the few that reported doing so in the previous year's report. Anecdotal evidence from operators using MD5 shows that almost all report using one manually distributed key throughout the entire network. These same operators report that the single key has not been changed since it was originally installed, sometimes five or more years ago. When asked why, particularly for the case of protecting BGP sessions using TCP MD5, the following reasons were often given:
对运营商的采访表明了关于路由安全的几点。首先，根据[ISR2008]，超过70%的运营商已经在其外部边界网关协议（eBGP）会话上通过TCP MD5[RFC3562]部署了传输连接保护。超过55%的用户还在其内部边界网关协议（iBGP）连接上部署TCP MD5，50%的用户使用其他一些内部网关协议（IGP）上提供的TCP MD5。同一项调查指出，“与之前版本的调查相比，使用TCP MD5与外部对等点（eBGP）、内部对等点（iBGP）和IGP的MD5扩展的调查发现了显著的增长。”尽管报告中没有收集到数据，但作者相信，在他们的网络某处部署了TCP MD5的人，在他们的网络中，只有大约25-30%的路由器是在启用身份验证的情况下部署的。没有人报告使用IPsec[RFC4301]来保护路由协议，这与去年报告中报告使用IPsec[RFC4301]保护路由协议的少数人相比有所下降。来自使用MD5的运营商的传闻证据表明，几乎所有报告都使用一个手动分发的密钥覆盖整个网络。这些运营商报告说，单钥匙自最初安装以来（有时是五年或更多年前）一直没有更改。当被问及原因时，特别是在使用TCP MD5保护BGP会话的情况下，通常给出以下原因：
A. Changing the keys triggers a TCP reset, and thus the links/ adjacencies bounce, undermining Service Level Agreements (SLAs).
A.更改密钥会触发TCP重置，因此链路/邻接会反弹，从而破坏服务级别协议（SLA）。
B. For external peers, it is difficult to coordinate with the other organization, and in practice the coordination is very cumbersome and tedious to execute. Once the operator finds the correct contact at the other organization (not always so easy), the coordination function is serialized and performed on a per-peer or per-AS basis.
B.对于外部同行，很难与其他组织进行协调，在实践中，协调非常繁琐，执行起来也很繁琐。一旦操作员在另一个组织找到正确的联系人（并不总是那么容易），协调功能将被序列化，并在每个对等方或每个AS的基础上执行。
C. Keys must be changed at precisely the same time, or at least within 60 seconds (as supported by two major vendors) in order to limit the duration of a connectivity outage. This is incredibly difficult to do, operationally, especially between different organizations.
C.钥匙必须同时更换，或至少在60秒内更换（由两大供应商支持），以限制连接中断的持续时间。这在操作上是非常困难的，特别是在不同的组织之间。
D. Key change is perceived as a relatively low priority compared to other operational issues.
D.与其他运营问题相比，关键变更被视为相对较低的优先级。
E. Staff levels are insufficient to implement the changes on a device-by-device basis.
E.员工水平不足以逐个设备实施变更。
F. There are three use cases for operational peering at play: peers and interconnection with other operators, iBGP and other routing sessions within a single operator, and operator-to-customer devices. All three have very different properties, and all are reported as cumbersome to manage securely. One operator reported that the same key is used for all customer premise equipment (CPE). The same operator reported that if the customer mandated it, a unique key could be created, although the last time this occurred, it created such an operational headache that the administrators now usually tell customers that the option doesn't even exist, to avoid the difficulties. These customer-unique keys are never changed, unless the customer demands so. The main threat here is that a terminated employee from such an operator who had access to the one (or several) keys used for authentication in these environments could wage an attack. Alternatively, the operator could offer the keys to others who would wage the attack. In either case, the attacker could then bring down many of the adjacencies, thus destabilizing the routing system.
F.运营对等有三种使用情形：对等和与其他运营商的互连、单个运营商内的iBGP和其他路由会话，以及运营商到客户设备。所有这三个都有非常不同的属性，并且都被报告为难以安全管理。一名运营商报告说，所有客户场所设备（CPE）都使用相同的密钥。同一个运营商报告说，如果客户授权，可以创建一个唯一的密钥，尽管上次发生这种情况时，它造成了操作上的麻烦，以至于管理员现在通常会告诉客户该选项甚至不存在，以避免出现困难。除非客户要求，否则这些客户唯一密钥永远不会更改。这里的主要威胁是，来自这样一个运营商的被终止的员工如果能够访问这些环境中用于身份验证的一个（或多个）密钥，就可能发动攻击。或者，操作员可以将钥匙提供给发动攻击的其他人。在任何一种情况下，攻击者都可能破坏许多邻近区域，从而破坏路由系统的稳定性。
5. Whatever mechanisms KARP specifies need to be easier to deploy than the current methods and should provide obvious operational efficiency gains along with significantly better security. This combination of value may be enough to drive much broader adoption.
5. KARP指定的任何机制都需要比当前的方法更易于部署，并且应该提供明显的操作效率提高和显著更好的安全性。这种价值组合可能足以推动更广泛的采用。
6. Address the threats enumerated below in "Threats" (Section 3) for each routing protocol. Not all threats may be able to be addressed in the first specification update for any one protocol. Roadmaps will be defined so that both the Security Area and the Routing Area agree on how the threats will be addressed completely over time.
6. 针对每个路由协议，解决下面“威胁”（第3节）中列举的威胁。并非所有威胁都能在任何一个协议的第一次规范更新中解决。将定义路线图，以便安全区域和路由区域就如何随着时间的推移完全解决威胁达成一致。
7. Create a reusable architecture, framework, and guidelines for various IETF working groups that will address these security improvements for various Routing Protocols. The crux of the KARP work is to reuse the architecture, framework, and guidelines as much as possible across relevant Routing Protocols. For example, designers should aim to reuse the key management protocol that will be defined for BGP, which will establish keys for TCP-AO, for as many other routing protocols with similar characteristics and properties as possible.
7. 为各种IETF工作组创建一个可重用的体系结构、框架和指南，以解决各种路由协议的安全改进问题。KARP工作的关键是在相关路由协议中尽可能多地重用架构、框架和指南。例如，设计者应将为BGP定义的密钥管理协议（为TCP-AO建立密钥）用于尽可能多的具有类似特征和属性的其他路由协议。
8. Bridge any gaps between the IETF Routing and Security Areas by recording agreements on work items, roadmaps, and guidance from the cognizant Area Directors and the Internet Architecture Board (IAB).
8. 通过记录有关工作项目的协议、路线图以及认可区域主管和互联网架构委员会（IAB）的指导，弥合IETF路由和安全区域之间的任何差距。
The following goals are considered out of scope for this effort:
以下目标被认为超出了这项工作的范围：
o Confidentiality and non-repudiation of the packets on the wire. Once the goals of this roadmap are realized, work on confidentiality may be considered.
o 数据包在线路上的保密性和不可否认性。一旦实现了本路线图的目标，就可以考虑进行保密工作。
o Non-repudiation of the packets on the wire.
o 在线数据包的不可否认性。
o Message content validity (routing database validity). This work is being addressed in other IETF efforts. For example, BGP message content validity is being addressed in the SIDR working group.
o 消息内容有效性（路由数据库有效性）。这项工作正在其他IETF工作中解决。例如，SIDR工作组正在处理BGP消息内容有效性问题。
The audience for this document includes:
本文件的受众包括：
o Routing Area working group chairs and participants - These people are charged with updating Routing Protocol specifications. Any and all cryptographic authentication work on these specifications will occur in Routing Area working groups, in close partnership with the Security Area. Co-advisors from the Security Area may often be named for these partnership efforts.
o 路由区域工作组主席和参与者——这些人负责更新路由协议规范。关于这些规范的任何和所有加密身份验证工作都将在路由区域工作组中进行，并与安全区域密切合作。来自安全领域的联合顾问通常会因这些合作努力而被任命。
o Security Area reviewers of Routing Area documents - These people are tasked by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. Their particular attention to the use of cryptographic authentication and newly specified security mechanisms for the routing protocols is appreciated. They also help to ensure that incremental security improvements are being made, in line with this roadmap.
o 路由区域文档的安全区域审阅者-这些人在通过工作组最后一次呼叫或IESG审阅时，由安全区域主管负责对路由协议规范进行审阅。他们对使用密码认证和新指定的路由协议安全机制的特别关注值得赞赏。它们还有助于确保按照此路线图进行增量安全改进。
o Security Area engineers - These people partner with Routing Area authors/designers on the security mechanisms in routing protocol specifications. Some of these Security Area engineers will be assigned by the Security Area Directors, while others will be interested parties in the relevant working groups.
o 安全区域工程师-这些人与路由区域的作者/设计师合作，研究路由协议规范中的安全机制。其中一些安全区域工程师将由安全区域主管指派，而其他工程师将是相关工作组的相关方。
o Operators - The operators are a key audience for this work, as the work is considered to have succeeded only if operators deploy the technology. It is anticipated that deployment will take place only if operators perceive that the improved security offered by the Routing Protocol updates warrants the complexity and cost of deployment and operation. Conversely, the work will be considered a failure if operators do not deploy it, either due to a lack of
o 操作员-操作员是这项工作的关键受众，因为只有操作员部署了技术，这项工作才被认为是成功的。预计只有在运营商认为路由协议更新所提供的安全性改进保证了部署和操作的复杂性和成本时，才会进行部署。相反，如果操作员由于缺乏安全性而未部署该工作，则该工作将被视为失败
perceived value or due to perceived operational complexity. As a result, the GROW and OPSEC working groups should be kept squarely in the loop as well.
感知价值或由于感知到的运营复杂性。因此，GROW和OPSEC工作组也应该直接处于循环中。
This document uses the definition of "threat" from RFC 4949 [RFC4949]: "[a] potential for violation of security, which exists when there is an entity, circumstance, capability, action, or event that could cause harm."
本文件使用了RFC 4949[RFC4949]中“威胁”的定义：“[a]当存在可能造成伤害的实体、环境、能力、行动或事件时，存在违反安全的可能性。”
This section defines the threats that are in scope for the KARP effort. It also lists those threats that are explicitly out of scope for the KARP effort. Threats are discussed assuming that no protection (i.e., message authentication and message integrity) has been applied to routing protocol messages.
本节定义了KARP工作范围内的威胁。它还列出了那些明显超出KARP工作范围的威胁。假设未对路由协议消息应用任何保护（即消息身份验证和消息完整性），则讨论威胁。
This document leverages the model described in "Generic Threats to Routing Protocols" [RFC4593]. Specifically, the threats listed below were derived by reviewing [RFC4593], analyzing how the threats applied to the KARP problem space, and listing the threats that are applicable to the work for the KARP design team. This document categorizes [RFC4593] threats into those in scope and those out of scope for KARP. Each in-scope threat is discussed below, and its applicability to the KARP problem space is described. As such, the following text intentionally is not a comprehensive threat analysis. Rather, it describes the applicability of the existing threat analysis in [RFC4593] to KARP.
本文档利用了“路由协议的一般威胁”[RFC4593]中描述的模型。具体而言，以下列出的威胁是通过审查[RFC4593]，分析威胁如何应用于KARP问题空间，并列出适用于KARP设计团队工作的威胁而得出的。本文件将[RFC4593]威胁分为KARP范围内和范围外的威胁。下文将讨论每个范围内威胁，并描述其对KARP问题空间的适用性。因此，以下文本并非全面的威胁分析。相反，它描述了[RFC4593]中现有威胁分析对KARP的适用性。
Note: terms from [RFC4593] appear capitalized below -- e.g. OUTSIDERS -- so as to make explicit the term's origin, and to enable rapid cross referencing to the source RFC.
注：[RFC4593]中的术语在下面大写，例如外来者，以便明确术语的来源，并能够快速交叉引用源RFC。
For convenience, a terse definition of most [RFC4593] terms is offered here. Those interested in a more thorough description of routing protocol threat sources, motivations, consequences, and actions will want to read [RFC4593] before continuing here.
为方便起见，这里提供了大多数[RFC4593]术语的简洁定义。那些对路由协议威胁源、动机、后果和行为的更全面描述感兴趣的人，在继续本文之前，需要阅读[RFC4593]。
One of the threats that will be addressed in this roadmap is the situation in which the source is an OUTSIDER. An OUTSIDER attacker may reside anywhere in the Internet, may have the ability to send IP traffic to the router, may be able to observe the router's replies, and may even control the path for a legitimate peer's traffic. OUTSIDERS are not legitimate participants in the routing protocol.
本路线图将要解决的一个威胁是，信息来源是一个局外人。外部攻击者可能驻留在Internet的任何位置，可能能够向路由器发送IP流量，可能能够观察路由器的回复，甚至可能控制合法对等方流量的路径。局外人不是路由协议的合法参与者。
The use of message authentication and integrity protection specifically aims to identify packets originating from OUTSIDERS.
消息身份验证和完整性保护的使用特别旨在识别来自外部的数据包。
KARP design teams will consider two specific use cases of OUTSIDERS: those on path, and those off path.
卡普设计团队将考虑两个特定的外用案例：路径上的那些，以及那些偏离路径的。
o On Path - These attackers have control of a network resource or a tap that sits along the path between two routing peers. A "Man in the Middle" (MitM) is an on-path attacker. From this vantage point, the attacker can conduct either active or passive attacks. An active attack occurs when the attacker places packets on the network as part of the attack. One active MitM attack relevant to KARP, an active wiretapping attack, occurs when the attacker tampers with packets moving between two legitimate router peers in such a way that both peers think they are talking to each other directly, when in fact they are actually talking to the attacker. Protocols conforming to this roadmap will use cryptographic mechanisms to detect MitM attacks and reject packets from such attacks (i.e., discard them as being not authentic). Passive on-path attacks occur when the attacker silently gathers data and analyzes it to gain advantage. Passive activity by an on-path attacker may lead to an active attack.
o 在路径上-这些攻击者可以控制网络资源或位于两个路由对等点之间的路径上的抽头。“中间人”（MitM）是路径攻击者。从这个有利位置出发，攻击者可以进行主动或被动攻击。当攻击者在网络上放置数据包作为攻击的一部分时，就会发生主动攻击。一种与KARP相关的主动MitM攻击，即主动窃听攻击，发生在攻击者篡改在两个合法路由器对等点之间移动的数据包，使两个对等点都认为他们在直接交谈，而实际上他们正在与攻击者交谈时。符合此路线图的协议将使用加密机制检测MitM攻击，并拒绝来自此类攻击的数据包（即，丢弃不真实的数据包）。当攻击者静默地收集数据并进行分析以获取优势时，就会发生被动路径攻击。路径上攻击者的被动活动可能导致主动攻击。
o Off Path - These attackers sit on some network outside of that over which the packets between two routing peers run. The source may be one or several hops away. Off-path attackers can launch active attacks, such as SPOOFING or denial-of-service (DoS) attacks, to name a few.
o 非路径-这些攻击者位于两个路由对等点之间运行数据包的网络之外的某个网络上。源可以是一个或多个跃点。非路径攻击者可以发起主动攻击，例如欺骗或拒绝服务（DoS）攻击。
This threat source exists when an unauthorized entity somehow manages to gain access to keying material. Using this material, the attacker could send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The resulting traffic might appear to come from router A and be destined for router B, and thus the attacker could impersonate an authorized peer. The attacker could then adversely affect network behavior by sending bogus messages that appear to be authentic. The attack source possessing the unauthorized keys could be on path, off path, or both.
当未经授权的实体以某种方式设法获得密钥材料的访问权限时，存在此威胁源。使用此材料，攻击者可以发送通过基于消息身份验证码（MAC）的真实性检查的数据包。由此产生的流量似乎来自路由器A，目的地为路由器B，因此攻击者可以模拟授权对等方。然后，攻击者可以发送看似真实的虚假消息，从而对网络行为产生不利影响。拥有未经授权密钥的攻击源可能在路径上，也可能在路径外，或者两者兼而有之。
The obvious mitigation for an unauthorized key holder is to change the keys currently in use by the legitimate routing peers. This mitigation can be either reactive or proactive. Reactive mitigation occurs when keys are changed only after one has discovered that the previous keys have fallen into the possession of unauthorized users. The reactive mitigation case is highlighted here in order to explain a common operational situation where new keying material will need to
对于未经授权的密钥持有者，明显的缓解措施是更改合法路由对等方当前使用的密钥。这种缓解措施可以是被动的，也可以是主动的。只有在发现以前的密钥落入未经授权的用户手中后才更改密钥时，才会发生被动缓解。此处强调了反应缓解案例，以解释需要使用新键控材料的常见操作情况
be put in place with little or no advanced warning. In such a case, new keys must be able to be installed and put into use very quickly, and with little operational expense. Proactive mitigation occurs when an operator assumes that unauthorized possession will occur from time to time without being discovered, and the operator moves to new keying material in order to cut short an attacker's window of opportunity to use the stolen keys effectively.
在很少或没有提前警告的情况下安装到位。在这种情况下，新钥匙必须能够快速安装并投入使用，并且操作费用很低。当操作员认为未经授权的占有会不时发生而不会被发现，并且操作员移动到新的钥匙材料以缩短攻击者有效使用被盗钥匙的机会时，就会发生主动缓解。
KARP design teams can address this type of attack by creating specifications that make it practical for the operator to quickly change keys without disruption to the routing system and with minimal operational overhead. Operators can further mitigate threats from unauthorized key holders by regularly changing keys.
KARP设计团队可以通过创建规范来解决此类攻击，使运营商能够在不中断路由系统的情况下，以最小的运营开销快速更改密钥。运营商可以通过定期更换钥匙，进一步缓解未经授权的钥匙持有者的威胁。
A terminated employee is an important example of an unauthorized key holder. Staff attrition is a reality in routing operations and is therefore a potential threat source. The threat source risk arises when a network operator who had been granted access to keys ceases to be an employee. If new keys are deployed immediately, the situation of a terminated employee can become an "unauthorized key holder, proactive" case, as described above, rather than an "unauthorized key holder, reactive mitigation" case. It behooves the operator to change the keys, to enforce the revocation of authorization of the old keys, in order to minimize the threat source's window of opportunity.
被解雇的员工是未经授权的密钥持有者的一个重要例子。员工流失是路由操作中的一个现实，因此是一个潜在的威胁源。当被授权访问密钥的网络运营商不再是员工时，就会产生威胁源风险。如果立即部署新钥匙，则被解雇员工的情况可能会变成如上所述的“未经授权的钥匙持有人，主动”情况，而不是“未经授权的钥匙持有人，被动缓解”情况。操作员应该更改密钥，强制撤销旧密钥的授权，以最小化威胁源的机会窗口。
A terminated employee is a valid unauthorized key holder threat source for KARP, and designs should address the associated threats. For example, new keys must be able to be installed and made operational in the routing protocols very quickly, with zero impact to the routing system, and with little operational expense. The threat actions associated with a terminated employee also motivate the need to change the keys quickly, also with little operational expense.
被解雇的员工是KARP的有效未经授权的密钥持有者威胁源，设计应解决相关威胁。例如，新密钥必须能够在路由协议中快速安装并运行，对路由系统没有影响，并且运行费用很低。与被解雇员工相关的威胁行为也促使员工需要快速更换钥匙，而且操作费用也很低。
According to [RFC4593], Section 3.1.1.2, BYZANTINE "attackers are faulty, misconfigured, or subverted routers; i.e., legitimate participants in the routing protocol", whose messages cause routing to malfunction.
根据[RFC4593]第3.1.1.2节，拜占庭“攻击者是有故障、配置错误或被破坏的路由器；即路由协议的合法参与者”，其消息会导致路由故障。
[RFC4593] goes on to say that "[s]ome adversaries can subvert routers, or the management workstations used to control these routers. These Byzantine failures represent the most serious form of
[RFC4593]接着说，“一些对手可以破坏路由器，或者用来控制这些路由器的管理工作站。这些拜占庭式的故障代表了最严重的安全威胁。”
attack capability in that they result in emission of bogus traffic by legitimate routers."
攻击能力，因为它们导致合法路由器发出虚假流量。”
[RFC4593] explains that "[d]eliberate attacks are mimicked by failures that are random and unintentional. In particular, a Byzantine failure in a router may occur because the router is faulty in hardware or software or is misconfigured", and thus routing malfunctions unintentionally. Although not malicious, such occurrences still disrupt network operation.
[RFC4593]解释说，“eliberate攻击是通过随机和非故意的故障来模拟的。特别是，路由器中可能发生拜占庭式故障，因为路由器在硬件或软件上有故障，或者配置错误”，因此路由故障是非故意的。尽管并非恶意，但此类事件仍会中断网络运行。
Whether faulty, misconfigured, or subverted, Byzantine routers have an empowered position from which to provide believable yet bogus routing messages that are damaging to the network.
无论是错误的、配置错误的还是被破坏的，拜占庭路由器都有一个强大的位置，可以提供可信但虚假的路由消息，从而破坏网络。
The following THREAT ACTIONS are in scope for KARP:
以下威胁行动在KARP的范围内：
o SPOOFING - when an unauthorized device assumes the identity of an authorized one. Spoofing is special in that it can be used to carry out other threat actions that cause other threat consequences. SPOOFING can be used, for example, to inject malicious routing information that causes the disruption of network services. SPOOFING can also be used to cause a neighbor relationship to form that subsequently denies the formation of the relationship with a legitimate router.
o 欺骗-当未经授权的设备具有授权设备的身份时。欺骗的特殊之处在于，它可用于执行导致其他威胁后果的其他威胁操作。例如，可以使用欺骗来注入导致网络服务中断的恶意路由信息。欺骗还可用于导致邻居关系形成，从而拒绝与合法路由器形成关系。
o DoS attacks
o 拒绝服务攻击
A. At the transport layer - This occurs when an attacker sends packets aimed at halting or preventing the underlying protocol over which the routing protocol runs. The attacker could use SPOOFING, FALSIFICATION, or INTERFERENCE (see below) to produce the DoS attack. For example, BGP running over Transport Layer Security (TLS) will still not solve the problem of an attacker being able to send a spoofed TCP FIN or TCP RST and causing the BGP session to go down. Since these attacks depend on spoofing, operators are encouraged to deploy proper authentication mechanisms to prevent them. Specification work should ensure that Routing Protocols can operate over transport subsystems in a fashion that is resilient to such DoS attacks.
A.在传输层-当攻击者发送旨在停止或阻止路由协议运行的基础协议的数据包时，就会发生这种情况。攻击者可以使用欺骗、伪造或干扰（见下文）来产生DoS攻击。例如，通过传输层安全性（TLS）运行的BGP仍然无法解决攻击者能够发送伪造的TCP FIN或TCP RST并导致BGP会话中断的问题。由于这些攻击依赖于欺骗，因此鼓励运营商部署适当的身份验证机制来防止它们。规范工作应确保路由协议能够在传输子系统上以一种能够抵御此类DoS攻击的方式运行。
B. Using the authentication mechanism - This includes an attacker causing INTERFERENCE, which inhibits exchanges of legitimate routers. The attack is often perpetrated by sending packets that confuse or overwhelm a security mechanism itself. An example is initiating an overwhelming load of spoofed routing
B.使用身份验证机制-这包括攻击者造成干扰，从而阻止合法路由器的交换。攻击通常通过发送混淆或压倒安全机制本身的数据包来实施。例如，启动大量伪造路由
protocol packets that contain a MAC (i.e., INSERTING MESSAGES), so that the receiver spends substantial CPU resources on the processing cycles to check the MAC, only to discard the spoofed packet. Other types of INTERFERENCE include REPLAYING OUT-DATED PACKETS, CORRUPTING MESSAGES, and BREAKING SYNCHRONIZATION.
包含MAC（即插入消息）的协议数据包，以便接收器在处理周期上花费大量CPU资源来检查MAC，而只是丢弃伪造的数据包。其他类型的干扰包括重放过时的数据包、破坏消息和中断同步。
o FALSIFICATION - An action whereby an attacker sends false routing information. This document targets only FALSIFICATION from OUTSIDERS that may occur from tampering with packets in flight or sending entirely false messages. FALSIFICATION from BYZANTINES (see Section 3.3) are not addressed by the KARP effort.
o 伪造-攻击者发送虚假路由信息的行为。本文档仅针对来自外部的伪造，这些伪造可能是由于在飞行中篡改数据包或发送完全错误的消息造成的。来自拜占庭的伪造（见第3.3节）未通过KARP的努力解决。
o Brute-Force Attacks Against Password/Keys - This includes either online or offline attacks in which attempts are made repeatedly using different keys/passwords until a match is found. While it is impossible to make brute-force attacks on keys completely unsuccessful, proper design can make it much harder for such attacks to succeed. For example, current guidance for the security strength of an algorithm with a particular key length should be deemed acceptable for a period of 10 years. (Section 10 of [SP.800-131A] is one source for guidance.) Using per-session keys is another widely used method for reducing the number of brute-force attacks, as this would make it difficult to guess the keys.
o 针对密码/密钥的暴力攻击-这包括在线或离线攻击，其中重复使用不同的密钥/密码进行尝试，直到找到匹配项。虽然不可能使对密钥的暴力攻击完全失败，但适当的设计会使此类攻击更难成功。例如，对于具有特定密钥长度的算法的安全强度的当前指导应被视为在10年内可接受。（参考[SP.800-131A]第10节）使用每会话密钥是减少暴力攻击次数的另一种广泛使用的方法，因为这会使猜测密钥变得困难。
BYZANTINE sources -- be they faulty, misconfigured, or subverted -- are out of scope for this roadmap. KARP works to cryptographically ensure that received routing messages originated from authorized peers and that the message was not altered in transit. Formation of a bogus message by a valid and authorized peer falls outside the KARP scope. Any of the attacks described in Section 3.2 that may be levied by a BYZANTINE source are therefore also out of scope, e.g. FALSIFICATION from BYZANTINE sources or unauthorized message content by a legitimate authorized peer.
拜占庭式的资源——无论是错误的、配置错误的还是被颠覆的——都超出了本路线图的范围。KARP的工作原理是以加密方式确保收到的路由消息来自授权的对等方，并且消息在传输过程中未被更改。由有效且经授权的对等方生成虚假消息不属于KARP范围。因此，拜占庭来源可能发起的第3.2节中所述的任何攻击也超出范围，例如，来自拜占庭来源的伪造或合法授权对等方未经授权的消息内容。
In addition, these other attack actions are out of scope for this work:
此外，这些其他攻击行为不在本工作范围内：
o SNIFFING (passive wiretapping) - Passive observation of route message contents in flight. Data confidentiality, as achieved by data encryption, is the common mechanism for preventing SNIFFING. While useful, especially to prevent the gathering of data needed to perform an off-path packet injection attack, data encryption is out of scope for KARP.
o 嗅探（被动窃听）-在飞行中被动观察路线信息内容。通过数据加密实现的数据机密性是防止嗅探的常见机制。虽然数据加密非常有用，特别是在防止收集执行非路径数据包注入攻击所需的数据时，但数据加密不适用于KARP。
o INTERFERENCE due to:
o 由于以下原因造成的干扰：
A. NOT FORWARDING PACKETS - Cannot be prevented with cryptographic authentication. Note: If sequence numbers with sliding windows are used in the solution (as is done, for example, in Bidirectional Forwarding Detection (BFD) [RFC5880]), a receiver can at least detect the occurrence of this attack.
A.不转发数据包-无法通过加密身份验证阻止。注意：如果在解决方案中使用带滑动窗口的序列号（例如，在双向转发检测（BFD）[RFC5880]中），则接收器至少可以检测到该攻击的发生。
B. DELAYING MESSAGES - Cannot be prevented with cryptographic authentication. Note: Timestamps can be used to detect delays.
B.延迟消息-无法通过加密身份验证阻止。注意：时间戳可用于检测延迟。
C. DENIAL OF RECEIPT (non-repudiation) - Cannot be prevented with cryptographic authentication.
C.拒绝接收（不可抵赖）-无法通过加密身份验证来防止。
D. UNAUTHORIZED MESSAGE CONTENT - Covered by the work of the IETF's SIDR working group (http://www.ietf.org/html.charters/sidr-charter.html).
D.未经授权的消息内容——由IETF的SIDR工作组的工作涵盖(http://www.ietf.org/html.charters/sidr-charter.html).
E. DoS attacks not involving the routing protocol. For example, a flood of traffic that fills the link ahead of the router, so that the router is rendered unusable and unreachable by valid packets is NOT an attack that KARP will address. Many such examples could be contrived.
E.不涉及路由协议的DoS攻击。例如，大量流量填满路由器前面的链路，从而使路由器变得不可用且有效数据包无法访问，这不是KARP将要解决的攻击。许多这样的例子都是虚构的。
4. Requirements for KARP Work Phase 1: Update to a Routing Protocol's Existing Transport Security
4. KARP工作阶段1的要求：更新路由协议的现有传输安全
Section 4.1 of the KARP Design Guide [RFC6518] describes two distinct work phases for the KARP effort. This section addresses requirements for the first work phase only, Work Phase 1, the update to a routing protocol's existing transport security. Work Phase 2, the framework and usage of a KMP, will be addressed in a future document(s).
《KARP设计指南》[RFC6518]第4.1节描述了KARP工作的两个不同工作阶段。本节仅讨论第一个工作阶段（工作阶段1）的要求，即对路由协议现有传输安全性的更新。工作阶段2，KMP的框架和使用，将在未来的文件中讨论。
The following list of requirements SHOULD be addressed by a KARP Work Phase 1 security update to any Routing Protocol (according to section 4.1 of the KARP Design Guide [RFC6518]document). IT IS RECOMMENDED that any Work Phase 1 security update to a Routing Protocol contain a section of the specification document that describes how each of the following requirements are met. It is further RECOMMENDED that justification be presented for any requirements that are NOT addressed.
应通过对任何路由协议进行KARP工作阶段1安全更新（根据KARP设计指南[RFC6518]文件第4.1节），解决以下要求列表。建议路由协议的任何工作阶段1安全更新都包含规范文档的一部分，该部分描述了如何满足以下每个要求。还建议对未解决的任何要求提出理由。
1. Clear definitions of which elements of the transmitted data (frame, packet, segment, etc.) are protected by an authentication/integrity mechanism.
1. 传输数据的哪些元素（帧、分组、段等）受身份验证/完整性机制保护的明确定义。
2. Strong cryptographic algorithms, as defined and accepted by the IETF security community, MUST be specified. The use of non-standard or unpublished algorithms MUST be avoided.
2. 必须指定IETF安全社区定义和接受的强加密算法。必须避免使用非标准或未发布的算法。
3. Algorithm agility for the cryptographic algorithms used in the authentication MUST be specified, and protocol specifications MUST be clear regarding how new algorithms are specified and used within the protocol. This requirement exists because research identifying weaknesses in cryptographic algorithms can cause the security community to reduce confidence in some algorithms. Breaking a cipher isn't a matter of if, but when it will occur. Having the ability to specify alternate algorithms (algorithm agility) within the protocol specification to support such an event is essential. Additionally, more than one algorithm MUST be specified. Mandating support for two algorithms (i.e., one mandatory to implement algorithm and one or more backup algorithms to guide transition) provides both redundancy, and a mechanism for enacting that redundancy.
3. 必须指定认证中使用的加密算法的算法灵活性，协议规范必须明确说明如何在协议中指定和使用新算法。这一要求之所以存在，是因为识别密码算法弱点的研究可能会导致安全社区降低对某些算法的信心。破译密码不在于是否破译，而在于破译的时间。必须能够在协议规范中指定备用算法（算法敏捷性），以支持此类事件。此外，必须指定多个算法。强制支持两个算法（即，一个强制实现算法，一个或多个备份算法指导转换）既提供了冗余，也提供了一种执行冗余的机制。
4. Secure use of PSKs, offering both operational convenience and a baseline level of security, MUST be specified.
4. 必须规定PSK的安全使用，提供操作便利性和基准安全水平。
5. Routing Protocols (or the transport or network mechanism protecting routing protocols) SHOULD be able to detect and reject replayed intra-session and inter-session messages. Packets captured from one session MUST NOT be able to be resent and accepted during a later session (i.e., inter-session replay). Additionally, replay mechanisms MUST work correctly even in the presence of routing protocol packet prioritization by the router.
5. 路由协议（或保护路由协议的传输或网络机制）应该能够检测和拒绝重播的会话内和会话间消息。从一个会话捕获的数据包不能在以后的会话（即会话间重播）期间重新发送和接受。此外，即使路由器存在路由协议包优先级，重播机制也必须正常工作。
There is a specific case of replay attack combined with spoofing that must be addressed. Several routing protocols (e.g., OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453], etc.), require all speakers to share the same authentication and message association key on a broadcast segment. It is important that an integrity check associated with a message fail if an attacker has replayed the message with a different origin.
必须解决重放攻击与欺骗相结合的具体情况。一些路由协议（例如，OSPF[RFC2328]、IS-IS[RFC1195]、BFD[RFC5880]、RIP[RFC2453]等）要求所有扬声器在广播段上共享相同的身份验证和消息关联密钥。如果攻击者使用不同的来源重放了消息，则与消息相关联的完整性检查必须失败，这一点很重要。
6. A change of security parameters MUST force a change of session traffic keys. The specific security parameters for the various routing protocols will differ and will be defined by each protocol design team. Some examples may include master key, key lifetime, and cryptographic algorithm. If one of these configured parameters changes, then a new session traffic key MUST immediately be established using the updated parameters. The routing protocol security mechanisms MUST support this behavior.
6. 更改安全参数必须强制更改会话通信密钥。各种路由协议的具体安全参数将有所不同，并由每个协议设计团队定义。一些示例可能包括主密钥、密钥生存期和加密算法。如果其中一个配置参数发生更改，则必须立即使用更新的参数建立新的会话通信密钥。路由协议安全机制必须支持此行为。
7. Security mechanisms MUST specify a means to affect intra-session rekeying without disrupting a routing session. This should be accomplished without data loss, if possible. Keys may need to be changed periodically based on policy or when an administrator who had access to the keys leaves an organization. A rekeying mechanism enables the operators to execute the change without productivity loss.
7. 安全机制必须指定在不中断路由会话的情况下影响会话内密钥更新的方法。如果可能的话，这应该在不丢失数据的情况下完成。可能需要根据策略定期更改密钥，或者在有权访问密钥的管理员离开组织时更改密钥。重新键入机制使操作员能够在不损失生产力的情况下执行更改。
8. Rekeying SHOULD be supported in such a way that it can occur during a session without the peer needing to use multiple keys to validate a given packet. The rare exception will occur if a routing protocol's design team can find no other way to rekey and still adhere to the other requirements in this section. The specification SHOULD include a key identifier, which allows receivers to choose the correct key (or determine that they are not in possession of the correct key).
8. 应以这样一种方式支持密钥更新，即在会话期间可以发生密钥更新，而对等方无需使用多个密钥来验证给定的数据包。如果路由协议的设计团队无法找到其他方法重新设置密钥，并且仍然遵守本节中的其他要求，则会出现罕见的例外情况。规范应包括一个密钥标识符，该标识符允许接收者选择正确的密钥（或确定他们不拥有正确的密钥）。
9. New mechanisms MUST resist DoS attacks described as in scope in Section 3.2. Routers protect the control plane by implementing mechanisms to reject completely or rate-limit traffic not required at the control-plane level (i.e., unwanted traffic). Typically, line-rate packet-filtering capabilities look at information in the IP and transport (TCP or UDP) headers, but do not include higher-layer information. Therefore, the new mechanisms should neither hide nor encrypt the information carried in the IP and transport layers in control-plane packets.
9. 新机制必须抵抗第3.2节中所述的DoS攻击。路由器通过实现完全拒绝或速率限制控制平面级别不需要的流量（即不需要的流量）的机制来保护控制平面。通常，线路速率数据包过滤功能查看IP和传输（TCP或UDP）头中的信息，但不包括更高层的信息。因此，新机制既不应隐藏也不应加密控制平面数据包中IP和传输层中携带的信息。
10. Mandatory cryptographic algorithms and mechanisms MUST be specified for each routing protocol security mechanism. Further, the protocol specification MUST define default security mechanism settings for all implementations to use when no explicit configuration is provided. To understand the need for this requirement, consider the case where a routing protocol mandates three different cryptographic algorithms for a MAC operation. If company A implements algorithm 1 as the default for this protocol, while company B implements algorithm 2 as the default, then two operators who enable the security mechanism with no explicit configuration other than a PSK will experience a connection failure. It is not enough that each implementation implement the three mandatory algorithms; one default must further be specified in order to gain maximum out-of-the-box interoperability.
10. 必须为每个路由协议安全机制指定强制加密算法和机制。此外，协议规范必须为所有实现定义默认安全机制设置，以便在未提供显式配置时使用。为了理解对该要求的需要，考虑路由协议规定MAC操作的三种不同密码算法的情况。如果公司A实现算法1作为该协议的默认值，而公司B实现算法2作为默认值，则启用除PSK之外没有显式配置的安全机制的两个操作员将遇到连接故障。每个实现实现实现三个强制算法是不够的；为了获得最大的开箱即用互操作性，必须进一步指定一个默认值。
11. For backward-compatibility reasons, manual keying MUST be supported.
11. 出于向后兼容的原因，必须支持手动键控。
12. The specification MUST consider and allow for future use of a KMP.
12. 该规范必须考虑并允许将来使用KMP。
13. The authentication mechanism in a Routing Protocol MUST be decoupled from the key management system used. The authentication protocol MUST include a specification for agreeing on keying material. This will accommodate both manual keying and the use of KMPs.
13. 路由协议中的身份验证机制必须与所使用的密钥管理系统解耦。认证协议必须包括一个关于密钥材料的约定规范。这将适应手动键控和KMP的使用。
14. Convergence times of the Routing Protocols SHOULD NOT be materially affected. Changes in the convergence time will be immediately and independently verifiable by convergence performance test beds already in use (e.g. those maintained by router vendors, service providers, and researchers). An increase in convergence time in excess of 5% is likely to be considered to have materially affected convergence by network operators. A number of other factors can also change convergence over time (e.g., speed of processors used on individual routing peers, processing power increases due to Moore's law, and implementation specifics), and implementors will need to take into account the effect of an authentication mechanism on Routing Protocols. Protocol designers should consider the impact on convergence times as a function of both the total number of protocol packets that must be exchanged and the required computational processing of individual messages in the specification, understanding that the operator community's threshold for an increase in convergence times is very low, as stated above.
14. 路由协议的收敛时间不应受到重大影响。收敛时间的变化将由已经使用的收敛性能测试台（例如，由路由器供应商、服务提供商和研究人员维护的测试台）立即独立验证。收敛时间增加超过5%可能会被视为对网络运营商的收敛产生重大影响。随着时间的推移，许多其他因素也会改变收敛性（例如，单个路由对等点上使用的处理器速度、摩尔定律导致的处理能力增加以及实现细节），实现者需要考虑身份验证机制对路由协议的影响。协议设计者应该考虑到收敛时间的影响，作为必须交换的协议分组的总数和规范中单个消息所需的计算处理的功能，理解操作员社区对于收敛时间的增加的阈值非常低，如上所述。
15. The changes to or addition of security mechanisms SHOULD NOT cause a refresh of route advertisements or cause additional route advertisements to be generated.
15. 对安全机制的更改或添加不应导致刷新路由播发或生成其他路由播发。
16. Router implementations provide prioritized treatment for certain protocol packets. For example, OSPF Hello and Acknowledgement packets are prioritized for processing above other OSPF packets. The security mechanism SHOULD NOT interfere with the ability to observe and enforce such prioritization. Any effect on such priority mechanisms MUST be explicitly documented and justified. Replay protection mechanisms provided by the routing protocols MUST work even if certain protocol packets are offered prioritized treatment.
16. 路由器实现为某些协议包提供优先处理。例如，OSPF Hello和确认数据包优先于其他OSPF数据包进行处理。安全机制不应干扰观察和执行此类优先顺序的能力。对这类优先权机制的任何影响都必须明确记录和证明。路由协议提供的重播保护机制必须工作，即使某些协议包被提供了优先处理。
17. The Routing Protocol MUST send minimal information regarding the authentication mechanisms and associated parameters in its protocol packets. This keeps the Routing Protocols as clean and focused as possible, and loads security negotiations into the KMP as much as possible. This also avoids exposing any security negotiation information unnecessarily to possible attackers on the path.
17. 路由协议必须发送有关其协议数据包中的身份验证机制和相关参数的最小信息。这使得路由协议尽可能干净和集中，并尽可能将安全协商加载到KMP中。这还避免了向路径上可能的攻击者不必要地公开任何安全协商信息。
18. Routing Protocols that rely on the IP header (or information separate from routing protocol payload) to identify the neighbor that originated the packet MUST either protect the IP header or provide some other means to authenticate the neighbor. [RFC6039] describes some attacks that motivate this requirement.
18. 依赖IP报头（或独立于路由协议有效负载的信息）来识别发起数据包的邻居的路由协议必须保护IP报头或提供一些其他方法来验证邻居。[RFC6039]描述了激发此需求的一些攻击。
19. Every new KARP-developed security mechanisms MUST support incremental deployment. It will not be feasible to deploy a new Routing Protocol authentication mechanism throughout a network instantaneously. Indeed, it may not actually be feasible to deploy such a mechanism to all routers in a large autonomous system (AS) in a bounded timeframe. Proposed solutions MUST support an incremental deployment method that benefits those who participate. Because of this, there are several requirements that any proposed KARP mechanism should consider.
19. 每一个新的KARP开发的安全机制都必须支持增量部署。在整个网络中即时部署新的路由协议身份验证机制是不可行的。事实上，在有限的时间内将这种机制部署到大型自治系统（AS）中的所有路由器实际上可能并不可行。建议的解决方案必须支持增量部署方法，使参与方受益。正因为如此，有任何要求，任何建议的卡普机制应考虑。
A. The Routing Protocol security mechanism MUST enable each router to configure use of the security mechanism on a per-peer basis where the communication is peer to peer (unicast).
A.路由协议安全机制必须使每个路由器能够在通信为对等（单播）的情况下，在每个对等的基础上配置安全机制的使用。
B. Every new KARP-developed security mechanism MUST provide backward compatibility with respect to message formatting, transmission, and processing of routing information carried through secure and non-secure security environments. Message formatting in a fully secured environment MAY be handled in a non-backward-compatible fashion, though care must be taken to ensure that routing protocol packets can traverse intermediate routers that don't support the new format.
B.每一个新的KARP开发的安全机制都必须在消息格式、传输和处理通过安全和非安全安全环境传输的路由信息方面提供向后兼容性。在完全安全的环境中，消息格式可能以不向后兼容的方式进行处理，但必须注意确保路由协议数据包可以穿过不支持新格式的中间路由器。
C. In an environment where both secured and non-secured routers are interoperating, a mechanism MUST exist for secured systems to identify whether a peer intended the messages to be secured.
C.在安全路由器和非安全路由器都在互操作的环境中，安全系统必须有一种机制来识别对等方是否打算保护消息。
D. In an environment where secured service is in the process of being deployed, a mechanism MUST exist to support a transition free of service interruption (caused by the deployment per se).
D.在安全服务正在部署的环境中，必须存在一种机制来支持无服务中断（由部署本身引起）的转换。
20. The introduction of mechanisms to improve routing security may increase the processing performed by a router. Since most of the currently deployed routers do not have hardware to accelerate cryptographic operations, these operations could impose a significant processing burden under some circumstances. Thus, proposed solutions SHOULD be evaluated carefully with regard to the processing burden they may impose, since
20. 引入提高路由安全性的机制可以增加路由器执行的处理。由于目前部署的大多数路由器没有硬件来加速加密操作，因此在某些情况下，这些操作可能会带来巨大的处理负担。因此，应仔细评估提议的解决方案可能带来的处理负担，因为
deployment may be impeded if network operators perceive that a solution will impose a processing burden that either incurs substantial capital expense or threatens to degrade router performance.
如果网络运营商认为某个解决方案会造成处理负担，导致大量资本支出或可能降低路由器性能，则部署可能会受到阻碍。
21. New authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding) in order for the routing system to be secure. In order to ensure the rapid initialization and/or return to service of failed nodes, it is important to reduce reliance on these external systems to the greatest extent possible. Proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is, however, acceptable for the proposed solutions to require post-initialization synchronization with external systems in order to fully synchronize security associations.
21. 新的身份验证和安全机制不应依赖路由系统外部的系统（执行转发的设备）来确保路由系统的安全。为了确保故障节点的快速初始化和/或恢复服务，必须尽可能减少对这些外部系统的依赖。除了直接参与对等关系的系统外，建议的解决方案不应要求连接到外部系统，以恢复完整服务。但是，建议的解决方案要求初始化后与外部系统同步，以便完全同步安全关联，这是可以接受的。
If authentication and security mechanisms rely on systems external to the routing system, then there MUST be one or more options available to avoid circular dependencies. It is not acceptable to have a routing protocol (e.g., unicast routing) depend upon correct operation of a security protocol that, in turn, depends upon correct operation of the same instance of that routing protocol (i.e., the unicast routing). However, it is acceptable to have operation of a routing protocol (e.g., multicast routing) depend upon operation of a security protocol, which depends upon an independent routing protocol (e.g., unicast routing). Similarly, it would be okay to have the operation of a routing protocol depend upon a security protocol, which in turn uses an out-of-band network to exchange information with remote systems.
如果身份验证和安全机制依赖于路由系统外部的系统，则必须有一个或多个选项可用于避免循环依赖。路由协议（例如，单播路由）依赖于安全协议的正确操作是不可接受的，而安全协议又依赖于该路由协议的相同实例（即，单播路由）的正确操作。然而，路由协议（例如，多播路由）的操作取决于安全协议的操作是可以接受的，安全协议的操作取决于独立的路由协议（例如，单播路由）。类似地，让路由协议的操作依赖于安全协议也可以，安全协议反过来使用带外网络与远程系统交换信息。
This document is mostly about security considerations for the KARP efforts, both threats and the requirements for addressing those threats. More detailed security considerations are provided in the Security Considerations section of the KARP Design Guide [RFC6518]document.
本文件主要是关于KARP工作的安全考虑，包括威胁和应对这些威胁的要求。KARP设计指南[RFC6518]文件的安全注意事项部分提供了更详细的安全注意事项。
The use of a group key between a set of Routing Protocol peers has special security considerations. Possession of the group key itself is used for identity validation; no other identity check is used. Under these conditions, an attack exists when one peer masquerades as a neighbor by using the neighbor's source IP address. This type of attack has been well documented in the group-keying problem space, and it is non-trivial to solve. Solutions exist within the group-
在一组路由协议对等方之间使用组密钥具有特殊的安全考虑。拥有组密钥本身用于身份验证；不使用其他身份检查。在这些情况下，当一个对等方使用邻居的源IP地址伪装成邻居时，就会发生攻击。这种类型的攻击已经在组密钥问题空间中得到了很好的记录，并且解决起来非常困难。解决方案存在于集团内部-
keying realm, but they come with significant increases in complexity and computational intensity.
键控是一个领域，但它们的复杂性和计算强度显著增加。
The majority of the text for initial draft of this document was taken from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz.
本文件初稿的大部分文本取自Gregory M.Lebovitz编写的“在线路由协议包加密认证路线图”。
Brian Weis provided significant assistance in handling the many comments that came back during IESG review, including making textual edits directly to the XML. For his extensive efforts he was added as an author.
Brian Weis在处理IESG审查期间返回的许多评论方面提供了重要帮助，包括直接对XML进行文本编辑。由于他的广泛努力，他被增加为作家。
We would like to thank the following people for their thorough reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent, Vishwas Manral, Barry Leiba, Sean Turner, and Uma Chunduri.
我们要感谢以下人士的全面评论和评论：Brian Weis、Yoshifumi Nishida、Stephen Kent、Vishwas Manral、Barry Leiba、Sean Turner和Uma Chunduri。
Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for much of the time he worked on this document, though not at the time of its publishing. Thus, Juniper sponsored much of this effort.
作者Gregory M.Lebovitz受雇于Juniper Networks，Inc.从事本文档的大部分工作，但在本文档出版时并非如此。因此，Juniper赞助了大部分这项工作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[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月。
[ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure Security Report", October 2008, <http://pages.arbornetworks.com/rs/arbor/images/ ISR2008_EN.pdf>.
[ISR2008]McPherson，D.和C.Labovitz，“全球基础设施安全报告”，2008年10月<http://pages.arbornetworks.com/rs/arbor/images/ ISR2008\u EN.pdf>。
[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月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，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月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，2007年8月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年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月。
[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月。
[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月。
[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月。
[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月。
[SP.800-131A] Barker, E. and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", United States of America, National Institute of Science and Technology, NIST Special Publication 800-131A, January 2011.
[SP.800-131A]Barker，E.和A.Roginsky，“转换：密码算法和密钥长度使用的转换建议”，美国国家科学技术研究院，NIST特别出版物800-131A，2011年1月。
Authors' Addresses
作者地址
Gregory Lebovitz Aptos, California 95003 United States
Gregory Lebovitz Aptos，加利福尼亚州，美国95003
EMail: gregory.ietf@gmail.com
EMail: gregory.ietf@gmail.com
Manav Bhatia Alcatel-Lucent Bangalore, India
印度班加罗尔朗讯公司
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 United States
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号95134-1706
EMail: bew@cisco.com
URI: http://www.cisco.com
EMail: bew@cisco.com
URI: http://www.cisco.com