Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6518 M. Bhatia
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 February 2012
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 6518 M. Bhatia
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 February 2012
Keying and Authentication for Routing Protocols (KARP) Design Guidelines
路由协议的键控和认证（KARP）设计指南
Abstract
摘要
This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.
本文档是一系列涉及定义协议规范工作路线图的文档之一，用于在路由协议中使用现代密码机制和算法进行消息身份验证。特别是，它定义了密钥管理协议的框架，该协议可用于创建和管理会话密钥以实现消息身份验证和完整性。
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/rfc6518.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6518.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Conventions Used in This Document ..........................4
2. Categorizing Routing Protocols ..................................5
2.1. Category: Message Transaction Type .........................5
2.2. Category: Peer versus Group Keying .........................6
3. Consider the Future Existence of a Key Management Protocol ......6
3.1. Consider Asymmetric Keys ...................................7
3.2. Cryptographic Keys Life Cycle ..............................8
4. Roadmap .........................................................9
4.1. Work Phases on Any Particular Protocol .....................9
4.2. Work Items per Routing Protocol ...........................11
5. Routing Protocols in Categories ................................13
6. Supporting Incremental Deployment ..............................16
7. Denial-of-Service Attacks ......................................17
8. Gap Analysis ...................................................18
9. Security Considerations ........................................20
9.1. Use Strong Keys ...........................................21
9.2. Internal versus External Operation ........................22
9.3. Unique versus Shared Keys .................................22
9.4. Key Exchange Mechanism ....................................24
10. Acknowledgments ...............................................26
11. References ....................................................26
11.1. Normative References ....................................26
11.2. Informative References ..................................26
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Categorizing Routing Protocols ..................................5
2.1. Category: Message Transaction Type .........................5
2.2. Category: Peer versus Group Keying .........................6
3. Consider the Future Existence of a Key Management Protocol ......6
3.1. Consider Asymmetric Keys ...................................7
3.2. Cryptographic Keys Life Cycle ..............................8
4. Roadmap .........................................................9
4.1. Work Phases on Any Particular Protocol .....................9
4.2. Work Items per Routing Protocol ...........................11
5. Routing Protocols in Categories ................................13
6. Supporting Incremental Deployment ..............................16
7. Denial-of-Service Attacks ......................................17
8. Gap Analysis ...................................................18
9. Security Considerations ........................................20
9.1. Use Strong Keys ...........................................21
9.2. Internal versus External Operation ........................22
9.3. Unique versus Shared Keys .................................22
9.4. Key Exchange Mechanism ....................................24
10. Acknowledgments ...............................................26
11. References ....................................................26
11.1. Normative References ....................................26
11.2. Informative References ..................................26
In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that document states that "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）举办了一次关于“不必要的互联网流量”主题的研讨会。该研讨会的报告记录在RFC 4948[RFC4948]中。该文件第8.1节指出，“简单的风险分析表明，成本最低但中断最大的理想攻击目标是核心路由基础设施”。第8.2节要求“加强核心路由基础设施的安全性”。确定了拧紧的四个主要步骤：
o Increase the security mechanisms and practices for operating routers.
o 增加操作路由器的安全机制和实践。
o Clean up the Internet Routing Registry [IRR] repository, and securing both the database and the access, so that it can be used for routing verifications.
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 the SIDR working group.
OPSEC工作组正在处理第一个问题。第二个问题应该通过与那些在全球运行IRR的人联系来解决。SIDR工作组正在处理第三个问题。
This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. Thus, it is concerned with guidelines for describing issues and techniques for protecting the messages between directly communicating peers. This may overlap with, but is strongly distinct from, protection designed to ensure that routing information is properly authorized relative to sources of this information. Such authorizations are provided by other mechanisms and are outside the scope of this document and the work that relies on it.
本文档介绍了最后一个要点，即保护路由协议交换线路上的数据包。因此，它关注于描述问题的指南和保护直接通信的对等方之间的消息的技术。这可能与设计用于确保路由信息相对于此信息源得到适当授权的保护重叠，但与之截然不同。此类授权由其他机制提供，不在本文件及其相关工作的范围内。
This document uses the terminology "on the wire" to talk about the information used by routing 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. Other documents that will analyze individual protocols will need to indicate how they use the term "on the wire".
本文档使用术语“在线”来讨论路由系统使用的信息。该术语在RFC中广泛使用，但有几种不同的用法。在本文档中，它既指路由协议实例之间交换的信息，也指在特定情况下可能需要保护的底层协议。其他将分析单个协议的文档将需要指出它们如何使用术语“在线”。
The term "routing transport" is used to refer to the layer that exchanges the routing protocols. This can be TCP, UDP, or even direct link-level messaging in the case of some routing protocols. The term is used here to allow a referent for discussing both common and disparate issues that affect or interact with this dimension of the routing systems. The term is used here to refer generally to the set of mechanisms and exchanges underneath the routing protocol, whatever that is in specific cases.
术语“路由传输”用于指交换路由协议的层。在某些路由协议的情况下，这可以是TCP、UDP，甚至是直接链路级消息传递。这里使用该术语是为了允许引用人讨论影响路由系统这个维度或与之交互的常见和不同问题。这里使用的术语通常指路由协议下的一组机制和交换，无论在特定情况下是什么。
Keying and Authentication for Routing Protocols (KARP) will focus on an abstraction for keying information that describes the interface between routing protocols, operators, and automated key management. Conceptually, when routing protocols send or receive messages, they will look up the key to use in this abstract key table. Conceptually, there will be an interface for a routing protocol to make requests of automated key management when it is being used; when keys become available, they will be made available in the key table. There is no requirement that this abstraction be used for implementation; the abstraction serves the needs of standardization and management. Specifically, as part of the KARP work plan:
路由协议的键控和认证（KARP）将侧重于描述路由协议、操作员和自动密钥管理之间接口的键控信息抽象。从概念上讲，当路由协议发送或接收消息时，它们将在这个抽象密钥表中查找要使用的密钥。从概念上讲，路由协议将有一个接口，用于在使用时发出自动密钥管理请求；当键可用时，它们将在键表中可用。不要求将此抽象用于实现；抽象服务于标准化和管理的需要。具体而言，作为KARP工作计划的一部分：
1) KARP will design the key table abstraction, the interface between key management protocols and routing protocols, and possibly security protocols at other layers.
1) KARP将设计密钥表抽象、密钥管理协议和路由协议之间的接口，以及可能的其他层的安全协议。
2) For each routing protocol, KARP will define the mapping between how the protocol represents key material and the protocol-independent key table abstraction. When routing protocols share a common mechanism for authentication, such as the TCP Authentication Option, the same mapping is likely to be reused between protocols. An implementation may be able to move much of the keying logic into code related to this shared authentication primitive rather than code specific to routing protocols.
2) 对于每个路由协议，KARP将定义协议如何表示关键材料和独立于协议的关键表抽象之间的映射。当路由协议共享一个通用的身份验证机制（如TCP身份验证选项）时，可能会在协议之间重用相同的映射。一个实现可能能够将大部分键控逻辑移动到与此共享身份验证原语相关的代码中，而不是特定于路由协议的代码中。
3) When designing automated key management for both symmetric keys and group keys, we will only use the abstractions designed in point 1 above to communicate between automated key management and routing protocols.
3) 在为对称密钥和组密钥设计自动密钥管理时，我们将只使用上面第1点中设计的抽象来在自动密钥管理和路由协议之间进行通信。
Readers must refer to [THTS-REQS] for a clear definition of the scope, goals, non-goals, and the audience for the design work being undertaken in the KARP WG.
读者必须参考[THTS-REQS]以明确定义KARP工作组正在进行的设计工作的范围、目标、非目标和受众。
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]中所述进行解释。
This document places the routing protocols into two categories according to their requirements for authentication. We hope these categories will allow design teams to focus on security mechanisms for a given category. Further, we hope that each protocol in the group will be able to reuse the authentication mechanism. It is also hoped that, down the road, we can create one Key Management Protocol (KMP) per category (if not for several categories), so that the work can be easily leveraged for use in the various routing protocol groupings. KMPs are useful for allowing simple, automated updates of the traffic keys used in a base protocol. KMPs replace the need for humans, or operational support systems (OSS) routines, to periodically replace keys on running systems. It also removes the need for a chain of manual keys to be chosen or configured on such systems. When configured properly, a KMP will enforce the key freshness policy among peers by keeping track of the key's lifetime and negotiating a new key at the defined interval.
本文档根据认证要求将路由协议分为两类。我们希望这些类别将允许设计团队关注给定类别的安全机制。此外，我们希望组中的每个协议都能够重用身份验证机制。我们还希望，今后我们可以为每个类别（如果不是为几个类别）创建一个密钥管理协议（KMP），这样就可以轻松地利用这项工作在各种路由协议分组中使用。KMP对于允许对基本协议中使用的流量密钥进行简单、自动的更新非常有用。KMP取代了人工或操作支持系统（OSS）例程定期更换运行系统上的密钥的需要。它还消除了在此类系统上选择或配置手动钥匙链的需要。正确配置后，KMP将通过跟踪密钥的生命周期并在定义的时间间隔协商新密钥，在对等方之间强制执行密钥新鲜度策略。
The first category defines three types of messaging transactions used on the wire by the base routing protocol. They are as follows:
第一类定义了基本路由协议在线路上使用的三种类型的消息传递事务。详情如下:
One-to-One
一对一
One peer router directly and intentionally delivers a route update specifically to one other peer router. Examples are BGP [RFC4271]; LDP [RFC5036]; BFD [RFC5880]; and RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151]. Point-to-point modes of both IS-IS [RFC1195] and OSPF [RFC2328], when sent over both traditional point-to-point links and when using multi-access layers, may both also fall into this category.
一个对等路由器直接有意地向另一个对等路由器发送路由更新。例如BGP[RFC4271]；LDP[RFC5036]；BFD[RFC5880]；和RSVP-TE[RFC3209]、[RFC3473]、[RFC4726]和[RFC5151]。IS-IS[RFC1195]和OSPF[RFC2328]的点对点模式在通过传统点对点链路发送和使用多接入层时也可能属于这一类。
One-to-Many
一对多
A router peers with multiple other routers on a single network segment -- i.e., on link local -- such that it creates and sends one route update message that is intended for multiple peers. Examples would be OSPF and IS-IS in their broadcast, non-point-to-point mode and Routing Information Protocol (RIP) [RFC2453].
路由器与单个网段（即本地链路）上的多个其他路由器对等，因此它创建并发送一条针对多个对等的路由更新消息。例如OSPF和IS-IS的广播、非点对点模式和路由信息协议（RIP）[RFC2453]。
Multicast
多播
Multicast protocols have unique security properties because they are inherently group-based protocols; thus, they have group keying requirements at the routing level where link-local
组播协议具有独特的安全特性，因为它们本质上是基于组的协议；因此，它们在路由级别具有组键控需求，其中链路是本地的
routing messages are multicasted. Also, at least in the case of Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], some messages are sent unicast to a given peer(s), as is the case with router-close-to-sender and the "Rendezvous Point". Some work for application-layer message security has been done in the Multicast Security (MSEC) working group and may be helpful to review, but it is not directly applicable.
路由消息是多播的。此外，至少在协议独立多播稀疏模式（PIM-SM）[RFC4601]的情况下，一些消息被单播发送到给定的对等方，就像路由器靠近发送方和“集合点”的情况一样。多播安全性（MSEC）工作组已经完成了一些应用层消息安全性方面的工作，可能有助于审查，但并不直接适用。
These categories affect both the routing protocol view of the communication and the actual message transfer. As a result, some message transaction types for a few routing protocols may be mixtures, for example, using broadcast where multicast might be expected or using unicast to deliver what looks to the routing protocol like broadcast or multicast.
这些类别影响通信的路由协议视图和实际的消息传输。结果，一些路由协议的一些消息事务类型可能是混合的，例如，在可能期望多播的地方使用广播，或者使用单播来传递路由协议的外观，如广播或多播。
Protocol security analysis documents produced in the KARP working group need to pay attention both to the semantics of the communication and the techniques that are used for the message exchanges.
KARP工作组编制的协议安全分析文件需要注意通信的语义和用于消息交换的技术。
The second category is the keying mechanism that will be used to distribute the session keys to the routing transports. They are as follows:
第二类是密钥机制，用于将会话密钥分发到路由传输。详情如下:
Peer Keying
对等键控
One router sends the keying messages only to one other router, such that a one-to-one, uniquely keyed security association (SA) is established between the two routers (e.g., BGP, BFD and LDP).
一个路由器仅向另一个路由器发送密钥消息，以便在两个路由器（例如，BGP、BFD和LDP）之间建立一对一的唯一密钥安全关联（SA）。
Group Keying
组键控
One router creates and distributes a single keying message to multiple peers. In this case, a group SA will be established and used among multiple peers simultaneously. Group keying exists for protocols like OSPF [RFC2328] and for multicast protocols like PIM-SM [RFC4601].
一个路由器创建一个键控消息并将其分发给多个对等方。在这种情况下，将在多个对等方之间同时建立和使用组SA。对于OSPF[RFC2328]等协议和PIM-SM[RFC4601]等多播协议，存在组键控。
When it comes time for the KARP WG to design a reusable model for a Key Management Protocol (KMP), [RFC4107] should be consulted.
当KARP工作组为密钥管理协议（KMP）设计可重用模型时，应参考[RFC4107]。
When conducting the design work on a manually keyed version of a routing protocol's authentication mechanism, consideration must be made for the eventual use of a KMP. In particular, design teams must consider what parameters would need to be handed to the routing protocols by a KMP.
在对路由协议认证机制的手动密钥版本进行设计时，必须考虑KMP的最终使用。特别是，设计团队必须考虑哪些参数需要通过KMP交给路由协议。
Examples of parameters that might need to be passed are as follows: a security association identifier (e.g., IPsec Security Parameter Index (SPI) or the TCP Authentication Option's (TCP-AO's) KeyID), a key lifetime (which may be represented in either bytes or seconds), the cryptographic algorithms being used, the keys themselves, and the directionality of the keys (i.e., receiving versus the sending keys).
可能需要传递的参数示例如下：安全关联标识符（例如，IPsec安全参数索引（SPI）或TCP身份验证选项（TCP-AO）的密钥ID）、密钥生存期（可能以字节或秒表示）、使用的加密算法、密钥本身、，以及键的方向性（即，接收键与发送键）。
The use of asymmetric keys can be a very powerful way to authenticate machine peers as used in routing protocol peer exchanges. If generated on the machine, and never moved off the machine, these keys will not need to be changed if an administrator leaves the organization. Since the keys are random, they are far less susceptible to off-line dictionary and guessing attacks.
在路由协议对等交换中，使用非对称密钥可以非常有效地对机器对等进行身份验证。如果这些密钥是在计算机上生成的，并且从未离开过计算机，则如果管理员离开组织，则无需更改这些密钥。由于密钥是随机的，它们不太容易受到离线字典和猜测攻击。
An easy and simple way to use asymmetric keys is to start by having the router generate a public/private key pair. At the time of this writing, the recommended key size for algorithms based on integer factorization cryptography like RSA is 1024 bits and 2048 bits for extremely valuable keys like the root key pair used by a certification authority. It is believed that a 1024-bit RSA key is equivalent in strength to 80-bit symmetric keys and 2048-bit RSA keys to 112-bit symmetric keys [RFC3766]. Elliptic Curve Cryptography (ECC) [RFC4492] appears to be secure with shorter keys than those needed by other asymmetric key algorithms. National Institute of Standards and Technology (NIST) guidelines [NIST-800-57] state that ECC keys should be twice the length of equivalent strength symmetric key algorithms. Thus, a 224-bit ECC key would roughly have the same strength as a 112-bit symmetric key.
使用非对称密钥的一种简单易行的方法是，首先让路由器生成一对公钥/私钥。在撰写本文时，对于基于整数分解加密（如RSA）的算法，建议的密钥大小为1024位，对于极有价值的密钥（如证书颁发机构使用的根密钥对），建议的密钥大小为2048位。据信，1024位RSA密钥的强度相当于80位对称密钥，2048位RSA密钥的强度相当于112位对称密钥[RFC3766]。椭圆曲线密码（ECC）[RFC4492]似乎比其他非对称密钥算法所需的密钥更短，因而更安全。国家标准与技术研究所（NIST）指南[NIST-800-57]规定，ECC密钥长度应为等效强度对称密钥算法长度的两倍。因此，224位ECC密钥的强度大致与112位对称密钥相同。
Many routers have the ability to be remotely managed using Secure Shell (SSH) Protocol [RFC4252] and [RFC4253]. As such, routers will also have the ability to generate and store an asymmetric key pair, because this is the common authentication method employed by SSH when an administrator connects to a router for management sessions.
许多路由器都能够使用Secure Shell（SSH）协议[RFC4252]和[RFC4253]进行远程管理。因此，路由器还能够生成和存储非对称密钥对，因为这是SSH在管理员连接到路由器进行管理会话时使用的常用身份验证方法。
Once an asymmetric key pair is generated, the KMP generating security association parameters and keys for routing protocol may use the machine's asymmetric keys for the authentication mechanism. The form of the identity proof could be raw keys, the more easily administrable self-signed certificate format, or a PKI-issued [RFC5280] certificate credential.
一旦生成非对称密钥对，生成路由协议的安全关联参数和密钥的KMP就可以将机器的非对称密钥用于认证机制。身份证明的形式可以是原始密钥、更易于管理的自签名证书格式或PKI颁发的[RFC5280]证书凭证。
Regardless of which credential is standardized, the authentication mechanism can be as simple as a strong hash over a string of human-readable and transferable form of ASCII characters. More complex, but also more secure, the identity proof could be verified through the use of a PKI system's revocation checking mechanism, (e.g., Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) responder). If the SHA-1 fingerprint is used, the solution could be as simple as loading a set of neighbor routers' peer ID strings into a table and listing the associated fingerprint string for each ID string. In most organizations or peering points, this list will not be longer than a thousand or so routers, and often the list will be much shorter. In other words, the entire list for a given organization's router ID and hash could be held in a router's configuration file, uploaded, downloaded, and moved about at will. Additionally, it doesn't matter who sees or gains access to these fingerprints, because they can be distributed publicly as it needn't be kept secret.
无论哪种凭证是标准化的，身份验证机制都可以像对人类可读和可转移的ASCII字符字符串进行强哈希一样简单。更复杂但也更安全的身份证明可以通过使用PKI系统的撤销检查机制（例如证书撤销列表（CRL）或在线证书状态协议（OCSP）响应程序）进行验证。如果使用SHA-1指纹，解决方案可能非常简单，只需将一组邻居路由器的对等ID字符串加载到表中，并列出每个ID字符串的关联指纹字符串。在大多数组织或对等点中，此列表的长度不会超过1000个左右的路由器，并且通常会短得多。换句话说，给定组织的路由器ID和哈希的整个列表可以保存在路由器的配置文件中，可以随意上传、下载和移动。此外，谁看到或获得这些指纹并不重要，因为它们可以公开分发，因为不需要保密。
Cryptographic keys should have a limited lifetime and may need to be changed when an operator who had access to them leaves. Using a key chain, a set of keys derived from the same keying material and used one after the other, also does not help as one still has to change all the keys in the key chain when an operator having access to all those keys leaves the company. Additionally, key chains will not help if the routing transport subsystem does not support rolling over to the new keys without bouncing the routing sessions and adjacencies. So the first step is to fix the routing stack so that routing protocols can change keys without breaking or bouncing the adjacencies.
加密密钥应具有有限的生存期，并且可能需要在有权访问密钥的操作员离开时进行更改。使用钥匙链，即从相同的钥匙材料中衍生出来的一组钥匙，并且一个接一个地使用，也没有帮助，因为当拥有所有钥匙的操作员离开公司时，仍然需要更换钥匙链中的所有钥匙。此外，如果路由传输子系统不支持在不跳转路由会话和邻接的情况下滚动到新密钥，则密钥链将没有帮助。因此，第一步是修复路由堆栈，这样路由协议就可以在不破坏或反弹邻接的情况下更改密钥。
An often cited reason for limiting the lifetime of a key is to minimize the damage from a compromised key. It could be argued that it is likely a user will not discover an attacker has compromised the key if the attacker remains "passive"; thus, relatively frequent key changes will limit any potential damage from compromised keys.
限制密钥使用寿命的一个经常被引用的原因是将受损密钥造成的损害降至最低。可以说，如果攻击者保持“被动”，用户很可能不会发现攻击者已泄露密钥；因此，相对频繁的密钥更改将限制受损密钥的任何潜在损害。
Another threat against the long-lived key is that one of the systems storing the key, or one of the users entrusted with the key, will be subverted. So, while there may not be cryptographic motivations of changing the keys, there could be system security motivations for rolling the key.
对长寿命密钥的另一个威胁是，存储该密钥的一个系统或委托该密钥的一个用户将被破坏。因此，虽然更改密钥可能没有密码动机，但滚动密钥可能有系统安全动机。
Although manual key distribution methods are subject to human error and frailty, more frequent manual key changes might actually increase the risk of exposure, as it is during the time that the keys are being changed that they are likely to be disclosed. In these cases, especially when very strong cryptography is employed, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequent, poorly controlled manual key distributions. In general, where strong cryptography is employed, physical, procedural, and logical access protection considerations often have more impact on the key life than do algorithm and key size factors.
尽管手动钥匙分配方法存在人为错误和缺陷，但更频繁的手动钥匙更改实际上可能会增加暴露风险，因为钥匙更改期间可能会被披露。在这些情况下，特别是当使用非常强的加密时，可能更谨慎的做法是使用较少的、控制良好的手动密钥分发，而不是更频繁的、控制较差的手动密钥分发。通常，在使用强加密的情况下，物理、程序和逻辑访问保护考虑因素对密钥寿命的影响往往大于算法和密钥大小因素。
For incremental deployments, we could start by associating life times with the send and the receive keys in the key chain for the long-lived keys. This is an incremental approach that we could use until the cryptographic keying material for individual sessions is derived from the keying material stored in a database of long-lived cryptographic keys as described in [CRPT-TAB]. A key derivation function (KDF) and its inputs are also specified in the database of long-lived cryptographic keys; session-specific values based on the routing protocol are input to the KDF. Protocol-specific key identifiers may be assigned to the cryptographic keying material for individual sessions if needed.
对于增量部署，我们可以首先将生命周期与长寿命密钥的密钥链中的发送和接收密钥相关联。这是一种增量方法，我们可以使用该方法，直到单个会话的加密密钥材料从[CRPT-TAB]中所述的长期密码密钥数据库中存储的密钥材料中派生出来。密钥派生函数（KDF）及其输入也在长寿命密码密钥数据库中指定；基于路由协议的会话特定值被输入到KDF。如果需要，可以将特定于协议的密钥标识符分配给各个会话的加密密钥材料。
The long-lived cryptographic keys used by the routing protocols can either be inserted manually in a database or make use of an automated key management protocol to do this.
路由协议使用的长寿命加密密钥可以手动插入数据库中，也可以使用自动密钥管理协议来执行此操作。
It is believed that improving security for any routing protocol will be a two-phase process. The first phase would be to modify routing protocols to support modern cryptography algorithms and key agility. The second phase would be to design and move to an automated key management mechanism. This is like a crawl, walk, and run process. In order for operators to accept these phases, we believe that the key management protocol should be clearly separated from the routing transport. This would mean that the routing transport subsystem is oblivious to how the keys are derived, exchanged, and downloaded as long as there is something that it can use. It is like having a
人们相信，提高任何路由协议的安全性都将是一个分为两个阶段的过程。第一阶段是修改路由协议，以支持现代加密算法和密钥灵活性。第二阶段是设计并转向自动密钥管理机制。这就像是一个爬行、行走和跑步的过程。为了让运营商接受这些阶段，我们认为密钥管理协议应该与路由传输明确分开。这意味着路由传输子系统不知道密钥是如何派生、交换和下载的，只要有它可以使用的东西。这就像有一个
routing-protocol-configuration switch that requests the security module for the "KARP security parameters" so that it can refer to some module written, maintained, and operated by security experts and insert those parameters in the routing exchange.
路由协议配置开关，向安全模块请求“KARP安全参数”，以便它可以引用由安全专家编写、维护和操作的某些模块，并将这些参数插入路由交换中。
The desired end state for the KARP work contains several items. First, the people desiring to deploy securely authenticated and integrity validated packets between routing peers have the tools specified, implemented, and shipped in order to deploy. These tools should be fairly simple to implement and not more complex than the security mechanisms to which the operators are already accustomed. (Examples of security mechanisms to which router operators are accustomed include: the use of asymmetric keys for authentication in SSH for router configuration, the use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, the use of self-signed certificates for HTTP Secure (HTTPS) access to device Web-based user interfaces, the use of strongly constructed passwords and/or identity tokens for user identification when logging into routers and management systems.) While the tools that we intend to specify may not be able to stop a deployment from using "foobar" as an input key for every device across their entire routing domain, we intend to make a solid, modern security system that is not too much more difficult than that. In other words, simplicity and deployability are keys to success. The routing protocols will specify modern cryptographic algorithms and security mechanisms. Routing peers will be able to employ unique, pair-wise keys per peering instance, with reasonable key lifetimes, and updating those keys on a regular basis will be operationally easy, causing no service interruption.
KARP工作所需的结束状态包含多个项目。首先，希望在路由对等点之间部署经过安全认证和完整性验证的数据包的人，已经指定、实现和发布了用于部署的工具。这些工具的实现应该相当简单，并且不会比操作员已经习惯的安全机制更复杂。（路由器操作员习惯的安全机制示例包括：在SSH中使用非对称密钥进行身份验证以进行路由器配置，在TCP MD5中使用预共享密钥（PSK）进行BGP保护，在HTTP安全（HTTPS）中使用自签名证书。）访问基于Web的设备用户界面，在登录路由器和管理系统时使用强构造密码和/或身份令牌进行用户标识。）而我们打算指定的工具可能无法阻止部署使用“foobar”作为每个设备在其整个路由域中的输入密钥，我们打算建立一个可靠的、现代化的安全系统，这不会比这更困难。换句话说，简单性和可部署性是成功的关键。路由协议将指定现代密码算法和安全机制。路由对等方将能够在每个对等实例中使用唯一的、成对的密钥，具有合理的密钥生命周期，并且定期更新这些密钥在操作上很容易，不会造成服务中断。
Achieving the above described end state using manual keys may be pragmatic only in very small deployments. However, manual keying in larger deployments will be too burdensome for operators. Thus, the second goal is to support key life cycle management with a KMP. We expect that both manual and automated key management will coexist in the real world.
使用手动键实现上述最终状态可能仅在非常小的部署中才实用。但是，在较大的部署中手动键入对操作员来说太麻烦了。因此，第二个目标是用KMP支持关键生命周期管理。我们期望手动和自动密钥管理将在现实世界中共存。
In accordance with the desired end state just described, we define two main work phases for each routing protocol:
根据刚才描述的期望终端状态，我们为每个路由协议定义了两个主要工作阶段：
1. Enhance the routing protocol's current authentication mechanism(s). This work involves enhancing a routing protocol's current security mechanisms in order to achieve a consistent, modern level of security functionality within its existing key management framework. It is understood and accepted that the existing key management frameworks are largely based on manual keys. Since many operators have already built operational support systems (OSS) around these manual key implementations, there is some automation available for an operator to leverage in
1. 增强路由协议的当前身份验证机制。这项工作涉及增强路由协议的当前安全机制，以便在其现有密钥管理框架内实现一致的现代安全功能。人们理解并接受，现有的密钥管理框架主要基于手动密钥。由于许多运营商已经围绕这些手动键实现构建了运营支持系统（OSS），因此运营商可以利用一些自动化
that way, if the underlying mechanisms are themselves secure. In this phase, we explicitly exclude embedding or creating a KMP. Refer to [THTS-REQS] for the list of the requirements for Phase 1 work.
这样，如果底层机制本身是安全的。在这个阶段，我们明确排除嵌入或创建KMP。关于第1阶段工程的要求清单，请参考[THTS-REQS]。
2. Develop an automated key management framework. The second phase will focus on the development of an automated keying framework to facilitate unique pair-wise (group-wise, where applicable) keys per peering instance. This involves the use of a KMP. The use of automatic key management mechanisms offers a number of benefits over manual keying. Most important, it provides fresh traffic keying material for each session, thus helping to prevent inter-connection replay attacks. In an inter-connection replay attack, protocol packets from the earlier protocol session are replayed affecting the current execution of the protocol. A KMP is also helpful because it negotiates unique, pair-wise, random keys, without administrator involvement. It negotiates several SA parameters like algorithms, modes, and parameters required for the secure connection, thus providing interoperability between endpoints with disparate capabilities and configurations. In addition it could also include negotiating the key lifetimes. The KMP can thus keep track of those lifetimes using counters and can negotiate new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the traffic key, and those new traffic keys will be installed and used in the current connection. In summary, a KMP provides a protected channel between the peers through which they can negotiate and pass important data required to exchange proof of identities, derive traffic keys, determine rekeying, synchronize their keying state, signal various keying events, notify with error messages, etc.
2. 开发一个自动化的密钥管理框架。第二阶段的重点是开发一个自动键控框架，以便为每个对等实例提供唯一的成对（分组，如适用）键。这涉及使用KMP。使用自动密钥管理机制比手动密钥管理有许多好处。最重要的是，它为每个会话提供了新的流量键控材料，从而有助于防止连接间重播攻击。在连接间重播攻击中，重播来自先前协议会话的协议数据包，从而影响协议的当前执行。KMP也很有用，因为它可以在没有管理员参与的情况下协商唯一的、成对的随机密钥。它协商几个SA参数，如安全连接所需的算法、模式和参数，从而提供具有不同功能和配置的端点之间的互操作性。此外，它还可以包括协商关键生命周期。因此，KMP可以使用计数器跟踪这些生命周期，并可以在新密钥和参数过期之前协商它们，而无需管理员交互。此外，如果出现违规情况，更改KMP密钥将立即导致交通密钥的重新密钥，并且这些新交通密钥将在当前连接中安装和使用。总之，KMP在对等方之间提供了一个受保护的通道，通过该通道，对等方可以协商和传递交换身份证明、派生流量密钥、确定密钥更新、同步其密钥更新状态、向各种密钥更新事件发信号、用错误消息通知等所需的重要数据。
Each routing protocol will have a team (the Routing_Protocol-KARP team, e.g., the OSPF-KARP team) working on incrementally improving the security of a routing protocol. These teams will have the following main work items:
每个路由协议将有一个团队（routing_protocol-KARP团队，例如OSPF-KARP团队）致力于逐步提高路由协议的安全性。这些团队将有以下主要工作项目：
PHASE 1:
第一阶段：
Characterize the Routing Protocol
描述路由协议的特征
Assess the routing protocol to see what authentication and integrity mechanisms it has today. Does it need significant improvement to its existing mechanisms or not? This will
评估路由协议，看看它现在有什么身份验证和完整性机制。它是否需要对现有机制进行重大改进？这将
include determining if modern, strong security algorithms and parameters are present and if the protocol supports key agility without bouncing adjacencies.
包括确定是否存在现代、强大的安全算法和参数，以及协议是否支持密钥敏捷性，而不存在跳跃式邻接。
Define Optimal State
定义最佳状态
List the requirements for the routing protocol's session key usage and format to contain modern, strong security algorithms and mechanisms, per the Requirements document [THTS-REQS]. The goal here is to determine what is needed for the routing protocol to be used securely with at least manual key management.
根据需求文件[THTS-REQS]，列出路由协议会话密钥使用和格式的要求，以包含现代、强大的安全算法和机制。这里的目标是确定路由协议至少需要手动密钥管理才能安全使用。
Gap Analysis
差距分析
Enumerate the requirements for this protocol to move from its current security state, the first bullet, to its optimal state, as listed just above.
列举此协议从其当前安全状态（第一个项目符号）移动到其最佳状态的要求，如上文所列。
Transition and Deployment Considerations
过渡和部署注意事项
Document the operational transition plan for moving from the old to the new security mechanism. Will adjacencies need to bounce? What new elements/servers/services in the infrastructure will be required? What is an example work flow that an operator will take? The best possible case is if the adjacency does not break, but this may not always be possible.
记录从旧安全机制过渡到新安全机制的运营过渡计划。邻接是否需要反弹？基础架构中需要哪些新的元素/服务器/服务？操作员将采用的工作流程示例是什么？最好的情况是邻接不中断，但这可能并不总是可能的。
Define, Assign, Design
定义、分配、设计
Create a deliverables list of the design and specification work, with milestones. Define owners. Release one or more documents.
创建一份设计和规范工作的可交付成果清单，其中包含里程碑。定义所有者。发布一个或多个文档。
PHASE 2:
第二阶段：
KMP Analysis
KMP分析
Review requirements for KMPs. Identify any nuances for this particular routing protocol's needs and its use cases for a KMP. List the requirements that this routing protocol has for being able to be used in conjunction with a KMP. Define the optimal state and check how easily it can be decoupled from the KMP.
审查KMP的要求。确定此特定路由协议的需求及其KMP用例的任何细微差别。列出此路由协议能够与KMP一起使用的要求。定义最佳状态，并检查其与KMP解耦的容易程度。
Gap Analysis
差距分析
Enumerate the requirements for this protocol to move from its current security state to its optimal state, with respect to the key management.
列举此协议从其当前安全状态移动到其最佳状态的有关密钥管理的要求。
Define, Assign, Design
定义、分配、设计
Create a deliverables list of the design and specification work, with milestones. Define owners. Generate the design and document work for a KMP to be able to generate the routing protocol's session keys for the packets on the wire. These will be the arguments passed in the API to the KMP in order to bootstrap the session keys for the routing protocol.
创建一份设计和规范工作的可交付成果清单，其中包含里程碑。定义所有者。生成KMP的设计和文档工作，以便能够为线路上的数据包生成路由协议的会话密钥。这些参数将在API中传递给KMP，以便引导路由协议的会话密钥。
There will also be a team formed to work on the base framework mechanisms for each of the main categories.
此外，还将组建一个团队，为每个主要类别制定基本框架机制。
This section groups the routing protocols into categories according to attributes set forth in the Categories' Section (Section 2). Each group will have a design team tasked with improving the security of the routing protocol mechanisms and defining the KMP requirements for their group, then rolling both into a roadmap document upon which they will execute.
本节根据类别部分（第2节）中规定的属性将路由协议分组。每个小组都将有一个设计团队，负责提高路由协议机制的安全性，并为他们的小组定义KMP要求，然后将这两个要求合并到路线图文档中，并在其中执行。
BGP, LDP, PCEP, and MSDP
BGP、LDP、PCEP和MSDP
These routing protocols fall into the category of the one-to-one peering messages and will use peer keying protocols. Border Gateway Protocol (BGP) [RFC4271], Path Computation Element Communication Protocol (PCEP) [RFC5440], and Multicast Source Discovery Protocol (MSDP) [RFC3618] messages are transmitted over TCP, while Label Distribution Protocol (LDP) [RFC5036] uses both UDP and TCP. A team will work on one mechanism to cover these TCP unicast protocols. Much of the work on the routing protocol update for its existing authentication mechanism has already occurred in the TCPM working group, on the TCP-AO [RFC5925] document, as well as its cryptography-helper document, TCP-AO-CRYPTO [RFC5926]. However, TCP-AO cannot be used for discovery exchanges carried in LDP as those are carried over UDP. A separate team might want to look at LDP. Another exception is the mode where LDP is used directly on the LAN. The work for this may go into the group keying category (along with OSPF) as mentioned below.
这些路由协议属于一对一对等消息的范畴，将使用对等键控协议。边界网关协议（BGP）[RFC4271]、路径计算元素通信协议（PCEP）[RFC5440]和多播源发现协议（MSDP）[RFC3618]消息通过TCP传输，而标签分发协议（LDP）[RFC5036]同时使用UDP和TCP。一个团队将研究一种机制来覆盖这些TCP单播协议。TCPM工作组已经在TCP-AO[RFC5925]文档及其密码学助手文档TCP-AO-CRYPTO[RFC5926]中完成了许多关于现有身份验证机制路由协议更新的工作。但是，TCP-AO不能用于LDP中进行的发现交换，因为这些交换是通过UDP进行的。另一个团队可能会考虑自民党。另一个例外是LDP直接在LAN上使用的模式。这方面的工作可能属于以下提到的组键控类别（以及OSPF）。
OSPF, IS-IS, and RIP
OSPF、IS-IS和RIP
The routing protocols that fall into the category group keying (with one-to-many peering) includes OSPF [RFC2328], IS-IS [RFC1195] and RIP [RFC2453]. Not surprisingly, all these routing protocols have two other things in common. First, they are run on a combination of the OSI datalink Layer 2, and the OSI network Layer 3. By this we mean that they have a component of how the routing protocol works, which is specified in Layer 2 as well as in Layer 3. Second, they are all internal gateway protocols (IGPs). The keying mechanisms will be much more complicated to define for these than for a one-to-one messaging protocol.
属于组键控（具有一对多对等）类别的路由协议包括OSPF[RFC2328]、IS-IS[RFC1195]和RIP[RFC2453]。毫不奇怪，所有这些路由协议还有两个共同点。首先，它们在OSI数据链路层2和OSI网络层3的组合上运行。我们的意思是，它们有一个路由协议工作原理的组件，在第2层和第3层中都有指定。其次，它们都是内部网关协议（IGP）。与一对一消息传递协议相比，为这些协议定义密钥机制要复杂得多。
BFD
BFD
Because it is less of a routing protocol, per se, and more of a peer liveness detection mechanism, Bidirectional Forwarding Detection (BFD) [RFC5880] will have its own team. BFD is also different from the other protocols covered here as it works on millisecond timers and would need separate considerations to mitigate the potential for Denial-of-Service (DoS) attacks. It also raises interesting issues [RFC6039] with respect to the sequence number scheme that is generally deployed to protect against replay attacks as this space can roll over quite frequently because of the rate at which BFD packets are generated.
由于双向转发检测（BFD）[RFC5880]本身不是一种路由协议，而是一种对等活跃度检测机制，因此它将拥有自己的团队。BFD也不同于本文介绍的其他协议，因为它工作在毫秒计时器上，需要单独考虑以减轻拒绝服务（DoS）攻击的可能性。它还提出了有关序列号方案的有趣问题[RFC6039]，通常部署该方案以防止重播攻击，因为由于BFD数据包的生成速率，该空间可能会非常频繁地滚动。
RSVP and RSVP-TE
RSVP和RSVP-TE
The Resource reSerVation Protocol (RSVP) [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747]. In this mode, an integrity object is attached to each RSVP message to transmit a keyed message digest. This message digest allows the recipient to verify the identity of the RSVP node that sent the message and to validate the integrity of the message. Through the inclusion of a sequence number in the scope of the digest, the digest also offers replay protection.
资源预留协议（RSVP）[RFC2205]允许对RSVP邻居进行逐跳身份验证，如[RFC2747]中所述。在此模式下，完整性对象附加到每个RSVP消息，以传输密钥消息摘要。此消息摘要允许收件人验证发送消息的RSVP节点的身份，并验证消息的完整性。通过在摘要范围中包含序列号，摘要还提供了重播保护。
[RFC2747] does not dictate how the key for the integrity operation is derived. Currently, most implementations of RSVP use a statically configured key, on a per-interface or per-neighbor basis.
[RFC2747]不规定完整性操作的密钥如何派生。目前，RSVP的大多数实现在每个接口或每个邻居的基础上使用静态配置的密钥。
RSVP relies on a per-peer authentication mechanism where each hop authenticates its neighbor using a shared key or a certificate.
RSVP依赖于每个对等身份验证机制，其中每个跃点使用共享密钥或证书对其邻居进行身份验证。
Trust in this model is transitive. Each RSVP node trusts, explicitly, only its RSVP next-hop peers through the message digest contained in the INTEGRITY object [RFC2747]. The next-hop
该模型中的信任是可传递的。每个RSVP节点显式地只信任其RSVP下一跳节点通过包含在INTEGRITY对象[RFC2747]中的消息摘要进行对等。下一跳
RSVP speaker, in turn, trusts its own peers, and so on. See also the document "RSVP Security Properties" [RFC4230] for more background.
反过来，RSVP演讲者信任自己的同龄人，等等。有关更多背景信息，请参见文档“RSVP安全属性”[RFC4230]。
The keys used for protecting the RSVP messages can be group keys (for example, distributed via the Group Domain of Interpretation (GDOI) [RFC6407], as discussed in [GDOI-MAC]).
用于保护RSVP消息的密钥可以是组密钥（例如，如[GDOI-MAC]中所述，通过组解释域（GDOI）[RFC6407]分发）。
The trust an RSVP node has with another RSVP node has an explicit and implicit component. Explicitly, the node trusts the other node to maintain the integrity (and, optionally, the confidentiality) of RSVP messages depending on whether authentication or encryption (or both) are used. This means that the message has not been altered or its contents seen by another, non-trusted node. Implicitly, each node trusts the other node to maintain the level of protection specified within that security domain. Note that in any group key management scheme, like GDOI, each node trusts all the other members of the group with regard to data origin authentication.
一个RSVP节点与另一个RSVP节点之间的信任具有显式和隐式组件。明确地说，节点信任另一个节点来维护RSVP消息的完整性（以及可选的机密性），这取决于是否使用了身份验证或加密（或两者都使用）。这意味着消息未被更改或其内容未被另一个不受信任的节点看到。隐式地，每个节点都信任另一个节点来维持该安全域中指定的保护级别。请注意，在任何组密钥管理方案（如GDOI）中，每个节点在数据源身份验证方面都信任组中的所有其他成员。
RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151] is an extension of the RSVP protocol for traffic engineering. It supports the reservation of resources across an IP network and is used for establishing MPLS label switch paths (LSPs), taking into consideration network constraint parameters such as available bandwidth and explicit hops. RSVP-TE signaling is used to establish both intra- and inter-domain TE LSPs.
RSVP-TE[RFC3209]、[RFC3473]、[RFC4726]和[RFC5151]是用于流量工程的RSVP协议的扩展。它支持在IP网络上保留资源，并用于建立MPLS标签交换路径（LSP），同时考虑可用带宽和显式跳数等网络约束参数。RSVP-TE信令用于建立域内和域间TE LSP。
When signaling an inter-domain RSVP-TE LSP, operators may make use of the security features already defined for RSVP-TE [RFC3209]. This may require some coordination between domains to share keys ([RFC2747][RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with Fast Reroute, since the merge point (MP) and point of local repair (PLR) should also share the key.
当向域间RSVP-TE LSP发送信号时，运营商可以利用已经为RSVP-TE定义的安全特性[RFC3209]。这可能需要域之间进行一些协调以共享密钥（[RFC2747][RFC3097]），并且需要注意确保密钥的更改足够频繁。注意，如果域边界节点通过快速重路由得到保护，这可能涉及额外的同步，因为合并点（MP）和本地修复点（PLR）也应该共享密钥。
For inter-domain signaling for MPLS-TE, the administrators of neighboring domains must satisfy themselves as to the existence of a suitable trust relationship between the domains. In the absence of such a relationship, the administrators should decide not to deploy inter-domain signaling and should disable RSVP-TE on any inter-domain interfaces.
对于MPLS-TE的域间信令，相邻域的管理员必须确信域之间存在合适的信任关系。在没有这种关系的情况下，管理员应决定不部署域间信令，并应在任何域间接口上禁用RSVP-TE。
KARP will currently be working only on RSVP-TE, as the native RSVP lies outside the scope of the WG charter.
KARP目前仅在RSVP-TE上工作，因为本地RSVP不在工作组章程的范围内。
PIM-SM and PIM-DM
PIM-SM和PIM-DM
Finally, the multicast protocols Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] and Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] will be grouped together. PIM-SM multicasts routing information (Hello, Join/Prune, Assert) on a link-local basis, using a defined multicast address. In addition, it specifies unicast communication for exchange of information (Register, Register-Stop) between the router closest to a group sender and the "Rendezvous Point". The Rendezvous Point is typically not "on-link" for a particular router. While much work has been done on multicast security for application-layer groups, little has been done to address the problem of managing hundreds or thousands of small one-to-many groups with link-local scope. Such an authentication mechanism should be considered along with the router-to-Rendezvous Point authentication mechanism. The most important issue is ensuring that only the "authorized neighbors" get the keys for source/group (S,G), so that rogue routers cannot participate in the exchanges. Another issue is that some of the communication may occur intra-domain, e.g., the link-local messages in an enterprise, while others for the same (*,G) may occur inter-domain, e.g., the router-to-Rendezvous Point messages may be from one enterprise's router to another.
最后，将多播协议独立多播稀疏模式（PIM-SM）[RFC4601]和协议独立多播密集模式（PIM-DM）[RFC3973]分组在一起。PIM-SM使用定义的多播地址在本地链路上多播路由信息（Hello、Join/Prune、Assert）。此外，它还规定了在距离组发送方最近的路由器和“集合点”之间交换信息（寄存器、寄存器停止）的单播通信。对于特定路由器，集合点通常不在“链路上”。虽然在应用层组的多播安全方面已经做了很多工作，但在解决管理数百或数千个具有链路本地范围的小型一对多组的问题方面却做得很少。这种认证机制应该与路由器到集合点的认证机制一起考虑。最重要的问题是确保只有“授权邻居”才能获得源/组（S、G）的密钥，从而使恶意路由器无法参与交换。另一个问题是，一些通信可能发生在域内，例如，企业中的链路本地消息，而相同（*，g）的其他通信可能发生在域间，例如，路由器到集合点消息可能从一个企业的路由器到另一个企业的路由器。
One possible solution proposes a region-wide "master" key server (possibly replicated), and one "local" key server per speaking router. There is no issue with propagating the messages outside the link, because link-local messages, by definition, are not forwarded. This solution is offered only as an example of how work may progress; further discussion should occur in this work team. Specification of a link-local protection mechanism for PIM-SM is defined in [RFC4601], and this mechanism has been updated in PIM-SM-LINKLOCAL [RFC5796]. However, the KMP part is completely unspecified and will require work outside the expertise of the PIM working group to accomplish, another example of why this roadmap is being created.
一种可能的解决方案是在整个区域范围内提供一个“主”密钥服务器（可能是复制的），每个路由器提供一个“本地”密钥服务器。在链接外部传播消息没有问题，因为根据定义，链接本地消息不会被转发。此解决方案仅作为工作如何进展的示例提供；应在该工作组中进行进一步讨论。[RFC4601]中定义了PIM-SM链路本地保护机制的规范，该机制已在PIM-SM-LINKLOCAL[RFC5796]中更新。然而，KMP部分完全未指定，需要PIM工作组专业知识之外的工作才能完成，这是创建此路线图的另一个例子。
It is imperative that the new authentication and security mechanisms defined support incremental deployment, as it is not feasible to deploy a new routing protocol authentication mechanism throughout the network instantaneously. One of the goals of the KARP WG is to add incremental security to existing mechanisms rather than replacing them. Delivering better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. It may also not be possible to deploy such a mechanism to all routers in a large Autonomous System (AS) at one
定义的新身份验证和安全机制必须支持增量部署，因为在整个网络中即时部署新的路由协议身份验证机制是不可行的。KARP工作组的目标之一是为现有机制增加增量安全性，而不是替换它们。提供供应商和运营商可以迁移到的更好的可部署解决方案比获得完美的安全解决方案更重要。也不可能同时将这种机制部署到大型自治系统（AS）中的所有路由器
time. This means that the designers must work on this aspect of the authentication mechanism for the routing protocol on which they are working. The mechanisms must provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment.
时间这意味着设计人员必须为他们正在使用的路由协议处理身份验证机制的这一方面。这些机制必须在消息格式化、传输和处理通过混合安全环境传输的路由信息时提供向后兼容性。
DoS attacks must be kept in mind when designing KARP solutions. [THTS-REQS] describes DoS attacks that are in scope for the KARP work. Protocol designers should ensure that the new cryptographic validation mechanisms must not provide an attacker with an opportunity for DoS attacks. Cryptographic validation, while typically cheaper than signing, is still an incremental cost. If an attacker can force a system to validate many packets multiple times, then this could be a potential DoS attack vector. On the other hand, if the authentication procedure is itself quite CPU intensive, then overwhelming the CPU with multiple bogus packets can bring down the system. In this case, the authentication procedure itself aids the DoS attack.
在设计KARP解决方案时，必须牢记DoS攻击。[THTS-REQS]描述了KARP工作范围内的DoS攻击。协议设计者应确保新的加密验证机制不得为攻击者提供DoS攻击的机会。加密验证虽然通常比签名便宜，但仍然是一种增量成本。如果攻击者可以强制系统多次验证多个包，那么这可能是一个潜在的DoS攻击向量。另一方面，如果身份验证过程本身相当CPU密集，那么用多个伪造数据包覆盖CPU可能会导致系统崩溃。在这种情况下，身份验证过程本身有助于DoS攻击。
There are some known techniques to reduce the cryptographic computation load. Packets can include non-cryptographic consistency checks. For example, [RFC5082] provides a mechanism that uses the IP header to limit the attackers that can inject packets that will be subject to cryptographic validation. In the design, Phase 2, once an automated key management protocol is developed, it may be possible to determine the peer IP addresses that are valid participants. Only the packets from the verified sources could be subject to cryptographic validation.
有一些已知的技术可以减少密码计算负载。数据包可以包括非加密一致性检查。例如，[RFC5082]提供了一种机制，该机制使用IP报头来限制攻击者可以注入将接受加密验证的数据包。在第2阶段的设计中，一旦开发了自动密钥管理协议，就可以确定有效参与者的对等IP地址。只有来自验证源的数据包才能进行加密验证。
Protocol designers must ensure that a device never needs to check incoming protocol packets using multiple keys, as this can overwhelm the CPU, leading to a DoS attack. KARP solutions should indicate the checks that are appropriate prior to performing cryptographic validation. KARP solutions should indicate where information about valid neighbors can be used to limit the scope of the attacks.
协议设计者必须确保设备永远不需要使用多个密钥检查传入的协议数据包，因为这会使CPU无法工作，从而导致DoS攻击。KARP解决方案应在执行加密验证之前指出适当的检查。KARP解决方案应指出有效邻居的信息可用于限制攻击范围的位置。
Particular care needs to be paid to the design of automated key management schemes. It is often desirable to force a party attempting to authenticate to do work and to maintain state until that work is done. That is, the initiator of the authentication should maintain the cost of any state required by the authentication for as long as possible. This also helps when an attacker sends an overwhelming load of keying protocol initiations from bogus sources.
需要特别注意自动密钥管理方案的设计。通常需要强制试图进行身份验证的一方进行工作，并在该工作完成之前保持状态。也就是说，身份验证的发起人应尽可能长时间地维持身份验证所需的任何状态的成本。当攻击者从虚假来源发送大量密钥协议启动时，这也会有所帮助。
Another important class of attack is denial of service against the routing protocol where an attacker can manipulate either the routing protocol or the cryptographic authentication mechanism to disrupt routing adjacencies.
另一类重要的攻击是针对路由协议的拒绝服务攻击，攻击者可以操纵路由协议或加密身份验证机制来破坏路由邻接。
Without KARP solutions, many routing protocols are subject to disruption simply by injecting an invalid packet or a packet for the wrong state. Even with cryptographic validation, replay attacks are often a vector where a previously valid packet can be injected to create a denial of service. KARP solutions should prevent all cases where packet replays or other packet injections by an outsider can disrupt routing sessions.
如果没有KARP解决方案，许多路由协议只需注入无效数据包或错误状态的数据包，就会受到干扰。即使使用加密验证，重播攻击通常也是一种向量，在此向量中可以注入以前有效的数据包以创建拒绝服务。KARP解决方案应防止外部人员的数据包重放或其他数据包注入会中断路由会话的所有情况。
Some residual denial-of-service risk is always likely. If an attacker can generate a large enough number of packets, the routing protocol can get disrupted. Even if the routing protocol is not disrupted, the loss rate on a link may rise to a point where claiming that traffic can successfully be routed across the link will be inaccurate.
一些剩余的拒绝服务风险总是可能的。如果攻击者能够生成足够多的数据包，则路由协议可能会中断。即使路由协议没有中断，链路上的丢失率也可能上升到声称流量可以通过链路成功路由的程度，这是不准确的。
The [THTS-REQS] document lists the generic requirements for the security mechanisms that must exist for the various routing protocols that come under the purview of KARP. There will be different design teams working for each of the categories of routing protocols defined.
[THTS-REQS]文件列出了KARP权限范围内的各种路由协议必须存在的安全机制的一般要求。将有不同的设计团队为定义的每一类路由协议工作。
To start, design teams must review the "Threats and Requirements for Authentication of routing protocols" document [THTS-REQS]. This document contains detailed descriptions of the threat analysis for routing protocol authentication and integrity in general. Note that it does not contain all the authentication-related threats for any one routing protocol, or category of routing protocols. The design team must conduct a protocol-specific threat analysis to determine if threats beyond those in the [THTS-REQS] document arise in the context of the protocol (group) and to describe those threats.
首先，设计团队必须审查“路由协议认证的威胁和要求”文件[THTS-REQS]。本文档详细描述了路由协议身份验证和完整性的威胁分析。请注意，它并不包含任何一种路由协议或路由协议类别的所有与身份验证相关的威胁。设计团队必须进行特定于协议的威胁分析，以确定超出[THTS-REQS]文件中的威胁是否在协议（组）的上下文中出现，并描述这些威胁。
The [THTS-REQS] document also contains many security requirements. Each routing protocol design team must walk through each section of the requirements and determine one by one how its protocol either does or does not relate to each requirement.
[THTS-REQS]文件还包含许多安全要求。每个路由协议设计团队必须遍历需求的每个部分，并逐个确定其协议与每个需求的关系。
Examples include modern, strong, cryptographic algorithms, with at least one such algorithm listed as a MUST, algorithm agility, secure use of simple PSKs, intra-connection replay protection, inter-connection replay protection, etc.
示例包括现代、强大的加密算法，其中至少有一种算法被列为必备算法、算法灵活性、简单PSK的安全使用、连接内重放保护、连接间重放保护等。
When doing the gap analysis, we must first identify the elements of each routing protocol that we wish to protect. In case of protocols riding on top of IP, we might want to protect the IP header and the protocol headers, while for those that work on top of TCP, it will be the TCP header and the protocol payload. There is patently value in protecting the IP header and the TCP header if the routing protocols rely on these headers for some information (for example, identifying the neighbor that originated the packet).
在进行差距分析时，我们必须首先确定我们希望保护的每个路由协议的元素。如果协议位于IP之上，我们可能希望保护IP头和协议头，而对于那些在TCP之上工作的协议，则是TCP头和协议负载。如果路由协议依赖这些报头获取某些信息（例如，识别发起数据包的邻居），那么保护IP报头和TCP报头显然是有价值的。
Then, there will be a set of cryptography requirements that we might want to look at. For example, there must be at least one set of cryptographic algorithms (MD5, SHA, etc.) or constructions (Hashed MAC (HMAC), etc.) whose use is supported by all implementations and can be safely assumed to be supported by any implementation of the authentication option. The design teams should look for the protocol on which they are working. If such algorithms or constructions are not available, then some should be defined to support interoperability by having a single default.
然后，我们可能会考虑一组加密要求。例如，必须至少有一组密码算法（MD5、SHA等）或构造（哈希MAC（HMAC）等），其使用由所有实现支持，并且可以安全地假设由认证选项的任何实现支持。设计团队应该寻找他们正在工作的协议。如果这样的算法或构造不可用，那么应该通过使用一个默认值来定义一些算法或构造以支持互操作性。
Design teams must ensure that the default cryptographic algorithms and constructions supported by the routing protocols are accepted by the community. This means that the protocols must not rely on non-standard or ad hoc hash functions, keyed-hash constructions, signature schemes, or other functions, and they must use published and standard schemes.
设计团队必须确保路由协议支持的默认加密算法和构造为社区所接受。这意味着协议不得依赖于非标准或特殊散列函数、密钥散列构造、签名方案或其他函数，并且必须使用已发布的和标准的方案。
Care should also be taken to ensure that the routing protocol authentication scheme has algorithm agility (i.e., it is capable of supporting algorithms other than its defaults). Ideally, the authentication mechanism should not be affected by packet loss and reordering.
还应注意确保路由协议认证方案具有算法灵活性（即，它能够支持除其默认值以外的算法）。理想情况下，身份验证机制不应受到数据包丢失和重新排序的影响。
Design teams should ensure that their protocol's authentication mechanism is able to accommodate rekeying. This is essential since it is well known that keys must periodically be changed. Also, what the designers must ensure is that this rekeying event should not affect the functioning of the routing protocol. For example, OSPF rekeying requires coordination among the adjacent routers, while IS-IS requires coordination among routers in the entire domain.
设计团队应确保其协议的身份验证机制能够适应密钥更新。这是至关重要的，因为众所周知，密钥必须定期更改。此外，设计者必须确保此密钥更新事件不应影响路由协议的功能。例如，OSPF密钥更新需要相邻路由器之间的协调，而IS-IS需要整个域中路由器之间的协调。
If new authentication and security mechanisms are needed, then the design teams must design in such a manner that the routing protocol authentication mechanism remains oblivious to how the keying material is derived. This decouples the authentication mechanism from the key management system that is employed.
如果需要新的身份验证和安全机制，那么设计团队必须以这样一种方式进行设计，即路由协议身份验证机制仍然不知道密钥材料是如何派生的。这将身份验证机制与所采用的密钥管理系统分离。
Design teams should also note that many routing protocols require prioritized treatment of certain protocol packets and authentication mechanisms should honor this.
设计团队还应注意，许多路由协议需要优先处理某些协议包，身份验证机制应遵守这一点。
Not all routing protocol authentication mechanisms provide support for replay attacks, and the design teams should identify such authentication mechanisms and work on them so that this can get fixed. The design teams must look at the protocols that they are working on and see if packets captured from the previous/stale sessions can be replayed.
并不是所有的路由协议认证机制都支持重播攻击，设计团队应该识别此类认证机制并对其进行处理，以便修复这一问题。设计团队必须查看他们正在处理的协议，并查看是否可以重放从以前/过时会话捕获的数据包。
What might also influence the design is the rate at which the protocol packets are originated. In case of protocols like BFD, where packets are originated at millisecond intervals, there are some special considerations that must be kept in mind when defining the new authentication and security mechanisms.
还可能影响设计的是协议数据包的发起速率。在像BFD这样的协议中，数据包以毫秒为间隔发起，在定义新的身份验证和安全机制时，必须记住一些特殊的注意事项。
The designers should also consider whether the current authentication mechanisms impose considerable processing overhead on a router that's doing authentication. Most currently deployed routers do not have hardware accelerators for cryptographic processing and these operations can impose a significant processing burden under some circumstances. The proposed solutions should be evaluated carefully with regard to the processing burden that they will impose, since deployment may be impeded if network operators perceive that a solution will impose a processing burden which either entails substantial capital expenses or threatens to destabilize the routers.
设计者还应该考虑当前的认证机制是否对正在进行身份验证的路由器施加相当大的处理开销。大多数当前部署的路由器没有用于加密处理的硬件加速器，在某些情况下，这些操作可能会造成巨大的处理负担。应仔细评估提议的解决方案将带来的处理负担，因为如果网络运营商认为解决方案将带来处理负担，这将导致大量资本支出或可能破坏路由器的稳定，那么部署可能会受到阻碍。
As mentioned in the Introduction, RFC 4948 [RFC4948] identifies additional steps needed to achieve the overall goal of improving the security of the core routing infrastructure. Those include validation of route origin announcements, path validation, cleaning up the IRR databases for accuracy, and operational security practices that prevent routers from becoming compromised devices. The KARP work is but one step needed to improve core routing infrastructure.
如引言中所述，RFC 4948[RFC4948]确定了实现提高核心路由基础设施安全性的总体目标所需的其他步骤。这些包括验证路由来源公告、路径验证、清理IRR数据库以确保准确性，以及防止路由器成为受损设备的操作安全实践。KARP工作只是改进核心路由基础设施所需的一步。
The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
基于密码的系统的安全性取决于所选密码算法的强度以及与这些算法一起使用的密钥的强度。安全性还取决于系统使用的协议工程，以确保没有非加密方式绕过整个系统的安全性。
Care should be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.
应注意确保所选密钥是不可预测的，避免任何已知对所用算法较弱的密钥。[RFC4086]包含有关密钥生成技术和密码随机性的有用信息。
Care should also be taken when choosing the length of the key. [RFC3766] provides some additional information on asymmetric and symmetric key sizes and how they relate to system requirements for attack resistance.
选择钥匙的长度时也应小心。[RFC3766]提供了一些关于非对称和对称密钥大小的附加信息，以及它们与系统抗攻击要求的关系。
In addition to using a key of appropriate length and randomness, deployers of KARP should use different keys between different routing peers whenever operationally possible. This is especially true when the routing protocol takes a static traffic key as opposed to a traffic key derived on a per-connection basis using a KDF. The burden for doing so is understandably much higher than using the same static traffic key across all peering routers. Depending upon the specific KMP, it can be argued that generally using a KMP network-wide increases peer-wise security. Consider an attacker that learns or guesses the traffic key used by two peer routers: if the traffic key is only used between those two routers, then the attacker has only compromised that one connection not the entire network.
除了使用适当长度和随机性的密钥外，KARP部署人员还应尽可能在不同的路由节点之间使用不同的密钥。当路由协议采用静态流量密钥而不是使用KDF基于每个连接派生的流量密钥时，尤其如此。这样做的负担比在所有对等路由器上使用相同的静态流量密钥要高得多，这是可以理解的。根据特定的KMP，可以认为，通常在网络范围内使用KMP会提高对等安全性。考虑攻击者学习或猜测由两个对等路由器使用的业务密钥：如果业务密钥仅在这两个路由器之间使用，那么攻击者只会破坏一个连接而不是整个网络。
However whenever using manual keys, it is best to design a system where a given pre-shared key (PSK) will be used in a KDF mixed with connection-specific material, in order to generate session unique -- and therefore peer-wise -- traffic keys. Doing so has the following advantages: the traffic keys used in the per-message authentication mechanism are peer-wise unique, it provides inter-connection replay protection, and if the per-message authentication mechanism covers some connection counter, intra-connection replay protection.
但是，无论何时使用手动密钥，最好设计一个系统，在该系统中，给定的预共享密钥（PSK）将在KDF中与特定于连接的材料混合使用，以便生成会话唯一的（因此是对等的）通信密钥。这样做具有以下优点：每条消息身份验证机制中使用的流量密钥是对等唯一的，它提供连接间重放保护，如果每条消息身份验证机制覆盖某些连接计数器，则提供连接内重放保护。
Note that certain key derivation functions (e.g., KDF_AES_128_CMAC) as used in TCP-AO [RFC5926], the pseudorandom function (PRF) used in the KDF may require a key of a certain fixed size as an input.
注意，在TCP-AO[RFC5926]中使用的某些密钥派生函数（例如，KDF_AES_128_CMAC），在KDF中使用的伪随机函数（PRF）可能需要具有特定固定大小的密钥作为输入。
For example, AES_128_CMAC requires a 128-bit (16-byte) key as the seed. However, for the convenience of the administrators, a specification may not want to require the entry of a PSK be of exactly 16 bytes. Instead, a specification may call for a key prep routine that could handle a variable-length PSK, one that might be less or more than 16 bytes (see [RFC4615], Section 3, as an example). That key prep routine would derive a key of exactly the required length, thus, be suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-800-118]. We simply attempted
例如，AES_128_CMAC需要128位（16字节）密钥作为种子。但是，为了方便管理员，规范可能不希望要求输入的PSK正好为16字节。相反，规范可能会调用密钥准备例程，该例程可以处理可变长度的PSK，该PSK可能小于或大于16字节（例如，请参见[RFC4615]，第3节）。该密钥准备程序将导出一个恰好符合所需长度的密钥，因此，该密钥适合作为PRF的种子。这并不意味着管理员可以安全地使用弱密钥。鼓励管理员遵循[RFC4086][NIST-800-118]。我们只是试图
to "put a fence around stupidity", as much as possible as it's hard to imagine administrators putting in a password that is, say 16 bytes in length.
尽可能地“在愚蠢周围设置围栏”，因为很难想象管理员会输入一个长度为16字节的密码。
A better option, from a security perspective, is to use some representation of a device-specific asymmetric key pair as the identity proof, as described in section "Unique versus Shared Keys" section.
从安全角度来看，更好的选择是使用特定于设备的非对称密钥对的某种表示作为身份证明，如“唯一密钥与共享密钥”一节所述。
Design teams must consider whether the protocol is an internal routing protocol or an external one, i.e., does it primarily run between peers within a single domain of control or between two different domains of control? Some protocols may be used in both cases, internally and externally, and as such, various modes of authentication operation may be required for the same protocol. While it is preferred that all routing exchanges run with the best security mechanisms enabled in all deployment contexts, this exhortation is greater for those protocols running on inter-domain point-to-point links. It is greatest for those on shared access link layers with several different domains interchanging together, because the volume of attackers are greater from the outside. Note however, that the consequences of internal attacks maybe no less severe -- in fact, they may be quite a bit more severe -- than an external attack. An example of this internal versus external consideration is BGP, which has both EBGP and IBGP modes. Another example is a multicast protocol where the neighbors are sometimes within a domain of control and sometimes at an inter-domain exchange point. In the case of PIM-SM running on an internal multi-access link, it would be acceptable to give up some security to get some convenience by using a group key among the peers on the link. On the other hand, in the case of PIM-SM running over a multi-access link at a public exchange point, operators may favor security over convenience by using unique pair-wise keys for every peer. Designers must consider both modes of operation and ensure the authentication mechanisms fit both.
设计团队必须考虑协议是内部路由协议还是外部路由协议，即，它主要是在单个控制域内的节点之间还是在两个不同的控制域之间运行？某些协议可在内部和外部两种情况下使用，因此，同一协议可能需要各种认证操作模式。虽然所有路由交换最好在所有部署上下文中启用最佳安全机制，但对于那些在域间点到点链路上运行的协议，这一告诫更为重要。这对于那些在共享访问链路层上，几个不同的域相互交换在一起的人来说是最好的，因为攻击者的数量来自外部。但是请注意，内部攻击的后果可能不会比外部攻击更严重——事实上，它们可能更严重。这种内部对外部考虑的一个例子是BGP，它同时具有EBGP和IBGP模式。另一个例子是多播协议，其中邻居有时在控制域内，有时在域间交换点。在PIM-SM在内部多址链路上运行的情况下，可以通过在链路上的对等方之间使用组密钥来放弃一些安全性以获得一些便利。另一方面，在PIM-SM通过公共交换点的多址链路运行的情况下，运营商可能会通过为每个对等方使用唯一的成对密钥来支持安全性而不是方便性。设计者必须考虑这两种操作模式，并确保认证机制适合两者。
Operators are encouraged to run cryptographic authentication on all their adjacencies, but to work from the outside in, i.e., External BGP (EBGP) links are a higher priority than the Internal BGP (IBGP) links because they are externally facing, and, as a result, more likely to be targeted in an attack.
鼓励运营商在其所有邻接处运行加密身份验证，但从外向内工作，即，外部BGP（EBGP）链路的优先级高于内部BGP（IBGP）链路，因为它们面向外部，因此更可能成为攻击的目标。
This section discusses security considerations regarding when it is appropriate to use the same authentication key inputs for multiple peers and when it is not. This is largely a debate of convenience
本节讨论关于何时适合对多个对等方使用相同的身份验证密钥输入以及何时不适合的安全注意事项。这在很大程度上是一场关于便利的辩论
versus security. It is often the case that the best secured mechanism is also the least convenient mechanism. For example, an air gap between a host and the network absolutely prevents remote attacks on the host, but having to copy and carry files using the "sneaker net" is quite inconvenient and does not scale.
对安全。通常情况下，最好的安全机制也是最不方便的机制。例如，主机和网络之间的气隙绝对可以防止对主机的远程攻击，但必须使用“运动鞋网络”复制和携带文件非常不方便，并且无法扩展。
Operators have erred on the side of convenience when it comes to securing routing protocols with cryptographic authentication. Many do not use it at all. Some use it only on external links, but not on internal links. Those that do use it often use the same key for all peers in a network. It is common to see the same key in use for years, e.g., the key was entered when authentication mechanisms were originally configured or when the routing gear was deployed.
当涉及到使用加密身份验证保护路由协议时，运营商在方便性方面犯了错误。许多人根本不使用它。有些人只在外部链接上使用它，而不在内部链接上使用它。那些使用它的人通常对网络中的所有对等方使用相同的密钥。常见的情况是，同一密钥已使用多年，例如，该密钥是在最初配置身份验证机制或部署路由设备时输入的。
One goal for designers is to create authentication and integrity mechanisms that are easy for operators to deploy and manage, and still use unique keys between peers (or small groups on multi-access links) and for different sessions among the same peers. Operators have the impression that they NEED one key shared across the network, when, in fact, they do not. What they need is the relative convenience they experience from deploying cryptographic authentication with one key (or a few keys) compared to the inconvenience they would experience if they deployed the same authentication mechanism using unique pair-wise keys. An example is BGP route reflectors. Here, operators often use the same authentication key between each client and the route reflector. The roadmaps defined from this guidance document should allow for unique keys to be used between each client and the peer, without sacrificing much convenience. Designers should strive to deliver peer-wise unique keying mechanisms with similar ease-of-deployment properties as today's one-key method.
设计人员的一个目标是创建身份验证和完整性机制，以便于运营商部署和管理，并且在对等点（或多访问链路上的小组）之间以及相同对等点之间的不同会话中仍然使用唯一密钥。运营商给人的印象是，他们需要在网络上共享一个密钥，而事实上他们并不需要。他们需要的是使用一个密钥（或几个密钥）部署加密身份验证所带来的相对便利，而不是使用唯一的成对密钥部署相同身份验证机制所带来的不便。BGP路由反射器就是一个例子。在这里，运营商通常在每个客户端和路由反射器之间使用相同的身份验证密钥。本指导文件中定义的路线图应允许在每个客户机和对等机之间使用唯一的密钥，而不会牺牲很多便利性。设计者应该努力提供对等的独特键控机制，其部署特性与当今的一键方法类似。
Operators must understand the consequences of using the same key across many peers. One argument against using the same key is that if the same key that is used in multiple devices, then a compromise of any one of the devices will expose the key. Also, since the same key is supported on many devices, this is known by many people, which affects its distribution to all of the devices.
操作员必须了解在多个对等方中使用相同密钥的后果。反对使用同一密钥的一个论点是，如果在多个设备中使用同一密钥，则任何一个设备的妥协都会暴露该密钥。此外，由于许多设备支持相同的密钥，因此许多人都知道这一点，这会影响其在所有设备上的分发。
Consider also the attack consequence size, the amount of routing adjacencies that can be negatively affected once a breach has occurred, i.e., once the keys have been acquired by the attacker.
还考虑攻击后果大小，一旦发生违反，即一旦攻击者获得密钥，就会受到负面影响的路由邻接量。
Again, if a shared key is used across the internal domain, then the consequence size is the whole network. Ideally, unique key pairs would be used for each adjacency.
同样，如果在内部域中使用共享密钥，那么结果大小就是整个网络。理想情况下，每个邻接将使用唯一的密钥对。
In some cases, use of shared keys is needed because of the problem space. For example, a multicast packet is sent once but then consumed by several routing neighbors. If unique keys were used per neighbor, the benefit of multicast would be erased because the sender would have to create a different announcement packet for each receiver. Though this may be desired and acceptable in some small number of use cases, it is not the norm. Shared (i.e., group) keys are an acceptable solution here, and much work has been done already in this area (by the MSEC working group).
在某些情况下，由于问题空间，需要使用共享密钥。例如，一个多播数据包发送一次，但随后被几个路由邻居使用。如果每个邻居使用唯一的密钥，则多播的好处将被抹去，因为发送方必须为每个接收方创建不同的公告包。虽然这在一些小的用例中可能是期望的和可接受的，但它不是标准。共享（即组）密钥在这里是一个可接受的解决方案，并且在这方面已经做了很多工作（由MSEC工作组）。
This section discusses the security and use case considerations for key exchange for routing protocols. Two options exist: an out-of-band mechanism or a KMP. An out-of-band mechanism involves operators configuring keys in the device through a configuration tool or management method (e.g., Simple Network Management Protocol (SNMP), Network Configuration Protocol (NETCONF)). A KMP is an automated protocol that exchanges keys without operator intervention. KMPs can occur either in-band to the routing protocol or out-of-band to the routing protocol (i.e., a different protocol).
本节讨论路由协议密钥交换的安全性和用例注意事项。存在两种选择：带外机制或KMP。带外机制涉及操作员通过配置工具或管理方法（例如，简单网络管理协议（SNMP）、网络配置协议（NETCONF））配置设备中的密钥。KMP是一种自动协议，无需操作员干预即可交换密钥。KMP可以发生在路由协议的带内，也可以发生在路由协议的带外（即，不同的协议）。
An example of an out-of-band configuration mechanism could be an administrator who makes a remote management connection (e.g., using SSH) to a router and manually enters the keying information, e.g., the algorithm, the key(s), the key lifetimes, etc. Another example could be an OSS system that inputs the same information by using a script over an SSH connection or by pushing configuration through some other management connection, standard (NETCONF-based) or proprietary.
带外配置机制的一个示例可以是管理员，他与路由器建立远程管理连接（例如，使用SSH），并手动输入密钥信息，例如，算法、密钥、密钥寿命，另一个例子可能是OSS系统，它通过SSH连接使用脚本或通过其他管理连接（标准（基于NETCONF）或专有）推送配置来输入相同的信息。
The drawbacks of an out-of-band configuration mechanism include lack of scalability, complexity, and speed of changing if a security breach is suspected. For example, if an employee who had access to keys was terminated, or if a machine holding those keys was believed to be compromised, then the system would be considered insecure and vulnerable until new keys were generated and distributed. Those keys then need to be placed into the OSS system, and the OSS system then needs to push the new keys -- often during a very limited change window -- into the relevant devices. If there are multiple organizations involved in these connections, because the protected connections are inter-domain, this process is very complicated.
带外配置机制的缺点包括缺乏可伸缩性、复杂性，以及在怀疑存在安全漏洞时更改的速度。例如，如果有权访问密钥的员工被终止，或者如果持有这些密钥的机器被认为受到威胁，那么在生成和分发新密钥之前，系统将被视为不安全和易受攻击。然后需要将这些密钥放入OSS系统，然后OSS系统需要将新密钥（通常在非常有限的更改窗口中）推入相关设备。如果这些连接涉及多个组织，因为受保护的连接是域间的，那么这个过程非常复杂。
The principle benefit of out-of-band configuration mechanism is that once the new keys/parameters are set in OSS system, they can be pushed automatically to all devices within the OSS's domain.
带外配置机制的主要好处是，一旦在OSS系统中设置了新的密钥/参数，就可以自动推送到OSS域内的所有设备上。
Operators have mechanisms in place for this already for managing other router configuration data. In small environments with few routers, a manual system is not difficult to employ.
运营商已经有了相应的机制来管理其他路由器配置数据。在路由器很少的小型环境中，使用手动系统并不困难。
We further define a peer-to-peer KMP as using cryptographically protected identity verification, session key negotiation, and security association parameter negotiation between the two routing peers. The KMP among peers may also include the negotiation of parameters, like cryptographic algorithms, cryptographic inputs (e.g., initialization vectors), key lifetimes, etc.
我们进一步将对等KMP定义为使用加密保护的身份验证、会话密钥协商和两个路由对等方之间的安全关联参数协商。对等方之间的KMP还可以包括参数的协商，例如密码算法、密码输入（例如，初始化向量）、密钥寿命等。
There are several benefits of a peer-to-peer KMP versus centrally managed and distributing keys. It results in key(s) that are privately generated, and it need not be recorded permanently anywhere. Since the traffic keys used in a particular connection are not a fixed part of a device configuration, no security sensitive data exists anywhere else in the operator's systems that can be stolen, e.g., in the case of a terminated or turned employee. If a server or other data store is stolen or compromised, the thieves gain limited or no access to current traffic keys. They may gain access to key derivation material, like a PSK, but may not be able to access the current traffic keys in use. In this example, these PSKs can be updated in the device configurations (either manually or through an OSS) without bouncing or impacting the existing session at all. In the case of using raw asymmetric keys or certificates, instead of PSKs, the data theft (from the data store) would likely not result in any compromise, as the key pairs would have been generated on the routers and never leave those routers. In such a case, no changes are needed on the routers; the connections will continue to be secure, uncompromised. Additionally, with a KMP, regular rekey operations occur without any operator involvement or oversight. This keeps keys fresh.
与集中管理和分发密钥相比，对等KMP有几个好处。它会产生私人生成的密钥，并且不需要在任何地方永久记录。由于在特定连接中使用的通信密钥不是设备配置的固定部分，因此在运营商系统中的任何其他地方都不存在可能被盗的安全敏感数据，例如，在终止或转职员工的情况下。如果服务器或其他数据存储被盗或受损，盗贼将获得有限或无法访问当前交通密钥的权限。他们可以访问密钥派生材料，如PSK，但可能无法访问当前使用的流量密钥。在本例中，这些PSK可以在设备配置中更新（手动或通过OSS），而不会反弹或影响现有会话。在使用原始非对称密钥或证书而不是PSK的情况下，数据盗窃（来自数据存储）可能不会导致任何危害，因为密钥对将在路由器上生成，并且永远不会离开这些路由器。在这种情况下，不需要对路由器进行任何更改；连接将继续保持安全、不妥协。此外，对于KMP，定期进行重新钥匙操作，无需任何操作员参与或监督。这使钥匙保持新鲜。
There are a few drawbacks to using a KMP. First, a KMP requires more cryptographic processing for the router at the beginning of a connection. This will add some minor start-up time to connection establishment versus a purely manual key management approach. Once a connection with traffic keys has been established via a KMP, the performance is the same in the KMP and the out-of-band configuration case. KMPs also add another layer of protocol and configuration complexity, which can fail or be misconfigured. This was more of an issue when these KMPs were first deployed, but less so as these implementations and operational experience with them have matured.
使用KMP有一些缺点。首先，KMP需要在连接开始时对路由器进行更多的加密处理。与纯手动密钥管理方法相比，这将为连接建立增加一些较小的启动时间。一旦通过KMP建立了与流量密钥的连接，KMP和带外配置情况下的性能相同。KMP还增加了另一层协议和配置复杂性，这可能会导致失败或配置错误。当这些KMP首次部署时，这是一个更大的问题，但随着这些实现和操作经验的成熟，问题就不那么严重了。
One of the goals for KARP is to develop a KMP; an out-of-band configuration protocol for key exchange is out of scope.
KARP的目标之一是发展KMP；密钥交换的带外配置协议超出范围。
Within this constraint, there are two approaches for a KMP:
在此约束条件下，KMP有两种方法：
The first is to use a KMP that runs independent of the routing and the signaling protocols. It would run on its own port and use its own transport (to avoid interfering with the routing protocol that it is serving). When a routing protocol needs a key, it would contact the local instance of this key management protocol and request a key. The KMP generates a key that is delivered to the routing protocol for it to use for authenticating and integrity verification of the routing protocol packets. This KMP could either be an existing key management protocol such as ISAKMP/IKE, GKMP, etc., extended for the routing protocols, or it could be a new KMP, designed for the routing protocol context.
第一种是使用独立于路由和信令协议运行的KMP。它将在自己的端口上运行并使用自己的传输（以避免干扰它所服务的路由协议）。当路由协议需要密钥时，它将联系该密钥管理协议的本地实例并请求密钥。KMP生成一个密钥，该密钥被传递到路由协议，供其用于对路由协议数据包进行身份验证和完整性验证。该KMP可以是为路由协议扩展的现有密钥管理协议，如ISAKMP/IKE、GKPP等，也可以是为路由协议上下文设计的新KMP。
The second approach is to define an in-band KMP extension for existing routing protocols putting the key management mechanisms inside the protocol itself. In this case, the key management messages would be carried within the routing protocol packets, resulting in very tight coupling between the routing protocols and the key management protocol.
第二种方法是为现有路由协议定义带内KMP扩展，将密钥管理机制放入协议本身。在这种情况下，密钥管理消息将在路由协议分组中携带，从而导致路由协议和密钥管理协议之间的紧密耦合。
Much of the text for this document came originally from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz.
本文档的大部分文本最初来自Gregory M.Lebovitz编写的“在线路由协议包加密认证路线图”。
We would like to thank Sam Hartman, Eric Rescorla, Russ White, Sean Turner, Stephen Kent, Stephen Farrell, Adrian Farrel, Russ Housley, Michael Barnes, and Vishwas Manral for their comments on the document.
我们要感谢萨姆·哈特曼、埃里克·雷斯科拉、罗斯·怀特、肖恩·特纳、斯蒂芬·肯特、斯蒂芬·法雷尔、阿德里安·法雷尔、罗斯·霍斯利、迈克尔·巴恩斯和维斯瓦斯·曼拉尔对该文件的评论。
[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月。
[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月。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[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月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[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月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[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月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，2006年5月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (- AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4615]Song，J.，Poovendran，R.，Lee，J.，和T.Iwata，“互联网密钥交换协议（IKE）的基于密码的消息认证码伪随机函数128（-AES-CMAC-PRF-128）算法的高级加密标准”，RFC 4615，2006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[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月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[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., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5796]Atwood，W.，Islam，S.，和M.Siami，“协议独立多播稀疏模式（PIM-SM）链路本地消息中的身份验证和机密性”，RFC 57962010年3月。
[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月。
[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月。
[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月。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6407]Weis，B.，Rowles，S.，和T.Hardjono，“解释的集团领域”，RFC 6407，2011年10月。
[THTS-REQS] Lebovitz, G., "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", Work in Progress, June 2011.
[THTS-REQS]Lebovitz，G.，“路由协议传输的加密认证的威胁分析和要求”，正在进行的工作，2011年6月。
[CRPT-TAB] Housley, R. and Polk, T., "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2011
[CRPT-TAB]Housley，R.和Polk，T.，“长寿命对称加密密钥数据库”，正在进行的工作，2011年10月
[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
[GDOI-MAC]Weis，B.和S.Rowles，“GDOI通用消息认证代码策略”，正在进行的工作，2011年9月。
[IRR] Merit Network Inc , "Internet Routing Registry Routing Assets Database", 2006, http://www.irr.net/.
[IRR]美德网络公司，“互联网路由注册路由资产数据库”，2006年，http://www.irr.net/.
[NIST-800-57] US National Institute of Standards & Technology, "Recommendation for Key Management Part 1: General (Revised)", March 2007
[NIST-800-57]美国国家标准与技术研究所，“关键管理建议第1部分：概述（修订）”，2007年3月
[NIST-800-118] US National Institute of Standards & Technology, "Guide to Enterprise Password Management (Draft)", April 2009
[NIST-800-118]美国国家标准与技术研究所，“企业密码管理指南（草案）”，2009年4月
Authors' Addresses
作者地址
Gregory M. Lebovitz Aptos, California USA 95003
Gregory M.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