Internet Engineering Task Force (IETF) U. Chunduri
Request for Comments: 7645 A. Tian
Category: Informational W. Lu
ISSN: 2070-1721 Ericsson Inc.
September 2015
Internet Engineering Task Force (IETF) U. Chunduri
Request for Comments: 7645 A. Tian
Category: Informational W. Lu
ISSN: 2070-1721 Ericsson Inc.
September 2015
The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis
路由协议（KARP）的密钥和认证是一种安全分析
Abstract
摘要
This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.
本文件根据“手动和自动密钥管理协议的路由协议密钥和认证（KARP）设计指南”（RFC 6518）中规定的要求，分析中间系统到中间系统（IS-IS）协议的当前状态。
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/rfc7645.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7645.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Subnetwork Independent . . . . . . . . . . . . . . . 4
2.1.2. Subnetwork dependent . . . . . . . . . . . . . . . . 4
2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5
2.3.1.1. Current Recovery Mechanism for LSPs . . . . . . . 6
2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8
3. Gap Analysis and Security Requirements . . . . . . . . . . . 8
3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8
3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Subnetwork Independent . . . . . . . . . . . . . . . 4
2.1.2. Subnetwork dependent . . . . . . . . . . . . . . . . 4
2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5
2.3.1.1. Current Recovery Mechanism for LSPs . . . . . . . 6
2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8
3. Gap Analysis and Security Requirements . . . . . . . . . . . 8
3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8
3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" [RFC6518] for both manual and automated key management protocols.
本文件根据手动和自动密钥管理协议的“路由协议的密钥和认证（KARP）设计指南”[RFC6518]中规定的要求，分析中间系统到中间系统（IS-IS）协议的当前状态。
With currently published work, IS-IS meets some of the requirements expected from a manually keyed routing protocol. Integrity protection is expanded by allowing more cryptographic algorithms to be used [RFC5310]. However, even with this expanded protection, only limited algorithm agility (HMAC-SHA family) is possible. [RFC5310] makes possible a basic form of intra-connection rekeying, but with some gaps as analyzed in Section 3 of this document.
根据目前发表的工作，IS-IS满足了手动键控路由协议的一些要求。通过允许使用更多加密算法，完整性保护得以扩展[RFC5310]。然而，即使有了这种扩展的保护，也只能实现有限的算法敏捷性（HMAC-SHA系列）。[RFC5310]使连接内密钥更新的基本形式成为可能，但如本文件第3节所分析的，存在一些差距。
This document summarizes the current state of cryptographic key usage in the IS-IS protocol and several previous efforts that analyze IS-IS security. This includes the base IS-IS specifications: [RFC1195], [RFC5304], [RFC5310], and [RFC6039].
本文档总结了IS-IS协议中加密密钥使用的当前状态以及以前分析IS-IS安全性的几项工作。这包括基础IS-IS规范：[RFC1195]、[RFC5304]、[RFC5310]和[RFC6039]。
This document also analyzes various threats to IS-IS (as described in [RFC6862]), lists security gaps, and provides specific recommendations to thwart the threats for both manual keying and automated key management mechanisms.
本文件还分析了IS-IS面临的各种威胁（如[RFC6862]所述），列出了安全漏洞，并提供了阻止手动密钥和自动密钥管理机制威胁的具体建议。
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]中所述进行解释。
DoS - Denial of Service
拒绝服务
GDOI - Group Domain of Interpretation
GDOI-解释的组域
IGP - Interior Gateway Protocol
内部网关协议
IIH - IS-IS HELLO
你好
IPv4 - Internet Protocol version 4
IPv4-互联网协议版本4
KMP - Key Management Protocol (automated key management)
KMP-密钥管理协议（自动密钥管理）
LSP - Link State PDU
LSP-链路状态PDU
MKM - Manual Key Management
MKM-手动密钥管理
NONCE - Number Once
NONCE-数字一次
PDU - Protocol Data Unit
协议数据单元
SA - Security Association
SA-安全协会
SNP - Sequence Number PDU
SNP-序列号PDU
IS-IS is specified in International Standards Organization (ISO) 10589 [ISO10589], with extensions to support Internet Protocol version 4 (IPv4) described in [RFC1195]. The specification includes an authentication mechanism that allows for any authentication algorithm and also specifies the algorithm for clear text passwords. Further, [RFC5304] extends the authentication mechanism to work with HMAC-MD5 and also modifies the base protocol for more effectiveness. [RFC5310] provides algorithm agility, with a new generic cryptographic authentication mechanism (CRYPTO_AUTH) for IS-IS.
IS-IS在国际标准化组织（ISO）10589[ISO10589]中有规定，其扩展支持[RFC1195]中描述的互联网协议版本4（IPv4）。该规范包括允许任何身份验证算法的身份验证机制，还指定明文密码的算法。此外，[RFC5304]扩展了认证机制以与HMAC-MD5配合使用，并修改了基本协议以提高效率。[RFC5310]为IS-IS提供了新的通用加密身份验证机制（CRYPTO_AUTH），提供了算法灵活性。
CRYPTO_AUTH also introduces a Key ID mechanism that maps to unique IS-IS SAs.
CRYPTO_AUTH还引入了一种密钥ID机制，该机制映射到唯一的IS-IS SA。
The following sections describe the current authentication key usage for various IS-IS messages, current key change methodologies, and the various potential security threats.
以下各节介绍各种IS-IS消息的当前身份验证密钥使用情况、当前密钥更改方法以及各种潜在的安全威胁。
IS-IS can be provisioned with a per-interface, peer-to-peer key for IIH PDUs and a group key for LSPs and SNPs. If provisioned, IIH packets can potentially use the same group key used for LSPs and SNPs.
IS-IS可以配置每个接口、IIH PDU的对等密钥以及LSP和SNP的组密钥。如果设置，IIH数据包可能使用LSP和SNP使用的相同组密钥。
Link State PDUs, Complete and partial Sequence Number PDUs come under Sub network Independent messages. For protecting Level-1 SNPs and Level-1 LSPs, provisioned Area Authentication key is used. Level-2 SNPs as well as Level-2 LSPs use the provisioned domain authentication key.
链路状态PDU、完整和部分序列号PDU属于子网独立消息。为了保护1级SNP和1级LSP，使用了配置的区域身份验证密钥。二级SNP和二级LSP使用提供的域身份验证密钥。
Because authentication is performed on the LSPs transmitted by an IS, rather than on the LSP packets transmitted to a specific neighbor, it is implied that all the ISes within a single flooding domain must be configured with the same key in order for authentication to work correctly. This is also true for SNP packets, though they are limited to link-local scope in broadcast networks.
由于认证是在is传输的LSP上执行的，而不是在传输到特定邻居的LSP数据包上执行的，这意味着必须使用相同的密钥配置单个泛洪域内的所有ISE，以便认证正常工作。SNP数据包也是如此，尽管它们仅限于广播网络中的链路本地范围。
If multiple instances share the circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect the LSPs and SNPs within an area or domain. It is important to note that [RFC6822] also allows usage of topology-specific authentication credentials within an instance for the LSPs and SNPs.
如果多个实例共享[RFC6822]中指定的电路，则可以使用实例特定的身份验证凭据来保护区域或域内的LSP和SNP。需要注意的是，[RFC6822]还允许在LSP和SNP实例中使用特定于拓扑的身份验证凭据。
IIH PDUs use the Link Level Authentication key, which may be different from that of LSPs and SNPs. This could be particularly true for point-to-point links. In broadcast networks, it is possible to provision the same common key used for LSPs and SNPs to protect IIH messages. This allows neighbor discovery and adjacency formation with more than one neighbor on the same physical interface. If multiple instances share the circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect Hello messages.
IIH PDU使用链路级认证密钥，这可能不同于LSP和SNP的认证密钥。这对于点对点链接来说可能尤其如此。在广播网络中，可以为LSP和SNP提供相同的公共密钥来保护IIH消息。这允许在同一物理接口上发现多个邻居并形成邻居。如果多个实例共享[RFC6822]中指定的电路，则可以使用实例特定的身份验证凭据来保护Hello消息。
Key roll over without effecting the routing protocols operation in general and IS-IS in particular is necessary for effective key management protocol integration.
在不影响路由协议操作的情况下进行密钥翻转，特别是IS-IS对于有效的密钥管理协议集成是必要的。
Current HMAC-MD5 cryptographic authentication as defined in [RFC5304], suggests a transition mode so that ISes use a set of keys when verifying the authentication value to allow key changes. This approach will allow changing the authentication key manually without bringing down the adjacency and without dropping any control packet. But, this can increase the load on the control plane for the key transition duration, as each control packet may have to be verified by more than one key, and it also allows a potential DoS attack in the transition duration.
[RFC5304]中定义的当前HMAC-MD5加密身份验证建议一种转换模式，以便ISE在验证身份验证值以允许密钥更改时使用一组密钥。这种方法将允许手动更改身份验证密钥，而不会降低相邻性，也不会丢弃任何控制数据包。但是，这可能会增加密钥转换持续时间内控制平面上的负载，因为每个控制数据包可能必须由多个密钥进行验证，并且在转换持续时间内还允许潜在的DoS攻击。
The above situation is improved with the introduction of the Key ID mechanism as defined in [RFC5310]. With this, the receiver determines the active SA by looking at the Key ID field in the incoming PDU and need not try with other keys when the integrity check or digest verification fails. But, neither key coordination across the group nor an exact key change mechanism is clearly defined. [RFC5310] says:
通过引入[RFC5310]中定义的密钥ID机制，上述情况得到了改善。这样，接收器通过查看传入PDU中的密钥ID字段来确定活动SA，并且在完整性检查或摘要验证失败时不需要尝试使用其他密钥。但是，无论是整个集团的关键协调还是确切的关键变更机制都没有明确定义。[RFC5310]表示：
Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
通常，实现将允许网络运营商在密钥链中配置一组密钥，其中链中的每个密钥具有固定的生存期。这些机制的实际运作超出了本文件的范围。
The following section analyzes various possible security threats in the current state of the IS-IS protocol.
以下部分分析IS-IS协议当前状态下可能存在的各种安全威胁。
Replaying a captured protocol packet to cause damage is a common threat for any protocol. Securing the packet with cryptographic authentication information alone cannot mitigate this threat completely. Though this problem is more prevalent in broadcast networks, it is important to note that most of the IGP deployments use P2P-over-lan circuits [RFC5309], which makes it possible for an adversary to replay an IS-IS PDU more easily than the traditional P2P networks.
重放捕获的协议数据包以造成损坏是任何协议的常见威胁。仅使用加密身份验证信息保护数据包无法完全缓解此威胁。尽管这个问题在广播网络中更为普遍，但需要注意的是，大多数IGP部署使用局域网上的P2P电路[RFC5309]，这使得对手比传统P2P网络更容易重放is-is PDU。
In intra-session replay attacks, a secured protocol packet of the current session that is replayed can cause damage, if there is no other mechanism to confirm this is a replay packet. In inter-session
在会话内重播攻击中，如果没有其他机制确认当前会话的安全协议数据包是重播数据包，则重播的当前会话的安全协议数据包可能会造成损坏。闭会期间
replay attacks, a captured packet from one of the previous sessions can be replayed to cause damage. IS-IS packets are vulnerable to both of these attacks, as there is no sequence number verification for IIH and SNP packets. Also with current manual key management, periodic key changes across the group are rarely done. Thus, the intra-connection and inter-connection replay requirements are not met.
重播攻击，可以重播以前会话之一捕获的数据包以造成损害。IS-IS数据包容易受到这两种攻击，因为IIH和SNP数据包没有序列号验证。此外，在当前的手动密钥管理中，很少在整个组中进行定期密钥更改。因此，不满足连接内和连接间重播要求。
IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 family in [RFC5310] to protect IS-IS packets. An adversary could replay old IIHs or replay old SNPs that would cause churn in the network or bring down the adjacencies.
IS-IS指定使用[RFC5310]中的HMAC-MD5[RFC5304]和HMAC-SHA-1系列来保护IS-IS数据包。对手可以重放旧的iih或重放旧的snp，这些snp会导致网络中的混乱或破坏相邻网络。
1. At the time of adjacency bring up an IS sends IIH packet with empty neighbor list (TLV 6) and with the authentication information as per the provisioned authentication mechanism. If this packet is replayed later on the broadcast network, all ISes in the broadcast network can bounce the adjacency to create a huge churn in the network.
1. 在邻接启动时，IS发送具有空邻居列表（tlv6）和根据所提供的认证机制的认证信息的IIH分组。如果该数据包稍后在广播网络上重播，广播网络中的所有ISE都会反弹相邻部分，从而在网络中造成巨大的混乱。
2. Today, LSPs have intra-session replay protection as the LSP header contains a 32-bit sequence number, which is verified for every received packet against the local LSP database. But, if a node in the network is out of service (is undergoing some sort of high availability condition or an upgrade) for more than LSP refresh time and the rest of the network ages out the LSPs of the node under consideration, an adversary can potentially plunge in inter-session replay attacks in the network. If the key is not changed in the above circumstances, attack can be launched by replaying an old LSP with a higher sequence number and fewer prefixes or fewer adjacencies. This may force the receiver to accept and remove the routes from the routing table, which eventually causes traffic disruption to those prefixes. However, as per the IS-IS specification, there is a built-in recovery mechanism for LSPs from inter-session replay attacks and it is further discussed in Section 2.3.1.1.
2. 如今，LSP具有会话内重播保护，因为LSP报头包含一个32位序列号，该序列号针对每个接收到的数据包根据本地LSP数据库进行验证。但是，如果网络中的一个节点停止服务（正在经历某种高可用性条件或升级）超过LSP刷新时间，并且网络的其余部分使正在考虑的节点的LSP老化，则对手可能会在网络中陷入会话间重放攻击。如果在上述情况下密钥没有更改，则可以通过重放具有更高序列号、更少前缀或更少邻接的旧LSP来发起攻击。这可能会迫使接收方接受路由并从路由表中删除路由，最终导致这些前缀的通信中断。但是，根据IS-IS规范，有一种内置的LSP会话间重放攻击恢复机制，将在第2.3.1.1节中进一步讨论。
3. In any IS-IS network (broadcast or otherwise), if an old and an empty Complete Sequence Number Packet (CSNP) is replayed, this can cause LSP flood in the network. Similarly, a replayed Partial Sequence Number Packet (PSNP) can cause LSP flood in the broadcast network.
3. 在任何IS-IS网络（广播或其他）中，如果重播旧的空完整序列号数据包（CSNP），这可能导致网络中LSP泛滥。类似地，重播的部分序列号分组（PSNP）可在广播网络中引起LSP洪泛。
In the event of inter-session replay attack by an adversary, as an LSP with a higher sequence number gets accepted, it also gets propagated until it reaches the originating node of the LSP. The
在对手进行会话间重放攻击的情况下，随着序列号较高的LSP被接受，它也会被传播，直到到达LSP的原始节点。这个
originator recognizes the LSP is "newer" than in the local database, which prompts the originator to flood a newer version of the LSP with a higher sequence number than that received. This newer version can potentially replace any versions of the replayed LSP that may exist in the network.
发起人识别出LSP比本地数据库中的“新”，这会提示发起人使用比接收到的序列号更高的LSP更新版本。此较新版本可能会替换网络中可能存在的任何版本的重播LSP。
However, in the above process, depending on where in the network the replay is initiated, how quickly the nodes in the network react to the replayed LSP, and how different the content in the accepted LSP is determines the damage caused by the replayed LSP.
然而，在上述过程中，取决于重播在网络中的何处发起、网络中的节点对重播LSP的反应速度以及所接受LSP中的内容的不同程度，确定重播LSP造成的损害。
IS-IS shares the same key between all neighbors in an area or in a domain to protect the LSP, SNP packets, and in broadcast networks even IIH packets. False advertisement by a router is not within the scope of the KARP work. However, given the wide sharing of keys as described above, there is a significant risk that an attacker can compromise a key from one device and use it to falsely participate in the routing, possibly even in a very separate part of the network.
IS-IS在一个区域或域中的所有邻居之间共享相同的密钥，以保护LSP、SNP数据包，以及广播网络中甚至IIH数据包。路由器的虚假广告不在KARP工作范围内。然而，鉴于如上所述的密钥的广泛共享，存在一个重大风险，即攻击者可能会泄露来自一个设备的密钥，并使用它来错误地参与路由，甚至可能在网络的一个非常独立的部分。
If the same underlying topology is shared across multiple instances to transport routing/application information as defined in [RFC6822], it is necessary to use different authentication credentials for different instances. In this connection, based on the deployment considerations, if certain topologies in a particular IS-IS instance require more protection from spoofing attacks and less exposure, topology-specific authentication credentials can be used for LSPs and SNPs as facilitated in [RFC6822].
如果在多个实例之间共享相同的底层拓扑以传输[RFC6822]中定义的路由/应用程序信息，则有必要为不同的实例使用不同的身份验证凭据。在这方面，基于部署方面的考虑，如果特定IS-IS实例中的某些拓扑需要更多的保护以防止欺骗攻击和更少的暴露，则可以对LSP和SNP使用拓扑特定的身份验证凭据，如[RFC6822]中所述。
Currently, possession of the key itself is used as an authentication check and there is no identity check done separately. Spoofing occurs when an illegitimate device assumes the identity of a legitimate one. An attacker can use spoofing to launch various types of attacks, for example:
目前，密钥本身的拥有权被用作身份验证检查，并且没有单独进行身份检查。当非法设备具有合法设备的身份时，就会发生欺骗。攻击者可以使用欺骗来发起各种类型的攻击，例如：
1. The attacker can send out unrealistic routing information that might cause the disruption of network services, such as block holes.
1. 攻击者可以发送可能导致网络服务中断的不切实际的路由信息，如阻塞孔。
2. A rogue system that has access to the common key used to protect the LSP can flood an LSP by setting the Remaining Lifetime field to zero, thereby initiating a purge. Subsequently, this can cause the sequence number of all the LSPs to increase quickly to max out the sequence number space, which can cause an IS to shut down for MaxAge + ZeroAgeLifetime period to allow the old LSPs to age out in other ISes of the same flooding domain.
2. 可以访问用于保护LSP的公用密钥的恶意系统可以通过将剩余寿命字段设置为零来淹没LSP，从而启动清除。随后，这会导致所有LSP的序列号迅速增加，以最大化序列号空间，这会导致IS在MaxAge+ZeroAgeLifetime期间关闭，以允许旧LSP在相同泛洪域的其他IE中老化。
DoS attacks using the authentication mechanism is possible and an attacker can send packets that can overwhelm the security mechanism itself. An example is initiating an overwhelming load of spoofed but integrity-protected protocol packets, so that the receiver needs to process the integrity check, only to discard the packet. This can cause significant CPU usage. DoS attacks are not generally preventable within the routing protocol. As the attackers are often remote, the DoS attacks are more damaging to area-scoped or domain-scoped packet receivers than link-local-scoped packet receivers.
使用身份验证机制的DoS攻击是可能的，攻击者可以发送可能压倒安全机制本身的数据包。例如，启动大量伪造但受完整性保护的协议数据包，因此接收器需要处理完整性检查，而只是丢弃数据包。这可能会导致大量CPU使用。DoS攻击在路由协议中通常是不可预防的。由于攻击者通常是远程的，DoS攻击对区域范围或域范围的数据包接收器的破坏性比链路本地范围的数据包接收器更大。
This section outlines the differences between the current state of the IS-IS routing protocol and the desired state as specified in the KARP Design Guidelines [RFC6518]. This section focuses on where the IS-IS protocol fails to meet general requirements as specified in the threats and requirements document [RFC6862].
本节概述IS-IS路由协议的当前状态与KARP设计指南[RFC6518]中规定的期望状态之间的差异。本节重点介绍IS-IS协议无法满足威胁和要求文件[RFC6862]中规定的一般要求的地方。
This section also describes security requirements that should be met by IS-IS implementations that are secured by manual as well as automated key management protocols.
本节还描述了由手动和自动密钥管理协议保护的IS-IS实现应满足的安全要求。
1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be protected with the HMAC-SHA family of cryptographic algorithms. The specification provides limited algorithm agility (SHA family). By using Key IDs, it also conceals the algorithm information from the protected control messages.
1. 使用CRYPTO_AUTH规范[RFC5310]，IS-IS数据包可以使用HMAC-SHA系列加密算法进行保护。该规范提供了有限的算法灵活性（SHA系列）。通过使用密钥ID，它还可以从受保护的控制消息中隐藏算法信息。
2. Even though both intra- and inter-session replay attacks are best prevented by deploying key management protocols with frequent key change capability, basic constructs for the sequence number should be in the protocol messages. So, some basic or extended sequence number mechanism should be in place to protect IIH packets and SNP packets. The sequence number should be increased for each protocol packet. This allows mitigation of some of the replay threats as mentioned in Section 2.3.1.
2. 即使通过部署具有频繁密钥更改功能的密钥管理协议，可以最好地防止会话内和会话间重播攻击，但序列号的基本结构应该在协议消息中。因此，应该有一些基本的或扩展的序列号机制来保护IIH数据包和SNP数据包。每个协议包的序列号都应该增加。这允许缓解第2.3.1节中提到的一些重播威胁。
3. Any common key mechanism with keys shared across a group of routers is susceptible to spoofing attacks caused by a malicious router. A separate authentication check (apart from the integrity check to verify the digest) with digital signatures as described in [RFC2154] can effectively nullify this attack. But this approach was never deployed, which we assume is due to operational considerations at that time. The alternative approach to thwart
3. 任何在一组路由器之间共享密钥的公共密钥机制都容易受到恶意路由器造成的欺骗攻击。如[RFC2154]所述，使用数字签名进行单独的身份验证检查（除了验证摘要的完整性检查之外）可以有效地消除此攻击。但这种方法从未被部署，我们认为这是由于当时的运营考虑。挫败的替代方法
this threat would be to use the keys from the group key management protocol. As the group key(s) are generated by authenticating the member ISes in the group first and are then periodically rekeyed, per-packet identity or authentication checks may not be needed.
这种威胁是使用组密钥管理协议中的密钥。由于组密钥是通过首先认证组中的成员ise而生成的，然后周期性地重新设置密钥，因此可能不需要每个分组的身份或认证检查。
4. In general, DoS attacks may not be preventable with the mechanism from the routing protocol itself. But some form of admin-controlled lists at the forwarding plane can reduce the damage. There are some other forms of DoS attacks common to any protocol that are not in scope per Section 3.3 of [RFC6862].
4. 一般来说，通过路由协议本身的机制可能无法防止DoS攻击。但是转发平面上的某种形式的管理员控制列表可以减少损害。任何协议都有一些其他形式的DoS攻击，这些攻击不在[RFC6862]第3.3节规定的范围内。
As discussed in Section 2.2, though the Key ID mechanism described in [RFC5310] helps, a better key coordination mechanism for key roll over is desirable even with manual key management. But, [RFC5310] does not specify the exact mechanism other than requiring use of key chains. The specific requirements are as follows:
如第2.2节所述，尽管[RFC5310]中描述的密钥ID机制有所帮助，但即使使用手动密钥管理，也需要更好的密钥滚动协调机制。但是，[RFC5310]除了要求使用钥匙链之外，没有指定确切的机制。具体要求如下：
a. Keys SHOULD be able to change without effecting the established adjacency, ideally without any control packet loss.
a. 密钥应该能够在不影响已建立的邻接的情况下更改，理想情况下不会丢失任何控制数据包。
b. Keys SHOULD be able to change without effecting the protocol operations; for example, LSP flooding should not be held for a specific Key ID availability.
b. 密钥应能够在不影响协议操作的情况下进行更改；例如，对于特定的密钥ID可用性，不应保持LSP泛洪。
c. Any proposed mechanism SHOULD also be incrementally deployable with key management protocols.
c. 任何提议的机制也应该可以通过密钥管理协议进行增量部署。
In broadcast deployments, the keys used for protecting IS-IS protocols messages can, in particular, be group keys. A mechanism is needed to distribute group keys to a group of ISes in a Level-1 area or Level-2 domain, using the Group Domain of Interpretation (GDOI) protocol as specified in [RFC6407]. An example policy and payload format is described in [GDOI].
在广播部署中，用于保护IS-IS协议消息的密钥尤其可以是组密钥。需要一种机制，使用[RFC6407]中规定的组解释域（GDOI）协议，将组密钥分发到一级区域或二级域中的一组ISE。[GDOI]中描述了一个示例策略和有效负载格式。
If a group key is used, the authentication granularity becomes group membership of devices, not peer authentication between devices. The deployed group key management protocol SHOULD support rekeying.
如果使用组密钥，身份验证粒度将成为设备的组成员身份，而不是设备之间的对等身份验证。部署的组密钥管理协议应支持密钥更新。
In some deployments, where IS-IS point-to-point (P2P) mode is used for adjacency bring-up, subnetwork-dependent messages (e.g., IIHs) can use a different key shared between the two P2P peers, while all other messages use a group key. When a group keying mechanism is deployed, even the P2P IIHs can be protected with the common group keys. This approach facilitates one key management mechanism instead of both pair-wise keying and group keying protocols being deployed together. If the same circuits are shared across multiple instances,
在一些部署中，IS-IS点到点（P2P）模式用于邻接启动，子网相关消息（例如IIH）可以使用两个P2P对等点之间共享的不同密钥，而所有其他消息使用组密钥。当部署组密钥机制时，即使P2P iih也可以使用公共组密钥进行保护。这种方法简化了一种密钥管理机制，而不是同时部署成对密钥和组密钥协议。如果在多个实例中共享相同的回路，
the granularity of the group can become per instance for IIHs and per instance/topology for LSPs and SNPs as specified in [RFC6822].
按照[RFC6822]中的规定，组的粒度可以是IIH的每个实例，LSP和SNP的每个实例/拓扑。
Effective key change capability within the routing protocol that allows key roll over without impacting the routing protocol operation is one of the requirements for deploying any group key mechanism. Once such mechanism is in place with the deployment of group key management protocol; IS-IS can be protected from various threats and is not limited to intra- and inter-session replay attacks and spoofing attacks.
部署任何组密钥机制的要求之一是，路由协议中具有有效的密钥更改功能，允许密钥滚动而不影响路由协议的操作。一旦该机制到位，部署组密钥管理协议；IS-IS可以免受各种威胁，并且不限于会话内和会话间重播攻击和欺骗攻击。
Specific use of cryptographic tables [RFC7210] should be defined for the IS-IS protocol.
应为IS-IS协议定义加密表[RFC7210]的具体用途。
This document is mostly about security considerations of the IS-IS protocol, and it lists potential threats and security requirements for mitigating these threats. This document does not introduce any new security threats for the IS-IS protocol. In view of openly published attack vectors, as noted in Section 1 of [RFC5310] on HMAC-MD5 cryptographic authentication mechanism, IS-IS deployments SHOULD use the HMAC-SHA family [RFC5310] instead of HMAC-MD5 [RFC5304] to protect IS-IS PDUs. For more detailed security considerations, please refer the Security Considerations section of the IS-IS Generic Cryptographic Authentication [RFC5310], the KARP Design Guide [RFC6518] document, as well as the KARP threat document [RFC6862].
本文档主要介绍is-is协议的安全注意事项，并列出了缓解这些威胁的潜在威胁和安全要求。本文档不会为IS-IS协议引入任何新的安全威胁。鉴于公开发布的攻击向量，如[RFC5310]关于HMAC-MD5加密身份验证机制的第1节所述，IS-IS部署应使用HMAC-SHA系列[RFC5310]而不是HMAC-MD5[RFC5304]来保护IS-IS PDU。有关更详细的安全注意事项，请参阅IS-IS通用加密身份验证[RFC5310]、KARP设计指南[RFC6518]文档以及KARP威胁文档[RFC6862]的安全注意事项部分。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1195]Callon，R.“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 1195，DOI 10.17487/RFC1195，1990年12月<http://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，DOI 10.17487/RFC5304，2008年10月<http://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[GDOI] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, draft-weis-gdoi-mac-tek-03, September 2011.
[GDOI]Weis，B.和S.Rowles，“GDOI通用消息身份验证代码策略”，正在进行的工作，草稿-Weis-GDOI-mac-tek-032011年9月。
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002，第二版，2002年11月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June 1997, <http://www.rfc-editor.org/info/rfc2154>.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，DOI 10.17487/RFC2154，1997年6月<http://www.rfc-editor.org/info/rfc2154>.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.
[RFC5309]Shen，N.，Ed.，和A.Zinin，Ed.，“链路状态路由协议下局域网上的点对点操作”，RFC 5309，DOI 10.17487/RFC5309，2008年10月<http://www.rfc-editor.org/info/rfc5309>.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, <http://www.rfc-editor.org/info/rfc6039>.
[RFC6039]Manral，V.，Bhatia，M.，Jaeggli，J.，和R.White，“路由协议现有加密保护方法的问题”，RFC 6039，DOI 10.17487/RFC6039，2010年10月<http://www.rfc-editor.org/info/rfc6039>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, <http://www.rfc-editor.org/info/rfc6407>.
[RFC6407]Weis，B.，Rowles，S.，和T.Hardjono，“解释的集团领域”，RFC 6407，DOI 10.17487/RFC6407，2011年10月<http://www.rfc-editor.org/info/rfc6407>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, DOI 10.17487/RFC6518, February 2012, <http://www.rfc-editor.org/info/rfc6518>.
[RFC6518]Lebovitz，G.和M.Bhatia，“路由协议的键控和认证（KARP）设计指南”，RFC 6518，DOI 10.17487/RFC6518，2012年2月<http://www.rfc-editor.org/info/rfc6518>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>.
[RFC6822]Previdi，S.，Ed.，Ginsberg，L.，Shand，M.，Roy，A.，和D.Ward，“IS-IS多实例”，RFC 6822，DOI 10.17487/RFC6822，2012年12月<http://www.rfc-editor.org/info/rfc6822>.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, DOI 10.17487/RFC6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.
[RFC6862]Lebovitz，G.，Bhatia，M.和B.Weis，“路由协议（KARP）的键控和认证概述，威胁和要求”，RFC 6862，DOI 10.17487/RFC6862，2013年3月<http://www.rfc-editor.org/info/rfc6862>.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, DOI 10.17487/RFC7210, April 2014, <http://www.rfc-editor.org/info/rfc7210>.
[RFC7210]Housley，R.，Polk，T.，Hartman，S.，和D.Zhang，“长寿命对称加密密钥数据库”，RFC 7210，DOI 10.17487/RFC7210，2014年4月<http://www.rfc-editor.org/info/rfc7210>.
Acknowledgements
致谢
Authors would like to thank Joel Halpern for initial discussions on this document and for giving valuable review comments. The authors would like to acknowledge Naiming Shen for reviewing and providing feedback on this document. Thanks to Russ White, Brian Carpenter, and Amanda Barber for reviewing the document during the IESG review process.
作者要感谢Joel Halpern对本文件进行的初步讨论，并给出了宝贵的评论。作者感谢沈乃明对本文件的审查和反馈。感谢Russ White、Brian Carpenter和Amanda Barber在IESG审查过程中审查了该文件。
Authors' Addresses
作者地址
Uma Chunduri Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Phone: 408 750-5678 Email: uma.chunduri@ericsson.com
Uma Chunduri Ericsson Inc.加利福尼亚州圣何塞市霍尔格路300号，邮编95134美国电话：408 750-5678电子邮件：Uma。chunduri@ericsson.com
Albert Tian Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Phone: 408 750-5210 Email: albert.tian@ericsson.com
Albert Tian Ericsson Inc.加利福尼亚州圣何塞市霍尔格路300号95134美国电话：408 750-5210电子邮件：Albert。tian@ericsson.com
Wenhu Lu Ericsson Inc. 300 Holger Way, San Jose, California 95134 United States Email: wenhu.lu@ericsson.com
文湖路爱立信有限公司，加利福尼亚州圣何塞市霍尔格路300号，邮编95134，美国电子邮件：文湖。lu@ericsson.com