Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7211 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co. Ltd.
June 2014
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7211 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co. Ltd.
June 2014
Operations Model for Router Keying
路由器密钥操作模型
Abstract
摘要
The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.
IETF致力于根据RFC 6518“路由协议的键控和认证（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/rfc7211.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7211.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Breakdown of KARP Configuration . . . . . . . . . . . . . . . 3
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . 5
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 5
3.3. Interactions with Automated Key Management . . . . . . . 6
3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 6
4. Credentials and Authorization . . . . . . . . . . . . . . . . 6
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 9
4.1.2. Key Separation and Protocol Design . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 10
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The Role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 12
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 14
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Breakdown of KARP Configuration . . . . . . . . . . . . . . . 3
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . 5
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 5
3.3. Interactions with Automated Key Management . . . . . . . 6
3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 6
4. Credentials and Authorization . . . . . . . . . . . . . . . . 6
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 9
4.1.2. Key Separation and Protocol Design . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 10
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The Role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 12
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 14
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
The Keying and Authentication of Routing Protocols (KARP) working group is designing improvements to the cryptographic authentication of IETF routing protocols. These improvements include enhancing how integrity functions are handled within each protocol as well as designing an automated key management solution.
路由协议的密钥和认证（KARP）工作组正在设计改进IETF路由协议的密码认证。这些改进包括增强在每个协议中处理完整性功能的方式，以及设计自动化密钥管理解决方案。
This document discusses issues to consider when thinking about the operational and management model for KARP. Each implementation will take its own approach to management; this is one area for vendor differentiation. However, it is desirable to have a common baseline for the management objects allowing administrators, security architects, and protocol designers to understand what management capabilities they can depend on in heterogeneous environments. Similarly, designing and deploying the protocol will be easier when thought is paid to a common operational model. This will also help with the design of NETCONF schemas or MIBs later. This document provides recommendations to help establish such a baseline.
本文讨论了在考虑卡普的运营和管理模式时要考虑的问题。每项实施都将采用自己的管理方法；这是供应商差异化的一个领域。但是，希望为管理对象提供一个通用的基线，使管理员、安全架构师和协议设计者能够了解他们在异构环境中可以依赖哪些管理功能。同样，当考虑到一个通用的操作模型时，设计和部署协议将更容易。这也将有助于以后设计NETCONF模式或mib。本文件提供了帮助建立此类基线的建议。
This document also gives recommendations for how management and operational issues can be approached as protocols are revised and as support is added for the key table [RFC7210].
本文件还就修订协议和增加对键表的支持[RFC7210]时如何处理管理和运营问题提出了建议。
Routing security faces interesting challenges not present with some other security domains. Routers need to function in order to establish network connectivity. As a result, centralized services cannot typically be used for authentication or other security tasks; see Section 4.4. In addition, routers' roles affect how new routers are installed and how problems are handled; see Section 6.
路由安全面临着一些其他安全域所没有的有趣挑战。路由器需要运行以建立网络连接。因此，集中式服务通常不能用于身份验证或其他安全任务；见第4.4节。此外，路由器的角色影响新路由器的安装方式和问题的处理方式；见第6节。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Routing authentication configuration includes configuration of key material used to authenticate routers as well as parameters needed to use these keys. Configuration also includes information necessary to use an automated key management protocol to configure router keying. The key table [RFC7210] describes configuration needed for manual keying. Configuration of automated key management is a work in progress.
路由验证配置包括用于验证路由器的密钥材料的配置以及使用这些密钥所需的参数。配置还包括使用自动密钥管理协议配置路由器密钥所需的信息。键表[RFC7210]描述了手动键控所需的配置。自动密钥管理的配置正在进行中。
There are multiple ways of structuring configuration information. One factor to consider is the scope of the configuration information. Several protocols are peer-to-peer routing protocols where a different key could potentially be used for each neighbor. Other protocols require that the same group key be used for all nodes in an administrative domain or routing area. In other cases, the same group key needs to be used for all routers on an interface, but different group keys can be used for each interface.
构造配置信息有多种方式。要考虑的一个因素是配置信息的范围。有几种协议是对等路由协议，其中每个邻居可能使用不同的密钥。其他协议要求对管理域或路由区域中的所有节点使用相同的组密钥。在其他情况下，一个接口上的所有路由器都需要使用相同的组密钥，但每个接口可以使用不同的组密钥。
Within situations where a per-interface, per-area, or per-peer key can be used for manually configured long-term keys, that flexibility may not be desirable from an operational standpoint. For example, consider OSPF [RFC2328]. Each router on an OSPF link needs to use the same authentication configuration, including the set of keys used for reception and the set of keys used for transmission, but it may use different keys for different links. The most general management model would be to configure keys per link. However, for deployments where the area uses the same key, it would be strongly desirable to configure the key as a property of the area. If the keys are configured per link, they can get out of sync. In order to support generality of configuration and common operational situations, it would be desirable to have some sort of inheritance where default configurations are made per area unless overridden per interface.
在每个接口、每个区域或每个对等密钥可用于手动配置的长期密钥的情况下，从操作角度来看，这种灵活性可能并不理想。例如，考虑OSPF[RFC2228 ]。OSPF链路上的每个路由器都需要使用相同的身份验证配置，包括用于接收的密钥集和用于传输的密钥集，但它可以为不同的链路使用不同的密钥。最通用的管理模型是为每个链接配置密钥。但是，对于区域使用相同密钥的部署，强烈希望将密钥配置为区域的属性。如果每个链接配置了密钥，它们可能会失去同步。为了支持配置的通用性和常见操作情况，最好有某种继承，其中默认配置是按区域进行的，除非按接口重写。
As described in [RFC7210], the cryptographic keys are separated from the interface configuration into their own configuration store. Each routing protocol is responsible for defining the form of the peer specification used by that protocol. Thus, each routing protocol needs to define the scope of keys. For group keying, the peer specification names the group. A protocol could define a peer specification indicating the key had a link scope and also a peer specification for scoping a key to a specific area. For link-scoped keys, it is generally best to define a single peer specification indicating the key has a link scope and to use interface restrictions to restrict the key to the appropriate link.
如[RFC7210]中所述，加密密钥从接口配置中分离到它们自己的配置存储中。每个路由协议负责定义该协议使用的对等规范的形式。因此，每个路由协议都需要定义密钥的范围。对于组键控，对等规范命名组。协议可以定义一个对等规范，指示密钥具有链接作用域，还可以定义一个对等规范，用于将密钥限定到特定区域。对于链接范围的键，通常最好定义一个指示键具有链接范围的对等规范，并使用接口限制将键限制到适当的链接。
Operational Requirements: implementations of this model MUST support configuration of keys at the most general scope for the underlying protocol; protocols supporting per-peer keys MUST permit configuration of per-peer keys, protocols supporting per-interface keys MUST support configuration of per-interface keys, and so on for any additional scopes. Implementations MUST NOT permit configuration of an inappropriate key scope. For example, configuration of separate keys per interface would be inappropriate to support for a protocol requiring per-area keys. This restriction can be enforced by rules specified by each routing protocol for validating key table
操作要求：此模型的实现必须支持在底层协议的最一般范围内配置密钥；支持每对等密钥的协议必须允许配置每对等密钥，支持每接口密钥的协议必须支持配置每接口密钥，依此类推。实现不得允许配置不适当的密钥作用域。例如，每个接口单独配置密钥不适合支持需要每个区域密钥的协议。此限制可以由每个路由协议指定的用于验证密钥表的规则强制实施
entries. As such, these implementation requirements are best addressed by care being taken in how routing protocols specify the use of the key tables.
条目。因此，这些实现需求最好通过注意路由协议如何指定密钥表的使用来解决。
The routing key table [RFC7210] provides a very general mechanism to abstract the storage of keys for routing protocols. To avoid misconfiguration and simplify problem determination, the router MUST verify the internal consistency of entries added to the table. Routing protocols describe how their protocol interacts with the key table including what validation MUST be performed. At a minimum, the router MUST verify:
路由密钥表[RFC7210]提供了一种非常通用的机制来抽象路由协议密钥的存储。为了避免错误配置和简化问题确定，路由器必须验证添加到表中的条目的内部一致性。路由协议描述其协议如何与密钥表交互，包括必须执行的验证。路由器至少必须验证：
o The cryptographic algorithms are valid for the protocol.
o 加密算法对协议有效。
o The key derivation function is valid for the protocol.
o 密钥派生函数对协议有效。
o The direction is valid for the protocol. For example, if a protocol requires the same session key be used in both directions, the direction field in the key table entry associated with the session key MUST be specified as "both".
o 该方向对协议有效。例如，如果协议要求在两个方向上使用相同的会话密钥，则与会话密钥相关联的密钥表条目中的方向字段必须指定为“两者”。
o The peer specification is consistent with the protocol.
o 对等规范与协议一致。
Other checks are possible. For example, the router could verify that if a key is associated with a peer, that peer is a configured peer for the specified protocol. However, this may be undesirable. It may be desirable to load a key table when some peers have not yet been configured. Also, it may be desirable to share portions of a key table across devices even when their current configuration does not require an adjacency with a particular peer in the interest of uniform configuration or preparing for fail-over. For these reasons, these additional checks are generally undesirable.
可以进行其他检查。例如，路由器可以验证，如果一个密钥与一个对等方关联，那么该对等方就是指定协议的配置对等方。然而，这可能是不可取的。当一些对等点尚未配置时，可能需要加载密钥表。此外，即使在设备的当前配置不需要为了统一配置或准备故障转移而与特定对等方相邻时，也可能希望在设备之间共享密钥表的部分。由于这些原因，这些附加检查通常是不可取的。
Several management interfaces will be quite common. For service provider deployments, the configuration management system can simply update the key table. However, for smaller deployments, efficient management interfaces that do not require a configuration management system are important. In these environments, configuration interfaces (such as web interfaces and command-line interfaces) provided directly by the router will be important for easy management of the router.
几个管理界面将非常常见。对于服务提供商部署，配置管理系统可以简单地更新密钥表。但是，对于较小的部署，不需要配置管理系统的高效管理界面非常重要。在这些环境中，路由器直接提供的配置接口（如web接口和命令行接口）对于路由器的轻松管理非常重要。
As part of adding a new key, it is typically desirable to set an expiration time for an old key. The management interface SHOULD provide a mechanism to easily update the expiration time for a current key used with a given peer or interface. Also, when adding a key, it is desirable to push the key out to nodes that will need it, allowing use for receiving packets and then later for enabling transmit. This can be accomplished automatically by providing a delay between when a key becomes valid for reception and transmission. However, some environments may not be able to predict when all the necessary changes will be made. In these cases, having a mechanism to enable a key for sending is desirable. The management interface SHOULD provide an easy mechanism to update the direction of an existing key or to enable a disabled key.
作为添加新密钥的一部分，通常需要为旧密钥设置过期时间。管理接口应提供一种机制，以便轻松更新与给定对等方或接口一起使用的当前密钥的过期时间。此外，当添加密钥时，希望将密钥推出到需要它的节点，允许用于接收数据包，然后稍后用于启用传输。这可以通过在钥匙有效接收和传输之间提供延迟来自动完成。但是，有些环境可能无法预测何时会进行所有必要的更改。在这些情况下，需要有一种机制来启用用于发送的密钥。管理界面应提供一种简单的机制来更新现有密钥的方向或启用禁用的密钥。
Implementations SHOULD permit a configuration in which if no unexpired key is available, existing security associations continue using the expired key with which they were established. Implementations MUST support a configuration in which security associations fail if no unexpired key is available for them. See Section 6.2 for a discussion of reporting and managing security faults including those related to key expiration.
实现应该允许一种配置，在这种配置中，如果没有未过期的密钥可用，现有的安全关联将继续使用建立它们的过期密钥。实现必须支持这样一种配置：如果没有可用的未过期密钥，则安全关联将失败。有关报告和管理安全故障（包括与密钥过期相关的故障）的讨论，请参见第6.2节。
Consideration is required for how an automated key management protocol will assign key IDs for group keys. All members of the group may need to use the same key ID. This requires careful coordination of global key IDs. Interactions with the peer key ID field may make this easier; this requires additional study.
需要考虑自动密钥管理协议如何为组密钥分配密钥ID。组的所有成员可能需要使用相同的密钥ID。这需要仔细协调全局密钥ID。与对等密钥ID字段的交互可能使这更容易；这需要额外的研究。
Automated key management protocols also assign keys for single peers. If the key ID is global and needs to be coordinated between the receiver and transmitter, then there is complexity in key management protocols that can be avoided if key IDs are not global.
自动密钥管理协议还为单个对等方分配密钥。如果密钥ID是全局的，并且需要在接收器和发送器之间进行协调，则密钥管理协议中存在复杂性，如果密钥ID不是全局的，则可以避免这种复杂性。
Many core and enterprise routers support multiple routing instances. For example, a router serving multiple VPNs is likely to have a forwarding/routing instance for each of these VPNs. Each VRF will require its own routing key table.
许多核心路由器和企业路由器支持多个路由实例。例如，为多个VPN提供服务的路由器可能会为每个VPN提供一个转发/路由实例。每个VRF都需要自己的路由密钥表。
Several methods for authentication have been proposed for KARP. The simplest is preshared keys used directly as traffic keys. In this mode, the traffic integrity keys are directly configured. This is the mode supported by most of today's routing protocols.
针对KARP提出了几种认证方法。最简单的是直接用作通信密钥的预共享密钥。在此模式下，直接配置流量完整性密钥。这是当今大多数路由协议支持的模式。
As discussed in [RTG-AUTH], preshared keys can be used as the input to a key derivation function (KDF) to generate traffic keys. For example, the TCP Authentication Option (TCP-AO) [RFC5925] derives keys based on the initial TCP session state. Typically, a KDF will combine a long-term key with public inputs exchanged as part of the protocol to form fresh session keys. A KDF could potentially be used with some inputs that are configured along with the long-term key. Also, it's possible that inputs to a KDF will be private and exchanged as part of the protocol, although this will be uncommon in KARP's uses of KDFs.
如[RTG-AUTH]中所述，预共享密钥可用作密钥派生函数（KDF）的输入，以生成通信密钥。例如，TCP身份验证选项（TCP-AO）[RFC5925]基于初始TCP会话状态派生密钥。通常，KDF将长期密钥与作为协议一部分交换的公共输入相结合，以形成新的会话密钥。KDF可能与一些与长期密钥一起配置的输入一起使用。此外，KDF的输入可能是私有的，并作为协议的一部分进行交换，尽管这在KARP使用KDF时并不常见。
Preshared keys could also be used by an automated key management protocol. In this mode, preshared keys would be used for authentication. However, traffic keys would be generated by some key-agreement mechanism or transported in a key encryption key derived from the preshared key. This mode may provide better replay protection. Also, in the absence of active attackers, key-agreement strategies such as Diffie-Hellman can be used to produce high-quality traffic keys even from relatively weak preshared keys. These key-agreement mechanisms are valuable even when active attackers are present, although an active attacker can mount a man-in-the-middle attack if the preshared key is sufficiently weak.
自动密钥管理协议也可以使用预共享密钥。在此模式下，预共享密钥将用于身份验证。然而，通信密钥将由某种密钥协商机制生成，或在从预共享密钥派生的密钥加密密钥中传输。此模式可以提供更好的重播保护。此外，在没有主动攻击者的情况下，可以使用Diffie-Hellman等密钥协商策略来生成高质量的流量密钥，即使是来自相对较弱的预共享密钥。即使存在主动攻击者，这些密钥协商机制也很有价值，尽管如果预共享密钥足够弱，主动攻击者可以发起中间人攻击。
Public keys can be used for authentication within an automated key management protocol. The KARP design guide [RFC6518] describes a mode in which routers have the hashes of peer routers' public keys. In this mode, a traditional public-key infrastructure is not required. The advantage of this mode is that a router only contains its own keying material, limiting the scope of a compromise. The disadvantage is that when a router is added or deleted from the set of authorized routers, all routers in that set need to be updated. Note that self-signed certificates are a common way of communicating public keys in this style of authentication.
公钥可用于自动密钥管理协议内的身份验证。KARP设计指南[RFC6518]描述了一种路由器拥有对等路由器公钥散列的模式。在这种模式下，不需要传统的公钥基础设施。这种模式的优点是路由器只包含自己的密钥材料，限制了妥协的范围。缺点是，当从授权路由器集中添加或删除路由器时，该集中的所有路由器都需要更新。请注意，自签名证书是以这种身份验证方式传递公钥的常见方式。
Certificates signed by a certification authority or some other PKI could be used for authentication within an automated key management protocol. The advantage of this approach is that routers may not need to be directly updated when peers are added or removed. The disadvantage is that more complexity and cost are required.
由证书颁发机构或某些其他PKI签署的证书可用于自动密钥管理协议内的身份验证。这种方法的优点是，当添加或删除对等点时，路由器可能不需要直接更新。缺点是需要更多的复杂性和成本。
Each of these approaches has a different set of management and operational requirements. Key differences include how authorization is handled and how identity works. This section discusses these differences.
每种方法都有一套不同的管理和操作要求。关键区别包括如何处理授权和身份如何工作。本节讨论这些差异。
In the protocol, manual preshared keys are either unnamed or named by a key ID (which is a small integer -- typically 16 or 32 bits). Implementations that support multiple keys for protocols that have no names for keys need to try all possible keys before deciding a packet cannot be validated [RFC4808]. Typically key IDs are names used by one group or peer.
在协议中，手动预共享密钥要么未命名，要么由密钥ID命名（这是一个小整数，通常为16位或32位）。对于没有密钥名称的协议，支持多个密钥的实现需要在确定无法验证数据包之前尝试所有可能的密钥[RFC4808]。通常，密钥ID是一个组或对等方使用的名称。
Manual preshared keys are often known by a group of peers rather than just one other peer. This is an interesting security property: unlike with digitally signed messages or protocols where symmetric keys are known only to two parties, it is impossible to identify the peer sending a message cryptographically. However, it is possible to show that the sender of a message is one of the parties who knows the preshared key. Within the routing threat model, the peer sending a message can be identified only because peers are trusted and thus can be assumed to correctly label the packets they send. This contrasts with a protocol where cryptographic means such as digital signatures are used to verify the origin of a message. As a consequence, authorization is typically based on knowing the preshared key rather than on being a particular peer. Note that once an authorization decision is made, the peer can assert its identity; this identity is trusted just as the routing information from the peer is trusted. Doing an additional check for authorization based on the identity included in the packet would provide little value: an attacker who somehow had the key could claim the identity of an authorized peer, and an attacker without the key should be unable to claim the identity of any peer. Such a check is not required by the KARP threat model: inside attacks are not in scope.
手动预共享密钥通常由一组对等方知道，而不仅仅是另一个对等方。这是一个有趣的安全特性：与数字签名的消息或协议不同，在这些消息或协议中，对称密钥仅为双方所知，因此无法通过加密方式识别发送消息的对等方。但是，可以显示消息的发送者是知道预共享密钥的一方。在路由威胁模型中，发送消息的对等方只能被识别，因为对等方是可信的，因此可以假设对等方正确标记了它们发送的数据包。这与使用加密手段（如数字签名）验证消息来源的协议形成对比。因此，授权通常基于知道预共享密钥，而不是作为特定对等方。注意，一旦做出授权决定，对等方就可以声明其身份；此标识受信任，就像来自对等方的路由信息受信任一样。基于数据包中包含的身份进行额外的授权检查将没有什么价值：以某种方式拥有密钥的攻击者可以声明已授权对等方的身份，而没有密钥的攻击者应该无法声明任何对等方的身份。KARP威胁模型不需要这样的检查：内部攻击不在范围之内。
Preshared keys used with key derivation work similarly to manual preshared keys. However, to form the actual traffic keys, session-or peer-specific information is combined with the key. From an authorization standpoint, the derivation key works the same as a manual key. An additional routing protocol step or transport step forms the key that is actually used.
与密钥派生一起使用的预共享密钥的工作方式类似于手动预共享密钥。然而，为了形成实际的通信密钥，将会话或对等特定信息与密钥相结合。从授权的角度来看，派生密钥的工作原理与手动密钥相同。额外的路由协议步骤或传输步骤形成了实际使用的密钥。
Preshared keys that are used via automatic key management have not yet been specified for KARP, although ongoing work suggests they will be needed. Their naming and authorization may differ from existing uses of preshared keys in routing protocols. In particular, such keys may end up being known only by two peers. Alternatively, they may also be known by a group of peers. Authorization could potentially be based on peer identity, although it is likely that knowing the right key will be sufficient. There does not appear to
通过自动密钥管理使用的预共享密钥尚未为KARP指定，尽管正在进行的工作表明需要这些密钥。它们的命名和授权可能不同于路由协议中预共享密钥的现有使用。特别是，这样的密钥最终可能只有两个对等方知道。或者，它们也可以由一组对等方知道。授权可能基于对等身份，尽管知道正确的密钥可能就足够了。似乎没有
be a compelling reason to decouple the authorization of a key for some purpose from the authorization of peers holding that key to perform the authorized function.
出于某种目的，将密钥授权与持有该密钥的对等方执行授权功能的授权分离是一个令人信服的理由。
Care needs to be taken when symmetric keys are used for multiple purposes. Consider the implications of using the same preshared key for two interfaces: it becomes impossible to cryptographically distinguish a router on one interface from a router on another interface. So, a router that is trusted to participate in a routing protocol on one interface becomes implicitly trusted for the other interfaces that share the key. For many cases, such as link-state routers in the same routing area, there is no significant advantage that an attacker could gain from this trust within the KARP threat model. However, other protocols, such as BGP and RIP, permit routes to be filtered across a trust boundary. For these protocols, participation in one interface might be more advantageous than another. Operationally, when this trust distinction is important to a deployment, different keys need to be used on each side of the trust boundary. Key derivation can help prevent this problem in cases of accidental misconfiguration. However, key derivation cannot protect against a situation where a system was incorrectly trusted to have the key used to perform the derivation. This question of trust is important to the KARP threat model because it is essential to determining whether a party is an insider for a particular routing protocol. A customer router that is an insider for a BGP peering relationship with a service provider is not typically an insider when considering the security of that service provider's IGP. Similarly, to the extent that there are multiple zones of trust and a routing protocol is determining whether a particular router is within a certain zone, the question of untrusted actors is within the scope of the routing threat model.
当对称密钥用于多种用途时，需要小心。考虑使用两个接口相同的预键的含义：不可能将一个接口上的路由器与另一个接口上的路由器进行密码区分。因此，受信任参与一个接口上的路由协议的路由器对于共享密钥的其他接口成为隐式受信任的路由器。对于许多情况，例如同一路由区域中的链路状态路由器，在KARP威胁模型中，攻击者无法从这种信任中获得显著优势。但是，其他协议（如BGP和RIP）允许跨信任边界过滤路由。对于这些协议，参与一个接口可能比参与另一个接口更有利。在操作上，当这种信任区分对部署很重要时，需要在信任边界的每一侧使用不同的密钥。密钥派生有助于防止意外错误配置时出现此问题。但是，密钥派生无法防止系统被错误地信任为具有用于执行派生的密钥的情况。信任问题对于KARP威胁模型非常重要，因为它对于确定一方是否是特定路由协议的内部人员至关重要。当考虑到服务提供商的IGP的安全性时，作为BGP对等关系的内部人的客户路由器通常不是内部人。类似地，如果存在多个信任区域，并且路由协议正在确定特定路由器是否在特定区域内，则不受信任的参与者的问题在路由威胁模型的范围内。
Key derivation can be part of a management solution for having multiple keys for different zones of trust. A master key could be combined with peer, link, or area identifiers to form a router-specific preshared key that is loaded onto routers. Provided that the master key lives only on the management server and not the individual routers, trust is preserved. However, in many cases, generating independent keys for the routers and storing the result is more practical. If the master key were somehow compromised, all the resulting keys would need to be changed. However, if independent keys are used, the scope of a compromise may be more limited.
密钥派生可以是针对不同信任区域拥有多个密钥的管理解决方案的一部分。主密钥可以与对等、链路或区域标识符组合，以形成加载到路由器上的特定于路由器的预共享密钥。如果主密钥仅存在于管理服务器上，而不存在于各个路由器上，则会保留信任。然而，在许多情况下，为路由器生成独立密钥并存储结果更为实际。如果主密钥以某种方式被泄露，则需要更改所有生成的密钥。但是，如果使用独立密钥，则折衷的范围可能会更加有限。
More subtle problems with key separation can appear in protocol design. Two protocols that use the same traffic keys may work together in unintended ways permitting one protocol to be used to attack the other. Consider two hypothetical protocols. Protocol A starts its messages with a set of extensions that are ignored if not understood. Protocol B has a fixed header at the beginning of its messages but ends messages with extension information. It may be that the same message is valid both as part of protocol A and protocol B. An attacker may be able to gain an advantage by getting a router to generate this message with one protocol under situations where the other protocol would not generate the message. This hypothetical example is overly simplistic; real-world attacks exploiting key separation weaknesses tend to be complicated and involve specific properties of the cryptographic functions involved. The key point is that whenever the same key is used in multiple protocols, attacks may be possible. All the involved protocols need to be analyzed to understand the scope of potential attacks.
在协议设计中可能会出现更微妙的密钥分离问题。使用相同通信密钥的两个协议可能以非预期方式协同工作，从而允许一个协议用于攻击另一个协议。考虑两个假设的协议。协议A以一组扩展开始其消息，如果不理解这些扩展，则会忽略这些扩展。协议B在其消息的开头有一个固定的头，但在消息的结尾有扩展信息。同一消息可能作为协议A和协议B的一部分都有效。在另一协议不生成消息的情况下，攻击者可以通过让路由器使用一个协议生成此消息来获得优势。这个假设的例子过于简单化；利用密钥分离弱点进行的实际攻击往往比较复杂，并且涉及所涉及的加密函数的特定属性。关键的一点是，只要在多个协议中使用相同的密钥，就可能发生攻击。需要分析所有涉及的协议，以了解潜在攻击的范围。
Key separation attacks interact with the KARP operational model in a number of ways. Administrators need to be aware of situations where using the same manual traffic key with two different protocols (or the same protocol in different contexts) creates attack opportunities. Design teams should consider how their protocol might interact with other routing protocols and describe any attacks discovered so that administrators can understand the operational implications. When designing automated key management or new cryptographic authentication within routing protocols, we need to be aware that administrators expect to be able to use the same preshared keys in multiple contexts. As a result, we should use appropriate key derivation functions so that different cryptographic keys are used even when the same initial input key is used.
密钥分离攻击以多种方式与KARP操作模型交互。管理员需要注意在两个不同协议（或不同上下文中的相同协议）中使用相同的手动流量密钥会造成攻击机会的情况。设计团队应该考虑他们的协议如何与其他路由协议交互，并描述发现的任何攻击，以便管理员能够理解操作含义。在路由协议中设计自动密钥管理或新的加密身份验证时，我们需要知道管理员希望能够在多个上下文中使用相同的预共享密钥。因此，我们应该使用适当的密钥派生函数，以便即使使用相同的初始输入密钥，也可以使用不同的加密密钥。
Outside of a PKI, public keys are expected to be known by the hash of a key or (potentially self-signed) certificate. The Session Description Protocol provides a standardized mechanism for naming keys (in that case, certificates) based on hashes (Section 5 of [RFC4572]). KARP SHOULD adopt this approach or another approach already standardized within the IETF rather than inventing a new mechanism for naming public keys.
在PKI之外，公钥应该通过密钥或（可能是自签名的）证书的散列来知道。会话描述协议提供了一种基于散列（RFC4572第5节）命名密钥（在这种情况下为证书）的标准化机制。KARP应该采用这种方法或IETF中已经标准化的另一种方法，而不是发明一种新的公钥命名机制。
A public key is typically expected to belong to one peer. As a peer generates new keys and retires old keys, its public key may change. For this reason, from a management standpoint, peers should be
公钥通常应属于一个对等方。当对等方生成新密钥并停用旧密钥时，其公钥可能会更改。因此，从管理的角度来看，同行应该
thought of as associated with multiple public keys rather than as containing a single public-key hash as an attribute of the peer object.
被认为与多个公钥关联，而不是包含单个公钥哈希作为对等对象的属性。
Authorization of public keys could be done either by key hash or by peer identity. Performing authorizations by peer identity should make it easier to update the key of a peer without risk of losing authorizations for that peer. However, management interfaces need to be carefully designed to avoid making this extra level of indirection complicated for operators.
公钥的授权可以通过密钥散列或对等身份来完成。通过对等身份执行授权应该可以更容易地更新对等方的密钥，而不会丢失该对等方的授权。然而，需要仔细设计管理界面，以避免使操作员的间接寻址变得复杂。
When a PKI is used, certificates are used. The certificate binds a key to a name of a peer. The key management protocol is responsible for exchanging certificates and validating them to a trust anchor.
使用PKI时，将使用证书。证书将密钥绑定到对等方的名称。密钥管理协议负责交换证书并向信任锚验证证书。
Authorization needs to be done in terms of peer identities not in terms of keys. One reason for this is that when a peer changes its key, the new certificate needs to be sufficient for authentication to continue functioning even though the key has never been seen before.
授权需要根据对等身份而不是密钥进行。这样做的一个原因是，当对等方更改其密钥时，新证书需要足以使身份验证继续工作，即使该密钥以前从未见过。
Potentially, authorization could be performed in terms of groups of peers rather than single peers. An advantage of this is that it may be possible to add a new router with no authentication-related configuration of the peers of that router. For example, a domain could decide that any router with a particular keyPurposeID signed by the organization's certificate authority is permitted to join the IGP. Just as in configurations where cryptographic authentication is not used, automatic discovery of this router can establish appropriate adjacencies.
可能的情况是，授权可以按照对等点组而不是单个对等点来执行。这样做的一个优点是，可以添加一个新路由器，而不需要该路由器的对等方的身份验证相关配置。例如，域可以决定允许具有由组织的证书颁发机构签名的特定keyPurposeID的任何路由器加入IGP。正如在不使用加密身份验证的配置中一样，此路由器的自动发现可以建立适当的邻接。
Assuming that self-signed certificates are used by routers that wish to use public keys but that do not need a PKI, then PKI and the "infrastructure-less" mode of public-key operation described in the previous section can work well together. One router could identify its peers based on names and use certificate validation. Another router could use hashes of certificates. This could be very useful for border routers between two organizations. Smaller organizations could use public keys and larger organizations could use PKI.
假设希望使用公钥但不需要PKI的路由器使用自签名证书，那么PKI和上一节描述的“无基础设施”公钥操作模式可以很好地协同工作。一个路由器可以根据名称识别其对等方，并使用证书验证。另一个路由器可以使用证书哈希。这对于两个组织之间的边界路由器非常有用。较小的组织可以使用公钥，较大的组织可以使用PKI。
A PKI has significant operational concerns including certification practices, handling revocation, and operational practices around certificate validation. The Routing PKI (RPKI) has addressed these concerns within the scope of BGP and the validation of address ownership. Adapting these practices to routing protocol authentication is outside the scope of this document.
PKI具有重要的操作问题，包括认证实践、处理撤销以及围绕证书验证的操作实践。路由PKI（RPKI）在BGP和地址所有权验证的范围内解决了这些问题。使这些实践适应路由协议身份验证超出了本文档的范围。
An area to explore is the role of central servers like RADIUS or directories. Routers need to securely operate in order to provide network routing services. Routers cannot generally contact a central server while establishing routing because the router might not have a functioning route to the central service until after routing is established. As a result, a system where keys are pushed by a central management system is an undesirable result for router keying. However, central servers may play a role in authorization and key rollover. For example, a node could send a hash of a public key to a RADIUS server.
一个需要探索的领域是RADIUS或目录等中心服务器的作用。为了提供网络路由服务，路由器需要安全运行。路由器通常无法在建立路由时联系中央服务器，因为路由器在建立路由之前可能没有到中央服务的正常路由。因此，由中央管理系统推送密钥的系统对于路由器密钥是不希望的结果。但是，中央服务器可能在授权和密钥翻转中发挥作用。例如，节点可以向RADIUS服务器发送公钥哈希。
If central servers do play a role, it will be critical to make sure that they are not required during routine operation or a cold-start of a network. They are more likely to play a role in enrollment of new peers or key migration/compromise.
如果中央服务器确实发挥了作用，那么确保在日常操作或网络冷启动期间不需要它们将是至关重要的。他们更有可能在新同伴的注册或关键迁移/妥协中发挥作用。
Another area where central servers may play a role is for group key agreement. As an example, [OSPF-AUTO] discusses the potential need for key-agreement servers in OSPF. Other routing protocols that use multicast or broadcast such as IS-IS are likely to need a similar approach. Multicast key-agreement protocols need to allow operators to choose which key servers will generate traffic keys. The quality of random numbers [RFC4086] is likely to differ between systems. As a result, operators may have preferences for where keys are generated.
中央服务器可能发挥作用的另一个领域是组密钥协议。例如，[OSPF-AUTO]讨论了OSPF中对关键协议服务器的潜在需求。使用多播或广播（如IS-IS）的其他路由协议可能需要类似的方法。多播密钥协议需要允许运营商选择哪些密钥服务器将生成通信密钥。随机数[RFC4086]的质量可能因系统而异。因此，操作员可能对生成关键点的位置具有首选项。
One significant management consideration will be the grouping of management objects necessary to determine who is authorized to act as a peer for a given routing action. As discussed previously, the following objects are potentially required:
一个重要的管理考虑因素将是确定谁有权作为给定路由操作的对等方所需的管理对象分组。如前所述，可能需要以下对象：
o Key objects are required. Symmetric keys may be preshared, and knowledge of the key may be used as the decision factor in authorization. Knowledge of the private key corresponding to asymmetric public keys may be used directly for authorization as well. During key transitions, more than one key may refer to a given peer. Group preshared keys may refer to multiple peers.
o 关键对象是必需的。可以预共享对称密钥，并且密钥的知识可以用作授权中的决策因素。与非对称公钥对应的私钥的知识也可直接用于授权。在密钥转换期间，多个密钥可能引用给定的对等方。组预共享密钥可能引用多个对等方。
o Peer objects are required. A peer is a router that this router might wish to communicate with. Peers may be identified by names or keys.
o 对等对象是必需的。对等方是该路由器可能希望与之通信的路由器。对等点可以通过名称或键来识别。
o Objects representing peer groups are required. Groups of peers may be authorized for a given routing protocol.
o 表示对等组的对象是必需的。可以为给定的路由协议授权对等组。
Establishing a management model is difficult because of the complex relationships between each set of objects. As discussed, there may be more than one key for a peer. However, in the preshared key case, there may be more than one peer for a key. This is true both for group security association protocols such as an IGP or one-to-one protocols where the same key is used administratively. In some of these situations, it may be undesirable to explicitly enumerate the peers in the configuration; for example, IGP peers are auto-discovered for broadcast links but not for non-broadcast multi-access links.
由于每组对象之间的复杂关系，建立管理模型很困难。如前所述，对等机可能有多个密钥。然而，在预共享密钥的情况下，一个密钥可能有多个对等方。对于组安全关联协议（如IGP）或管理性使用相同密钥的一对一协议，都是如此。在其中一些情况下，可能不希望显式枚举配置中的对等点；例如，对于广播链路自动发现IGP对等点，但对于非广播多址链路不自动发现IGP对等点。
Peers may be identified either by name or key. If peers are identified by key, it is strongly desirable from an operational standpoint to consider any peer identifiers or names to be a local matter and not require the identifiers or names to be synchronized. Obviously, if peers are identified by names (for example, with certificates in a PKI), identifiers need to be synchronized between the authorized peer and the peer making the authorization decision.
对等点可以通过名称或密钥进行标识。如果通过密钥识别对等体，则从操作的角度非常希望将任何对等标识符或名称视为本地事项，而不要求标识符或名称同步。显然，如果通过名称（例如，PKI中的证书）标识对等点，则需要在授权对等点和做出授权决策的对等点之间同步标识符。
In many cases, peers will explicitly be identified in routing protocol configuration. In these cases, it is possible to attach the authorization information (keys or identifiers) to the peer's configuration object. Two cases do not involve enumerating peers. The first is the case where preshared keys are shared among a group of peers. It is likely that this case can be treated from a management standpoint as a single peer representing all the peers that share the keys. The other case is one where certificates in a PKI are used to introduce peers to a router. In this case, rather than configuring peers, the router needs to be configured with information on which certificates represent acceptable peers.
在许多情况下，对等点将在路由协议配置中明确标识。在这些情况下，可以将授权信息（密钥或标识符）附加到对等方的配置对象。有两种情况不涉及枚举对等点。第一种情况是在一组对等方之间共享预共享密钥。从管理的角度来看，这种情况很可能被视为代表共享密钥的所有对等方的单个对等方。另一种情况是使用PKI中的证书将对等点引入路由器。在这种情况下，路由器需要配置哪些证书代表可接受的对等点的信息，而不是配置对等点。
Another consideration is which routing protocols share peers. For example, it may be common for LDP peers to also be peers of some other routing protocol. Also, RSVP - Traffic Engineering (RSVP-TE) may be associated with some TE-based IGP. In some of these cases, it would be desirable to use the same authorization information for both routing protocols.
另一个需要考虑的问题是哪些路由协议共享对等点。例如，LDP对等点也可能是一些其他路由协议的对等点。此外，RSVP-流量工程（RSVP-TE）可能与某些基于TE的IGP相关。在其中一些情况下，希望对两个路由协议使用相同的授权信息。
Finally, as discussed in Section 7, it is sometimes desirable to override some aspect of the configuration for a peer in a group. As an example, when rotating to a new key, it is desirable to be able to roll that key out to each peer that will use the key, even if in the stable state the key is configured for a peer group.
最后，如第7节所述，有时需要覆盖组中对等方的配置的某些方面。例如，当旋转到新密钥时，希望能够将该密钥转出到将使用该密钥的每个对等方，即使在稳定状态下，该密钥是为对等组配置的。
In order to develop a management model for authorization, the working group needs to consider several questions. What protocols support auto-discovery of peers? What protocols require more configuration of a peer than simply the peer's authorization information and
为了开发一个授权管理模型，工作组需要考虑几个问题。哪些协议支持自动发现对等点？什么协议需要对对等方进行更多的配置，而不仅仅是对等方的授权信息和
network address? What management operations are going to be common as security information for peers is configured and updated? What operations will be common while performing key transitions or while migrating to new security technologies?
网络地址？在配置和更新对等方的安全信息时，哪些管理操作将是常见的？在执行密钥转换或迁移到新的安全技术时，哪些操作是常见的？
One key operational question is what areas will administrator involvement be required. Likely areas where involvement may be useful include enrollment of new peers. Fault recovery should also be considered.
一个关键的操作问题是需要管理员参与哪些领域。参与可能有用的领域包括新同事的注册。还应考虑故障恢复。
One area where the management of routing security needs to be optimized is the deployment of a new router. In some cases, a new router may be deployed on an existing network where routing to management servers is already available. In other cases, routers may be deployed as part of connecting or creating a site. Here, the router and infrastructure may not be available until the router has securely authenticated.
路由安全管理需要优化的一个领域是新路由器的部署。在某些情况下，新的路由器可能部署在现有网络上，其中到管理服务器的路由已经可用。在其他情况下，路由器可以作为连接或创建站点的一部分进行部署。在这里，路由器和基础设施可能在路由器安全认证之前不可用。
In general, security configuration can be treated as an additional configuration item that needs to be set up to establish service. There is no significant security value in protecting routing protocol keys more than administrative password or Authentication, Authorization, and Accounting (AAA) secrets that can be used to gain login access to a router. These existing secrets can be used to make configuration changes that impact routing protocols as much as disclosure of a routing protocol key. Operators already have procedures in place for these items. So, it is appropriate to use similar procedures for routing protocol keys. It is reasonable to improve existing configuration procedures and the routing protocol procedures over time. However, it is more desirable to deploy KARP with security similar to that used for managing existing secrets than to delay deploying KARP.
通常，安全配置可以被视为需要设置以建立服务的附加配置项。在保护路由协议密钥方面没有比管理密码或可用于获得对路由器的登录访问权限的身份验证、授权和记帐（AAA）机密更重要的安全价值。这些现有机密可用于进行配置更改，这些更改对路由协议的影响与泄露路由协议密钥一样大。运营商已经为这些项目制定了程序。因此，对路由协议密钥使用类似的过程是合适的。随着时间的推移，改进现有的配置过程和路由协议过程是合理的。然而，部署具有类似于用于管理现有机密的安全性的KARP比延迟部署KARP更可取。
Operators MAY develop higher assurance procedures for dealing with keys. For example, asymmetric keys can be generated on a router and never exported from the router. Operators can evaluate the cost vs. security and the availability tradeoffs of these procedures.
操作员可制定更高的钥匙处理保证程序。例如，非对称密钥可以在路由器上生成，并且永远不会从路由器导出。运营商可以评估这些程序的成本与安全性以及可用性权衡。
Faults may interact with operational practice in at least two ways. First, security solutions may introduce faults. For example, if certificates expire in a PKI, previous adjacencies may no longer form. Operational practice will require a way of repairing these errors. This may end up being very similar to repairing other faults that can partition a network.
故障可能至少以两种方式与操作实践相互作用。首先，安全解决方案可能会引入故障。例如，如果证书在PKI中过期，则以前的邻接可能不再形成。操作实践需要一种修复这些错误的方法。这可能与修复其他可能导致网络分区的故障非常相似。
Notifications will play a critical role in avoiding security faults. Implementations SHOULD use appropriate mechanisms to notify operators as security resources are about to expire. Notifications can include messages to consoles, logged events, Simple Network Management Protocol (SNMP) traps, or notifications within a routing protocol. One strategy is to have increasing escalations of notifications.
通知将在避免安全故障方面发挥关键作用。当安全资源即将过期时，实现应使用适当的机制通知操作员。通知可以包括到控制台的消息、记录的事件、简单网络管理协议（SNMP）陷阱或路由协议内的通知。一个策略是增加通知的升级。
Monitoring will also play an important role in avoiding security faults such as certificate expiration. Some classes of security fault, including issues with certificates, will affect only key management protocols. Other security faults can affect routing protocols directly. However, the protocols MUST still have adequate operational mechanisms to recover from these situations. Also, some faults, such as those resulting from a compromise or actual attack on a facility, are inherent and may not be prevented.
监控还将在避免证书过期等安全故障方面发挥重要作用。某些类别的安全故障（包括证书问题）只会影响密钥管理协议。其他安全故障会直接影响路由协议。然而，这些协议仍必须有足够的运作机制，以便从这些情况中恢复过来。此外，一些故障（如设施受损或实际攻击导致的故障）是固有的，可能无法预防。
A second class of faults is equipment faults that impact security. For example, if keys are stored on a router and never exported from that device, failure of a router implies a need to update security provisioning on the replacement router and its peers.
第二类故障是影响安全的设备故障。例如，如果密钥存储在路由器上并且从未从该设备导出，则路由器故障意味着需要更新替换路由器及其对等机上的安全配置。
One approach, recommended by work on securing BGP [KEYING] is to maintain the router's keying material so that when a router is replaced the same keys can be used. Router keys can be maintained on a central server. These approaches permit the credentials of a router to be recovered. This provides valuable options in case of hardware fault. The failing router can be recovered without changing credentials on other routers or waiting for keys to be certified. One disadvantage of this approach is that even if public-key cryptography is used, the private keys are located on more than just the router. A system in which keys were generated on a router and never exported from that router would typically make it more difficult for an attacker to obtain the keys. For most environments, the ability to quickly replace a router justifies maintaining keys centrally.
保护BGP[KEYING]的工作推荐的一种方法是维护路由器的密钥材料，以便在更换路由器时可以使用相同的密钥。路由器密钥可以在中央服务器上维护。这些方法允许恢复路由器的凭据。这在出现硬件故障时提供了有价值的选项。故障路由器可以恢复，而无需更改其他路由器上的凭据或等待密钥认证。这种方法的一个缺点是，即使使用公钥加密，私钥也不仅仅位于路由器上。在一个系统中，密钥是在路由器上生成的，并且从未从该路由器导出，这通常会使攻击者更难获得密钥。对于大多数环境，快速更换路由器的能力证明需要集中维护密钥。
More generally, keying is another item of configuration that needs to be restored to reestablish service when equipment fails. Operators typically perform the minimal configuration necessary to get a router
更一般地说，键控是另一项配置，需要在设备出现故障时恢复以重新建立服务。运营商通常执行获得路由器所需的最低配置
back in contact with the management server. The same would apply for keys. Operators who do not maintain copies of key material for performing key recovery on routers would need to perform a bit more work to regain contact with the management server. It seems reasonable to assume that management servers will be able to cause keys to be generated or distributed sufficiently to fully restore service.
重新与管理服务器联系。这同样适用于钥匙。不维护密钥材料副本以在路由器上执行密钥恢复的操作员需要执行更多的工作以重新与管理服务器联系。似乎可以合理地假设，管理服务器将能够生成或分发足够的密钥，以完全恢复服务。
It needs to be possible to deploy automated key management in an organization without either having to disable existing security or disrupting routing. As a result, it needs to be possible to perform a phased upgrade from manual keying to automated key management. This upgrade procedure needs to be easy and have a very low risk of disrupting routing. Today, many operators do not update keys because the perceived risk of an attack is lower than the cost of an update combined with the potential cost of routing disruptions during the update. Even when a routing protocol has technical mechanisms that permit an update with no disruption in service, there is still a potential cost of service disruptions as operational procedures and practices need to correctly use the technical mechanisms.
需要能够在组织中部署自动密钥管理，而无需禁用现有安全性或中断路由。因此，需要能够执行从手动键控到自动键控管理的分阶段升级。此升级过程需要简单，并且中断路由的风险非常低。如今，许多运营商不更新密钥，因为感知到的攻击风险低于更新成本加上更新期间路由中断的潜在成本。即使路由协议具有允许在不中断服务的情况下进行更新的技术机制，由于操作过程和实践需要正确使用技术机制，仍然存在服务中断的潜在成本。
For peer-to-peer protocols such as BGP, upgrading to automated key management can be relatively easy. First, code that supports automated key management needs to be loaded on both peers. Then, the adjacency can be upgraded. The configuration can be updated to switch to automated key management when the second router reboots. Alternatively, if the key management protocols involved can detect that both peers now support automated key management, then a key can potentially be negotiated for an existing session.
对于BGP等对等协议，升级到自动密钥管理相对容易。首先，支持自动密钥管理的代码需要在两个对等机上加载。然后，可以升级邻接关系。当第二个路由器重新启动时，可以更新配置以切换到自动密钥管理。或者，如果所涉及的密钥管理协议可以检测到两个对等方现在都支持自动密钥管理，则可以为现有会话协商密钥。
The situation is more complex for organizations that have not upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option [RFC5925]. Today, routers typically need to understand whether a given peer supports TCP MD5 or TCP-AO before opening a TCP connection. In addition, many implementations support grouping configuration (including security configuration) of related peers together. Implementations make it challenging to move from TCP MD5 to TCP-AO before all peers in the group are ready. Operators perceive it as high risk to update the configuration of a large number of peers. One particularly risky situation is upgrading the configuration of Internal BGP (iBGP) peers.
对于尚未从TCP MD5[RFC2385]升级到TCP身份验证选项[RFC5925]的组织来说，情况更为复杂。如今，路由器通常需要在打开TCP连接之前了解给定对等方是否支持TCP MD5或TCP-AO。此外，许多实现支持将相关对等方的分组配置（包括安全配置）放在一起。实施使得在组中的所有对等方准备就绪之前从TCP MD5移动到TCP-AO具有挑战性。运营商认为更新大量对等机的配置具有高风险。一种特别危险的情况是升级内部BGP（iBGP）对等机的配置。
The situation is more complicated for multicast protocols. It's typically not desirable to bring down an entire link to reconfigure it as using automated key management. Two approaches should be considered. One is to support key table rows that enable the
对于多播协议来说，情况更为复杂。通常不希望关闭整个链接以使用自动密钥管理对其进行重新配置。应考虑两种方法。一种方法是支持启用
automated key management and manually configured keying for the same link at the same time. Coordinating this may be challenging from an operational standpoint. Another possibility is for the automated key management protocol to actually select the same traffic key that is being used manually. This could be accomplished by having an option in the key management protocol to export the current manual group key through the automated key management protocol. Then after all nodes are configured with automated key management, manual key entries can be removed. The next re-key after all nodes have manual entries removed will generate a new fresh key. Group key management protocols are RECOMMENDED to support an option to export existing manual keys during initial deployment of automated key management.
自动密钥管理和同时为同一链路手动配置密钥。从操作角度来看，协调这一点可能具有挑战性。另一种可能性是自动密钥管理协议实际选择手动使用的相同通信密钥。这可以通过密钥管理协议中的一个选项来实现，该选项通过自动密钥管理协议导出当前手动组密钥。然后，在所有节点都配置了自动密钥管理后，可以删除手动密钥条目。删除所有节点的手动条目后，下一次重新设置密钥将生成新的新密钥。建议使用组密钥管理协议来支持在自动密钥管理的初始部署期间导出现有手动密钥的选项。
This document does not define a protocol. It does discuss the operational and management implications of several security technologies.
本文档未定义协议。它确实讨论了几种安全技术的操作和管理含义。
Close synchronization of time can impact the security of routing protocols in a number of ways. Time is used to control when keys MAY begin being used and when they MUST NOT be used any longer as described in [RFC7210]. Routers need to have tight enough time synchronization that receivers permit a key to be utilized for validation prior to the first use of that key for generation of integrity-protected messages; otherwise, availability will be impacted. If time synchronization is too loose, then a key can be used beyond its intended lifetime. The Network Time Protocol (NTP) can be used to provide time synchronization. For some protocols, time synchronization is also important for replay detection.
时间的紧密同步可以在许多方面影响路由协议的安全性。如[RFC7210]所述，时间用于控制何时可以开始使用按键以及何时不能再使用按键。路由器需要有足够紧密的时间同步，以便在首次使用密钥生成完整性保护消息之前，接收器允许使用该密钥进行验证；否则，可用性将受到影响。如果时间同步太松，则密钥可以在其预期寿命之外使用。网络时间协议（NTP）可用于提供时间同步。对于某些协议，时间同步对于重播检测也很重要。
Funding for Sam Hartman's work on this memo is provided by Huawei.
Sam Hartman撰写本备忘录的资金由华为提供。
The authors would like to thank Bill Atwood, Randy Bush, Wes George, Gregory Lebovitz, and Russ White for valuable reviews.
作者要感谢比尔·阿特伍德、兰迪·布什、韦斯·乔治、格雷戈里·勒博维茨和罗斯·怀特的宝贵评论。
[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月。
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, April 2014.
[RFC7210]Housley，R.，Polk，T.，Hartman，S.，和D.Zhang，“长寿命对称加密密钥数据库”，RFC 72102014年4月。
[KEYING] Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", Work in Progress, May 2014.
[KEYING]Turner，S.，Patel，K.，和R.Bush，“BGPsec的路由器键控”，正在进行的工作，2014年5月。
[OSPF-AUTO] Liu, Y., "OSPFv3 Automated Group Keying Requirements", Work in Progress, July 2007.
[OSPF-AUTO]Liu，Y.，“OSPFv3自动组键控要求”，进展中的工作，2007年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808]Bellovin，S.，“TCP-MD5的关键变化策略”，RFC 4808，2007年3月。
[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月。
[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月。
[RTG-AUTH] Polk, T. and R. Housley, "Routing Authentication Using A Database of Long-Lived Cryptographic Keys", Work in Progress, November 2010.
[RTG-AUTH]Polk，T.和R.Housley，“使用长寿命密码密钥数据库进行路由验证”，正在进行的工作，2010年11月。
Authors' Addresses
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Dacheng Zhang Huawei Technologies Co. Ltd.
张大成华为技术有限公司。
EMail: zhangdacheng@huawei.com
EMail: zhangdacheng@huawei.com