Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 6863 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
March 2013
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 6863 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
March 2013
Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
根据路由协议的密钥和认证（KARP）设计指南分析OSPF的安全性
Abstract
摘要
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
本文件根据“路由协议（KARP）设计指南”（RFC 6518）第4.2节规定的指南分析OSPFv2和OSPFv3。本文件中确定的差距解决方案的关键组成部分已经在进行中。
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/rfc6863.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6863.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 6
4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 7
5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements to Meet . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Impacts of OSPF Replays . . . . . . . . . . . . . . . . . . . 6
4. Gap Analysis and Specific Requirements . . . . . . . . . . . . 7
5. Solution Work . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
This document analyzes the current state of OSPFv2 and OSPFv3 according to the requirements of [RFC6518]. It builds on several previous analysis efforts regarding routing security. The OPSEC working group put together an analysis of cryptographic issues with routing protocols [RFC6039]. Earlier, the RPSEC working group put together a detailed analysis of OSPF vulnerabilities [OSPF-SEC]. Work on solutions to address gaps identified in this analysis is underway [OSPF-MANKEY] [RFC6506].
本文件根据[RFC6518]的要求分析OSPFv2和OSPFv3的当前状态。它建立在之前关于路由安全性的几项分析工作的基础上。OPSEC工作组对路由协议的加密问题进行了分析[RFC6039]。早些时候，RPSEC工作组对OSPF漏洞进行了详细分析[OSPF-SEC]。解决本分析中发现的差距的解决方案工作正在进行[OSPF-MANKEY][RFC6506]。
OSPF meets many of the requirements expected from a manually keyed routing protocol. Integrity protection is provided with modern cryptographic algorithms. Algorithm agility is provided: the algorithm can be changed as part of rekeying an interface or peer. Intra-connection rekeying is provided by the specifications, although apparently some implementations have trouble with this in practice. OSPFv2 security does not interfere with prioritization of packets.
OSPF满足了手动键控路由协议的许多要求。完整性保护由现代密码算法提供。提供了算法敏捷性：算法可以作为重新设置接口或对等节点密钥的一部分进行更改。连接内密钥更新是由规范提供的，尽管显然有些实现在实践中遇到了问题。OSPFv2安全性不会干扰数据包的优先级。
However, some gaps remain between the current state and the requirements for manually keyed routing security expressed in [RFC6862]. This document explores these gaps and proposes directions for addressing the gaps.
然而，当前状态与[RFC6862]中所述的手动键控路由安全性要求之间仍存在一些差距。本文件探讨了这些差距，并提出了解决这些差距的方向。
There are a number of requirements described in Section 3 of [RFC6862] that OSPF does not currently meet. The gaps are as follows:
[RFC6862]第3节中描述了OSPF目前不满足的许多要求。差距如下：
o Secure Simple Pre-Shared Keys (PSKs): Today, OSPF directly uses the key as specified. Related key attacks, such as those described in Section 4.1 of [OPS-MODEL], are possible.
o 安全简单预共享密钥（PSK）：如今，OSPF直接使用指定的密钥。相关的密钥攻击，如[OPS-MODEL]第4.1节所述，是可能的。
o Replay Protection: The requirements document addresses requirements for both inter-connection replay protection and intra-connection replay protection. OSPFv3 has no replay protection at all. OSPFv2 has most of the mechanisms necessary for intra-connection replay protection. Unfortunately, OSPFv2 does not securely identify the neighbor with whom replay protection state is associated in all cases. This weakness can be used to create significant denial-of-service issues using intra-connection replays. OSPFv2 has no inter-connection replay protection; this creates significant denial-of-service opportunities.
o 重播保护：需求文档说明了连接间重播保护和连接内重播保护的需求。OSPFv3根本没有重播保护。OSPFv2具有连接内重播保护所需的大部分机制。不幸的是，OSPFv2在所有情况下都不能安全地识别重播保护状态关联的邻居。此弱点可用于使用连接内重播造成严重的拒绝服务问题。OSPFv2没有连接间重放保护；这会造成严重的拒绝服务机会。
o Packet Prioritization: OSPFv3 uses IPsec [RFC4301] to process packets. This complicates implementations that wish to process some packets, such as Hellos and Acknowledgements, above others. In addition, if IPsec replay mechanisms were used, packets would need to be processed at least by IPsec even if they were low priority.
o 数据包优先级：OSPFv3使用IPsec[RFC4301]处理数据包。这使得希望处理某些数据包（如Hellos和确认）的实现比处理其他数据包更复杂。此外，如果使用IPsec重播机制，则即使数据包的优先级较低，也至少需要IPsec来处理。
o Neighbor Identification: In some cases, OSPF identifies a neighbor based on the IP address. This operation is never protected with OSPFv2 and is not typically protected with OSPFv3.
o 邻居识别：在某些情况下，OSPF根据IP地址识别邻居。此操作从不受OSPFv2保护，通常不受OSPFv3保护。
The remainder of this document explains how OSPF fails to meet these requirements, and it proposes mechanisms for addressing them.
本文档的其余部分解释了OSPF如何无法满足这些要求，并提出了解决这些要求的机制。
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]中所述进行解释。
This section describes the security mechanisms built into OSPFv2 and OSPFv3. There are two goals to this section. First, this section gives a brief explanation of the OSPF security mechanisms to those familiar with connectionless integrity mechanisms but not with OSPF.
本节介绍OSPFv2和OSPFv3中内置的安全机制。本节有两个目标。首先，本节向那些熟悉无连接完整性机制但不熟悉OSPF的人简要解释OSPF安全机制。
Second, this section provides the background necessary to understand how OSPF fails to meet some of the requirements proposed for routing security.
其次，本节提供了必要的背景知识，以了解OSPF如何无法满足路由安全的一些建议要求。
Appendix D of [RFC2328] describes the basic procedure for cryptographic authentication in OSPFv2. An authentication data field in the OSPF packet header contains a key ID, the length of the authentication data, and a sequence number. A Message Authentication Code (MAC) is appended to the OSPF packet. This code protects all fields of the packet including the sequence number but not the IP header.
[RFC2328]的附录D描述了OSPFv2中加密身份验证的基本过程。OSPF分组报头中的认证数据字段包含密钥ID、认证数据的长度和序列号。消息认证码（MAC）附加到OSPF数据包。此代码保护数据包的所有字段，包括序列号，但不保护IP报头。
RFC 2328 defines the use of a keyed-MD5 MAC. While MD5 has not been broken as a MAC, it is not the algorithm of choice for new MACs.
RFC 2328定义了键控MD5 MAC的使用。虽然MD5还没有作为MAC被打破，但它不是新MAC的首选算法。
However, RFC 5709 [RFC5709] adds support for the SHA family of hashes [FIPS180] to OSPFv2. The cryptographic authentication described in RFC 5709 meets modern standards for per-packet integrity protection. Thus, OSPFv2 meets the requirement for strong algorithms. Since multiple algorithms are defined and a new algorithm can be selected with each key, OSPFv2 meets the requirement for algorithm agility. In order to provide cryptographic algorithms believed to have a relatively long useful life, RFC 5709 mandates support for SHA-2 rather than SHA-1.
但是，RFC5709[RFC5709]将对SHA哈希家族[FIPS180]的支持添加到OSPFv2中。RFC 5709中描述的加密身份验证符合每包完整性保护的现代标准。因此，OSPFv2满足强算法的要求。由于定义了多个算法，并且每个密钥都可以选择一个新算法，因此OSPFv2满足了算法敏捷性的要求。为了提供被认为具有相对较长使用寿命的密码算法，RFC 5709要求支持SHA-2而不是SHA-1。
These security services provide integrity protection on each packet. In addition, limited replay detection is provided. The sequence number is non-decreasing. So, once a router has increased its sequence number, an attacker cannot replay an old packet. Unfortunately, sequence numbers are not required to increase for each packet. For instance, because existing OSPF security solutions do not specify how to set the sequence number, it is possible that some implementations use, for example, "seconds since reboot" as their sequence numbers. The sequence numbers are thus increased only every second, permitting an opportunity for intra-connection replay. Also, no mechanism is provided to deal with the loss of anti-replay state; if sequence numbers are reused when a router reboots, then inter-connection replays are straight forward. In [OSPF-MANKEY], the OSPFv2 sequence number is expanded to 64 bits, with the least significant 32-bit value containing a strictly increasing sequence number and the most significant 32-bit value containing the boot count. The boot count is retained in non-volatile storage for the deployment life of an OSPF router. Therefore, the sequence number will never decrease, even after a cold reboot.
这些安全服务为每个数据包提供完整性保护。此外，还提供了有限的重播检测。序列号是非递减的。因此，一旦路由器增加了其序列号，攻击者就无法重播旧数据包。不幸的是，序列号不需要为每个数据包增加。例如，由于现有的OSPF安全解决方案没有指定如何设置序列号，因此一些实现可能会使用，例如，“重新启动后的秒数”作为序列号。因此，序列号仅每秒增加一次，从而允许连接内重播的机会。此外，没有提供任何机制来处理防重放状态的丢失；如果在路由器重新启动时重复使用序列号，则连接间重放是直接进行的。在[OSPF-MANKEY]中，OSPFv2序列号扩展为64位，最低有效32位值包含严格递增的序列号，最高有效32位值包含引导计数。在OSPF路由器的部署生命周期内，引导计数保留在非易失性存储器中。因此，即使在冷重启后，序列号也不会减少。
Also, because the IP header is not protected, the sequence number may not be associated with the correct neighbor, a situation that opens up opportunities for outsiders to perform replay attacks. See Section 3 for analysis of these attacks. In [OSPF-MANKEY], this issue is addressed by changing the definition of Apad from a constant defined in [RFC5709] to the source address in the IP header of the OSPFv2 protocol packet. In this way, the source address from the IP header is incorporated in the cryptographic authentication computation, and any change of the IP source address will be detected.
此外，由于IP报头未受保护，序列号可能与正确的邻居不关联，这种情况为外部人员执行重播攻击提供了机会。有关这些攻击的分析，请参见第3节。在[OSPF-MANKEY]中，通过将Apad的定义从[RFC5709]中定义的常量更改为OSPFv2协议包的IP报头中的源地址来解决此问题。这样，来自IP报头的源地址被合并到加密身份验证计算中，并且IP源地址的任何更改都将被检测到。
The mechanism provides good support for key rollover. There is a key ID. In addition, mechanisms are described for managing key lifetimes and starting the use of a new key in an orderly manner. Performing orderly key rollover requires that implementations support accepting a new key for received packets before using that key to generate packets. Section D.3 of RFC 2328 requires this support in the form of four configurable lifetimes for each key: two lifetimes control the beginning and ending period for acceptance, while two other lifetimes control the beginning and ending period for generation. These lifetimes provide a superset of the functionality in the key table [CRYPTO-KEYS] regarding lifetime.
该机制为键翻转提供了良好的支持。有一个密钥ID。此外，还描述了管理密钥生命周期和有序地开始使用新密钥的机制。执行有序密钥滚动需要实现支持在使用该密钥生成数据包之前接受接收到的数据包的新密钥。RFC 2328第D.3节要求以每个密钥四个可配置生命周期的形式提供这种支持：两个生命周期控制验收的开始和结束周期，而另外两个生命周期控制生成的开始和结束周期。这些生存期提供了密钥表[CRYPTO-KEYS]中有关生存期的功能超集。
The OSPFv2 replay mechanism does not handle prioritized transmission of OSPF Hello and Link State Acknowledgement (LSA) packets as recommended in [RFC4222]. When OSPF packets are transmitted with varied prioritization, they can arrive out of order, which results in packets with lower prioritization being discarded.
OSPFv2重播机制不处理[RFC4222]中建议的OSPF Hello和链路状态确认（LSA）数据包的优先传输。当以不同优先级传输OSPF数据包时，它们可能会无序到达，从而导致优先级较低的数据包被丢弃。
"Authentication/Confidentiality for OSPFv3" [RFC4552] describes how the IPsec authentication header and encapsulating security payload mechanism can be used to protect OSPFv3 packets. This mechanism provides per-packet integrity and optional confidentiality using a wide variety of cryptographic algorithms. Because OSPF uses multicast traffic, only manual key management is supported. This mechanism meets requirements related to algorithm selection and agility.
“OSPFv3的身份验证/机密性”[RFC4552]描述了如何使用IPsec身份验证头和封装安全负载机制来保护OSPFv3数据包。该机制使用多种密码算法提供每个数据包的完整性和可选的机密性。由于OSPF使用多播通信，因此仅支持手动密钥管理。该机制满足与算法选择和灵活性相关的要求。
The Security Parameter Index (SPI) [RFC4301] provides an identifier for the security association. This identifier, along with other IPsec facilities, provides a mechanism for moving from one key to another, meeting the key rollover requirements.
安全参数索引（SPI）[RFC4301]为安全关联提供标识符。此标识符与其他IPsec设施一起，提供了一种从一个密钥移动到另一个密钥的机制，以满足密钥翻转要求。
Because manual keying is used, no replay protection is provided for OSPFv3. Thus, the intra-connection and inter-connection replay requirements are not met.
由于使用了手动键控，因此OSPFv3不提供重放保护。因此，不满足连接内和连接间重播要求。
There is another serious problem with the OSPFv3 security: rather than being integrated into OSPF, it is based on IPsec. In practice, this has lead to deployment problems.
OSPFv3安全性还有另一个严重问题：它不是集成到OSPF中，而是基于IPsec。实际上，这会导致部署问题。
OSPF implementations generally prioritize packets in order to minimize disruption when router resources such as CPU or memory experience contention. When IPsec is used with OSPFv3, the offset of the packet type, which is used to prioritize packets, depends on which integrity transform is used. For this reason, prioritizing packets may be more complex for OSPFv3. One approach is to establish per-SPI filters to find the packet type and then act accordingly.
OSPF实现通常会优先考虑数据包，以便在路由器资源（如CPU或内存）发生争用时将中断降至最低。当IPsec与OSPFv3一起使用时，用于对数据包进行优先级排序的数据包类型的偏移量取决于所使用的完整性转换。因此，对于OSPFv3，对数据包进行优先级排序可能更复杂。一种方法是建立每个SPI过滤器来查找数据包类型，然后相应地采取行动。
As discussed, neither version of OSPF meets the requirements of inter-connection or intra-connection replay protection. In order to mount a replay, an attacker needs some mechanism to inject a packet. Physical security can limit a particular deployment's vulnerability to replay attacks. This section discusses the impacts of OSPF replays.
如前所述，OSPF的两个版本都不满足连接间或连接内重放保护的要求。为了装载重播，攻击者需要某种机制来注入数据包。物理安全性可以限制特定部署对重播攻击的漏洞。本节讨论OSPF重播的影响。
In OSPFv2, two facilities limit the scope of replay attacks. First, when cryptographic authentication is used, each packet includes a sequence number that is non-decreasing. In the current specifications, the sequence number is remembered as part of an adjacency: if an attacker can cause an adjacency to go down, then replay state is lost. Database Description packets also include a per-LSA sequence number that is part of the information that is flooded. Even if a packet is replayed, the per-LSA sequence number will prevent an old LSA from being installed. Unlike the per-packet sequence number, the per-LSA sequence number must increase when an LSA is changed. As a result, replays cannot be used to install old routing information.
在OSPFv2中，有两种功能限制了重放攻击的范围。首先，当使用密码认证时，每个数据包包括一个非递减的序列号。在当前规范中，序列号作为邻接的一部分被记住：如果攻击者可以导致邻接下降，那么重播状态将丢失。数据库描述数据包还包括每个LSA序列号，该序列号是被淹没信息的一部分。即使重播数据包，每个LSA序列号也会阻止安装旧LSA。与每包序列号不同，每LSA序列号在LSA更改时必须增加。因此，Replay无法用于安装旧的路由信息。
While the LSA sequence number provides some defense, the Routing Protocol Security Requirements (RPSEC) analysis [OSPF-SEC] describes a number of attacks that are possible because of per-packet replays. The most serious appear to be attacks against Hello packets, which may cause an adjacency to fail. Other attacks may cause excessive flooding or excessive use of CPU.
虽然LSA序列号提供了一些防御，但路由协议安全要求（RPSEC）分析[OSPF-SEC]描述了由于每包重放而可能发生的许多攻击。最严重的似乎是针对Hello数据包的攻击，这可能会导致邻接失败。其他攻击可能会导致CPU过度泛滥或过度使用。
Another serious attack concerns Database Description packets. In addition to the per-packet sequence number that is part of cryptographic authentication for OSPFv2 and the per-LSA sequence numbers, Database Description packets also include a Database Description sequence number. If a Database Description packet with the incorrect sequence number is received, then the database exchange process will be restarted.
另一个严重的攻击涉及数据库描述数据包。除了作为OSPFv2加密身份验证的一部分的每个数据包序列号和每个LSA序列号之外，数据库描述数据包还包括数据库描述序列号。如果收到序列号不正确的数据库描述数据包，则将重新启动数据库交换进程。
The per-packet OSPFv2 sequence number can be used to reduce the window in which a replay is valid. A receiver will harmlessly reject a packet whose per-packet sequence number is older than the one most recently received from a neighbor. Replaying the most recent packet from a neighbor does not appear to create problems. So, if the per-packet sequence number is incremented on every packet sent, then replay attacks should not disrupt OSPFv2. Unfortunately, OSPFv2 does not have a procedure for dealing with sequence numbers reaching the maximum value. It may be possible to figure out a set of rules sufficient to disrupt the damage of packet replays while minimizing the use of the sequence number space.
每包OSPFv2序列号可用于减少重播有效的窗口。接收器将无害地拒绝每个包序列号早于最近从邻居接收的包序列号的包。重播邻居最近的数据包似乎不会产生问题。因此，如果每个发送的数据包上的每个数据包序列号都增加，则重播攻击不应中断OSPFv2。不幸的是，OSPFv2没有处理序列号达到最大值的过程。在最小化序列号空间的使用的同时，可以找出一组足以中断数据包重放的破坏的规则。
As mentioned previously, when an adjacency is dropped, replay state is lost. So, after rebooting or when all adjacencies are lost, a router may allow its sequence number to decrease. An attacker can cause significant damage by replaying a packet captured before the sequence number decrease at a time after the sequence number decrease. If this happens, then the replayed packet will be accepted and the sequence number will be updated. However, the legitimate sender will be using a lower sequence number, so legitimate packets will be rejected. A similar attack is possible in cases where OSPF identifies a neighbor based on source address. An attacker can change the source address of a captured packet and replay it. If the attacker causes a replay from a neighbor with a high sequence number to appear to be from a neighbor with a low sequence number, then connectivity with that neighbor will be disrupted until the adjacency fails.
如前所述，删除邻接时，重播状态将丢失。因此，重新启动后或当所有邻接丢失时，路由器可能会允许其序列号减少。攻击者可以在序列号减少后的某个时间重放在序列号减少之前捕获的数据包，从而造成重大损害。如果发生这种情况，则将接受重播的数据包，并更新序列号。但是，合法发送方将使用较低的序列号，因此合法数据包将被拒绝。在OSPF根据源地址识别邻居的情况下，也可能发生类似的攻击。攻击者可以更改捕获的数据包的源地址并重播该数据包。如果攻击者使序列号高的邻居的重播看起来像是序列号低的邻居的重播，则与该邻居的连接将中断，直到邻接失败。
OSPFv3 lacks the per-packet sequence number but has the per-LSA sequence number. As such, OSPFv3 has no defense against denial-of-service attacks that exploit replay.
OSPFv3缺少每包序列号，但具有每LSA序列号。因此，OSPFv3无法抵御利用replay进行的拒绝服务攻击。
The design guide requires each design team to enumerate a set of requirements for the routing protocol. The only concerns identified with OSPF are areas in which it fails to meet the general requirements outlined in the threats and requirements document. This section explains how some of these general requirements map specifically onto the OSPF protocol and enumerates the specific gaps that need to be addressed.
设计指南要求每个设计团队列举路由协议的一组要求。OSPF发现的唯一问题是其未能满足威胁和要求文件中概述的一般要求的领域。本节解释了其中一些一般要求如何具体映射到OSPF协议，并列举了需要解决的具体差距。
There is a general requirement for inter-connection replay protection. In the context of OSPF, this means that if an adjacency goes down between two neighbors and later is re-established, replaying packets from before the adjacency went down cannot disrupt the adjacency. In the context of OSPF, intra-connection replay protection means that replaying a packet cannot prevent an adjacency
对连接间重播保护有一个一般要求。在OSPF的上下文中，这意味着如果两个邻居之间的邻接发生故障，然后重新建立，则重播邻接发生故障之前的数据包不能中断邻接。在OSPF的上下文中，连接内重放保护意味着重放数据包不能防止相邻
from forming or cannot disrupt an existing adjacency. In terms of meeting the requirements for intra-connection and inter-connection replay protection, a significant gap exists between the optimal state and where OSPF is today.
不能形成或不能破坏现有的邻接关系。在满足连接内和连接间重放保护的要求方面，最佳状态与OSPF目前的状态之间存在着巨大的差距。
Since OSPF uses fields in the IP header, the general requirement to protect the IP header and handle neighbor identification applies. This is another gap that needs to be addressed. Because the replay protection will depend on neighbor identification, the replay protection cannot be adequately addressed without handling this issue as well.
由于OSPF使用IP报头中的字段，因此保护IP报头和处理邻居标识的一般要求适用。这是另一个需要解决的差距。由于重播保护将取决于邻居标识，因此如果不处理此问题，重播保护将无法得到充分解决。
In order to encourage deployment of OSPFv3 security, an authentication option is required that does not have the deployment challenges of IPsec.
为了鼓励部署OSPFv3安全性，需要一个没有IPsec部署挑战的身份验证选项。
In order to support the requirement for simple pre-shared keys, OSPF needs to make sure that when the same key is used for two different purposes, no problems result.
为了支持对简单预共享密钥的要求，OSPF需要确保当同一密钥用于两个不同目的时，不会产生任何问题。
In order to support packet prioritization, it is desirable for the information needed to prioritize OSPF packets (the packet type) to be at a constant location in the packet.
为了支持分组优先化，期望将优先化OSPF分组（分组类型）所需的信息位于分组中的恒定位置。
It is recommended that the OSPF Working Group develop a solution for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. This solution would have the following improvements over the existing OSPFv2 option:
建议OSPF工作组基于OSPFv2加密认证选项为OSPFv2和OSPFv3开发解决方案。与现有OSPFv2选项相比，此解决方案将有以下改进：
Address most inter-connection replay attacks by splitting the sequence number and requiring preservation of state so that the sequence number increases on every packet.
通过拆分序列号并要求保留状态以使每个数据包上的序列号增加，来解决大多数连接间重播攻击。
Add a form of simple key derivation so that if the same pre-shared key is used for OSPF and other purposes, cross-protocol attacks do not result.
添加一种简单的密钥派生形式，以便如果相同的预共享密钥用于OSPF和其他目的，则不会导致跨协议攻击。
Support OSPFv3 authentication without use of IPsec.
支持OSPFv3身份验证，无需使用IPsec。
Specify processing rules sufficient to permit replay detection and packet prioritization.
指定足以允许重播检测和数据包优先级的处理规则。
Emphasize requirements already present in the OSPF specification sufficient to permit key migration without disrupting adjacencies.
强调OSPF规范中已经存在的要求，这些要求足以允许密钥迁移而不中断相邻。
Specify the proper use of the key table for OSPF.
指定OSPF密钥表的正确使用。
Protect the source IP address.
保护源IP地址。
Require that sequence numbers be incremented on each packet.
要求每个数据包上的序列号递增。
The key components of this solution work are already underway. OSPFv3 now supports an authentication option [RFC6506] that meets the requirements of this section; however, this document does not describe how the key tables are used for OSPF. OSPFv2 is being enhanced [OSPF-MANKEY] to protect the source address, provide inter-connection replay and describe how to use the key table.
这项解决方案工作的关键组成部分已经在进行中。OSPFv3现在支持符合本节要求的身份验证选项[RFC6506]；然而，本文档并未描述如何将密钥表用于OSPF。OSPFv2正在增强[OSPF-MANKEY]，以保护源地址，提供连接间重播，并描述如何使用密钥表。
This memo discusses and compiles vulnerabilities in the existing OSPF cryptographic handling.
本备忘录讨论并编译现有OSPF加密处理中的漏洞。
In analyzing proposed improvements to OSPF per-packet security, it is desirable to consider how these improvements interact with potential improvements in overall routing security. For example, the impact of replay attacks currently depends on the LSA sequence number mechanism. If cryptographic protections against insider attackers are considered by future work, then that work will need to provide a solution that meets the needs of the per-packet replay defense as well as protects routing data from insider attack. An experimental solution is discussed in [RFC2154] that explores end-to-end protection of routing data in OSPF. It may be beneficial to consider how improvements to the per-packet protections would interact with such a mechanism to future-proof these mechanisms.
在分析对每个包安全性提出的OSPF改进时，需要考虑这些改进如何与整体路由安全性的潜在改进相互作用。例如，重播攻击的影响目前取决于LSA序列号机制。如果未来的工作考虑了针对内部攻击者的加密保护，那么该工作将需要提供满足每包重放防御需要的解决方案，并保护路由数据免受内部攻击。[RFC2154]中讨论了一个实验解决方案，该方案探索了OSPF中路由数据的端到端保护。考虑每个分组保护的改进将如何与这样的机制交互以证明这些机制是有益的。
Implementations have a number of options in minimizing the potential denial-of-service impact of OSPF cryptographic authentication. The Generalized TTL Security Mechanism (GTSM) [RFC5082] might be appropriate for OSPF packets except for those traversing virtual links. Using this mechanism requires support of the sender; new OSPF cryptographic authentication could specify this behavior if desired. Alternatively, implementations can limit the source addresses from which they accept packets. Non-Hello packets need only be accepted from existing neighbors. If a system is under attack, Hello packets from existing neighbors could be prioritized over Hello packets from new neighbors. These mechanisms can be considered to limit the potential impact of denial-of-service attacks on the cryptographic authentication mechanism itself.
在最小化OSPF加密身份验证的潜在拒绝服务影响方面，实现有许多选项。通用TTL安全机制（GTSM）[RFC5082]可能适用于OSPF数据包，但穿越虚拟链路的数据包除外。使用此机制需要发送方的支持；如果需要，新的OSPF加密身份验证可以指定此行为。或者，实现可以限制从中接受数据包的源地址。非Hello数据包只需要从现有邻居处接受。如果系统受到攻击，来自现有邻居的Hello数据包的优先级可能高于来自新邻居的Hello数据包。可以考虑使用这些机制来限制拒绝服务攻击对加密身份验证机制本身的潜在影响。
Funding for Sam Hartman's work on this memo was provided by Huawei.
Sam Hartman撰写此备忘录的资金由华为提供。
The authors would like to thank Ran Atkinson, Michael Barnes, and Manav Bhatia for valuable comments.
作者要感谢Ran Atkinson、Michael Barnes和Manav Bhatia的宝贵评论。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年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月。
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013.
[RFC6862]Lebovitz，G.，Bhatia，M.和B.Weis，“路由协议的密钥和认证（KARP）概述，威胁和要求”，RFC 6862，2013年3月。
[CRYPTO-KEYS] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2012.
[加密密钥]Housley，R.，Polk，T.，Hartman，S.，和D.Zhang，“长寿命对称加密密钥数据库”，正在进行的工作，2012年10月。
[FIPS180] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2002.
[FIPS180]美国国家标准与技术研究所，“安全哈希标准（SHS）”，2002年8月。
[OPS-MODEL] Hartman, S. and D. Zhang, "Operations Model for Router Keying", Work in Progress, October 2012.
[OPS-MODEL]Hartman，S.和D.Zhang，“路由器键控操作模型”，正在进行的工作，2012年10月。
[OSPF-MANKEY] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, October 2012.
[OSPF-MANKEY]Bhatia，M.，Hartman，S.，Zhang，D.，和A.Lindem，“使用手动密钥管理时OSPFv2的安全扩展”，正在进行的工作，2012年10月。
[OSPF-SEC] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress, June 2006.
[OSPF-SEC]Jones，E.和O.Moigne，“OSPF安全漏洞分析”，正在进行的工作，2006年6月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", BCP 112, RFC 4222, October 2005.
[RFC4222]Choudhury，G.“特定OSPF版本2数据包的优先处理和拥塞避免”，BCP 112，RFC 4222，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 5709，2009年10月。
[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月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3的支持认证拖车”，RFC 65062012年2月。
Authors' Addresses
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
EMail: hartmans-ietf@mit.edu
URI: http://www.painless-security.com/
EMail: hartmans-ietf@mit.edu
URI: http://www.painless-security.com/
Dacheng Zhang Huawei Technologies Co., Ltd. Huawei Building No. 3 Xinxi Rd. Shang-Di Information Industrial Base Hai-Dian District, Beijing China
张大成华为技术有限公司中国北京市海淀区上地信息产业基地新西路3号华为大厦
EMail: zhangdacheng@huawei.com
EMail: zhangdacheng@huawei.com