Network Working Group M. Gupta
Request for Comments: 4552 Tropos Networks
Category: Standards Track N. Melam
Juniper Networks
June 2006
Network Working Group M. Gupta
Request for Comments: 4552 Tropos Networks
Category: Standards Track N. Melam
Juniper Networks
June 2006
Authentication/Confidentiality for OSPFv3
OSPFv3的身份验证/机密性
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header.
本文档描述了使用IPv6身份验证头/封装安全有效负载（AH/ESP）扩展头向OSPFv3提供身份验证/机密性的方法和机制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Transport Mode vs. Tunnel Mode ..................................3
3. Authentication ..................................................3
4. Confidentiality .................................................3
5. Distinguishing OSPFv3 from OSPFv2 ...............................4
6. IPsec Requirements ..............................................4
7. Key Management ..................................................5
8. SA Granularity and Selectors ....................................7
9. Virtual Links ...................................................8
10. Rekeying .......................................................9
10.1. Rekeying Procedure ........................................9
10.2. KeyRolloverInterval .......................................9
10.3. Rekeying Interval ........................................10
11. IPsec Protection Barrier and SPD ..............................10
12. Entropy of Manual Keys ........................................12
13. Replay Protection .............................................12
14. Security Considerations .......................................12
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Transport Mode vs. Tunnel Mode ..................................3
3. Authentication ..................................................3
4. Confidentiality .................................................3
5. Distinguishing OSPFv3 from OSPFv2 ...............................4
6. IPsec Requirements ..............................................4
7. Key Management ..................................................5
8. SA Granularity and Selectors ....................................7
9. Virtual Links ...................................................8
10. Rekeying .......................................................9
10.1. Rekeying Procedure ........................................9
10.2. KeyRolloverInterval .......................................9
10.3. Rekeying Interval ........................................10
11. IPsec Protection Barrier and SPD ..............................10
12. Entropy of Manual Keys ........................................12
13. Replay Protection .............................................12
14. Security Considerations .......................................12
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
OSPF (Open Shortest Path First) Version 2 [N1] defines the fields AuType and Authentication in its protocol header to provide security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields were removed from OSPF headers. OSPFv3 relies on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to provide integrity, authentication, and/or confidentiality.
OSPF（开放最短路径优先）版本2[N1]在其协议头中定义了字段AuType和Authentication，以提供安全性。在用于IPv6的OSPF（OSPFv3）[N2]中，两个身份验证字段都从OSPF头中删除。OSPFv3依赖IPv6身份验证头（AH）和IPv6封装安全负载（ESP）来提供完整性、身份验证和/或机密性。
This document describes how IPv6 AH/ESP extension headers can be used to provide authentication/confidentiality to OSPFv3.
本文档描述了如何使用IPv6 AH/ESP扩展头为OSPFv3提供身份验证/机密性。
It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], ESP [N4], the concept of security associations, tunnel and transport mode of IPsec, and the key management options available for AH and ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
假设读者熟悉OSPFv3[N2]、AH[N5]、ESP[N4]、安全关联的概念、IPsec的隧道和传输模式以及AH和ESP可用的密钥管理选项（手动密钥[N3]和Internet密钥交换（IKE）[I1]）。
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 [N7].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[N7]中所述进行解释。
The transport mode Security Association (SA) is generally used between two hosts or routers/gateways when they are acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves. OSPFv3 packets are exchanged between routers. However, since the packets are locally delivered, the routers assume the role of hosts in the context of tunnel mode SA. All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to OSPFv3 packets. They MAY also support tunnel mode SA to provide required IPsec security to OSPFv3 packets.
传输模式安全关联（SA）通常在两台主机或路由器/网关之间用作主机时使用。如果安全关联的任意一端是路由器/网关，则SA必须是隧道模式SA。两台主机可以在它们之间建立隧道模式SA。OSPFv3数据包在路由器之间交换。然而，由于数据包是本地传送的，路由器在隧道模式SA的上下文中承担主机的角色。符合本规范的所有实现必须支持传输模式SA，以向OSPFv3数据包提供所需的IPsec安全性。它们还可以支持隧道模式SA，为OSPFv3数据包提供所需的IPsec安全性。
Implementations conforming to this specification MUST support authentication for OSPFv3.
符合本规范的实现必须支持OSPFv3的身份验证。
In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.
为了向OSPFv3提供身份验证，实现必须支持ESP，并且可能支持AH。
If ESP in transport mode is used, it will only provide authentication to OSPFv3 protocol packets excluding the IPv6 header, extension headers, and options.
如果使用传输模式下的ESP，它将仅为OSPFv3协议包提供身份验证，不包括IPv6头、扩展头和选项。
If AH in transport mode is used, it will provide authentication to OSPFv3 protocol packets, selected portions of IPv6 header, selected portions of extension headers, and selected options.
如果使用传输模式下的AH，它将为OSPFv3协议包、IPv6报头的选定部分、扩展报头的选定部分和选定选项提供身份验证。
When OSPFv3 authentication is enabled,
启用OSPFv3身份验证时，
o OSPFv3 packets that are not protected with AH or ESP MUST be silently discarded.
o 不受AH或ESP保护的OSPFv3数据包必须被静默丢弃。
o OSPFv3 packets that fail the authentication checks MUST be silently discarded.
o 未通过身份验证检查的OSPFv3数据包必须以静默方式丢弃。
Implementations conforming to this specification SHOULD support confidentiality for OSPFv3.
符合本规范的实现应支持OSPFv3的保密性。
If confidentiality is provided, ESP MUST be used.
如果提供了保密性，则必须使用ESP。
When OSPFv3 confidentiality is enabled,
启用OSPFv3机密性时，
o OSPFv3 packets that are not protected with ESP MUST be silently discarded.
o 未受ESP保护的OSPFv3数据包必须被静默丢弃。
o OSPFv3 packets that fail the confidentiality checks MUST be silently discarded.
o 未通过保密性检查的OSPFv3数据包必须以静默方式丢弃。
The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), and OSPF distinguishes them based on the OSPF header version number. However, current IPsec standards do not allow using arbitrary protocol-specific header fields as the selectors. Therefore, the OSPF version field in the OSPF header cannot be used to distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the version field in the IP header can be used to distinguish OSPFv3 packets from OSPFv2 packets.
OSPFv2和OSPFv3的IP/IPv6协议类型相同（89），OSPF根据OSPF头版本号区分它们。但是，当前的IPsec标准不允许使用任意协议特定的头字段作为选择器。因此，OSPF头中的OSPF版本字段不能用于区分OSPFv3数据包和OSPFv2数据包。由于OSPFv2仅用于IPv4，而OSPFv3仅用于IPv6，因此IP报头中的版本字段可用于区分OSPFv3数据包和OSPFv2数据包。
In order to implement this specification, the following IPsec capabilities are required.
为了实现此规范，需要以下IPsec功能。
Transport mode IPsec in transport mode MUST be supported. [N3]
必须支持传输模式中的传输模式IPsec。[N3]
Multiple Security Policy Databases (SPDs) The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface. [N3]
多个安全策略数据库（SPD）实施必须支持多个SPD，并具有SPD选择功能，该功能提供基于接口选择特定SPD的能力。[N3]
Selectors The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.
选择器实现必须能够使用源地址、目标地址、协议和方向作为SPD中的选择器。
Interface ID tagging The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived. [N3]
接口ID标记实现必须能够使用到达接口（物理或虚拟）的ID标记入站数据包。[N3]
Manual key support Manually configured keys MUST be able to secure the specified traffic. [N3]
必须能够手动配置指定的流量密钥才能保护手动密钥。[N3]
Encryption and authentication algorithms The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing OSPFv3 packets since the stream ciphers are not suitable for manual keys.
加密和身份验证算法由于流密码不适用于手动密钥，因此实现不得允许用户选择流密码作为保护OSPFv3数据包的加密算法。
Except when in conflict with the above statement, the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in the [N6] document for algorithms to be supported are to be interpreted as described in [N7] for OSPFv3 support as well.
除与上述声明冲突外，[N6]文件中出现的支持算法的关键词“必须”、“不得”、“必需”、“应该”和“不应该”也应按照[N7]中OSPFv3支持的描述进行解释。
Dynamic IPsec rule configuration The routing module SHOULD be able to configure, modify, and delete IPsec rules on the fly. This is needed mainly for securing virtual links.
动态IPsec规则配置路由模块应能够动态配置、修改和删除IPsec规则。这主要是为了保护虚拟链接。
Encapsulation of ESP packet IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
ESP数据包的封装必须支持ESP数据包的IP封装。为简单起见，不应使用ESP数据包的UDP封装。
Different SAs for different Differentiated Services Code Points (DSCPs) As per [N3], the IPsec implementation MUST support the establishment and maintenance of multiple SAs with the same selectors between a given sender and receiver. This allows the implementation to associate different classes of traffic with the same selector values in support of Quality of Service (QoS).
根据[N3]，不同区分服务代码点（DSCP）的不同SA，IPsec实现必须支持在给定发送方和接收方之间使用相同选择器建立和维护多个SA。这允许实现将不同类别的流量与相同的选择器值相关联，以支持服务质量（QoS）。
OSPFv3 exchanges both multicast and unicast packets. While running OSPFv3 over a broadcast interface, the authentication/confidentiality required is "one to many". Since IKE is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required "one to many" authentication/confidentiality. This specification mandates the usage of Manual Keying with current IPsec implementations. Future specifications can explore the usage of protocols like Kerberized Internet Negotiation of Keys/Group Secure Association Key Management Protocol (KINK/GSAKMP) when they are widely available. In manual keying, SAs are statically installed on the routers and these static SAs are used to authenticate/encrypt packets.
OSPFv3同时交换多播和单播数据包。通过广播接口运行OSPFv3时，所需的身份验证/机密性为“一对多”。由于IKE基于Diffie-Hellman密钥协议协议，并且仅适用于两个通信方，因此不可能使用IKE来提供所需的“一对多”身份验证/机密性。本规范要求在当前IPsec实现中使用手动密钥。未来的规范可以在广泛可用时探索诸如密钥的Kerberized Internet协商/组安全关联密钥管理协议（KINK/GSAKMP）等协议的使用。在手动键控中，SAs静态安装在路由器上，这些静态SA用于验证/加密数据包。
The following discussion explains that it is not scalable and is practically infeasible to use different security associations for inbound and outbound traffic to provide the required "one to many" security. Therefore, the implementations MUST use manually
下面的讨论解释了它是不可伸缩的，并且实际上不可能对入站和出站流量使用不同的安全关联来提供所需的“一对多”安全性。因此，实现必须手动使用
configured keys with the same SA parameters (Security Parameter Index (SPI), keys, etc.) for both inbound and outbound SAs (as shown in Figure 3).
为入站和出站SA配置了具有相同SA参数（安全参数索引（SPI）、密钥等）的密钥（如图3所示）。
A |
SAa ------------>|
SAb <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 1
|
C |
SAa/SAb ------------>|
SAa/SAb <------------|
|
Broadcast
Network
A |
SAa ------------>|
SAb <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 1
|
C |
SAa/SAb ------------>|
SAa/SAb <------------|
|
Broadcast
Network
If we consider communication between A and B in Figure 1, everything seems to be fine. A uses security association SAa for outbound packets and B uses the same for inbound packets and vice versa. Now if we include C in the group and C sends a packet using SAa, then only A will be able to understand it. Similarly, if C sends a packet using SAb, then only B will be able to understand it. Since the packets are multicast and they are going to be processed by both A and B, there is no SA for C to use so that both A and B can understand them.
如果我们考虑图1中的A和B之间的通信，一切似乎都很好。A对出站数据包使用安全关联SAa，B对入站数据包使用安全关联SAa，反之亦然。现在，如果我们将C包含在组中，并且C使用SAa发送数据包，那么只有a能够理解它。类似地，如果C使用SAb发送数据包，那么只有B能够理解它。由于数据包是多播的，它们将由A和B处理，因此C没有SA可供使用，以便A和B都能理解它们。
A |
SAa ------------>|
SAb <------------|
SAc <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 2
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
SAb <------------|
|
Broadcast
Network
A |
SAa ------------>|
SAb <------------|
SAc <------------|
|
B |
SAb ------------>|
SAa <------------| Figure 2
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
SAb <------------|
|
Broadcast
Network
The problem can be solved by configuring SAs for all the nodes on every other node as shown in Figure 2. So A, B, and C will use SAa, SAb, and SAc, respectively, for outbound traffic. Each node will lookup the SA to be used based on the source (A will use SAb and SAc for packets received from B and C, respectively). This solution is not scalable and practically infeasible because a large number of SAs will need to be configured on each node. Also, the addition of a node in the broadcast network will require the addition of another SA on every other node.
可以通过为每个其他节点上的所有节点配置SAs来解决此问题，如图2所示。因此，A、B和C将分别使用SAa、SAb和SAc进行出站通信。每个节点将根据源查找要使用的SA（A将分别对从B和C接收的数据包使用SAb和SAc）。此解决方案不可扩展且实际上不可行，因为需要在每个节点上配置大量SA。此外，在广播网络中添加节点将需要在每个其他节点上添加另一SA。
A |
SAo ------------>|
SAi <------------|
|
B |
SAo ------------>|
SAi <------------| Figure 3
|
C |
SAo ------------>|
SAi <------------|
|
Broadcast
Network
A |
SAo ------------>|
SAi <------------|
|
B |
SAo ------------>|
SAi <------------| Figure 3
|
C |
SAo ------------>|
SAi <------------|
|
Broadcast
Network
The problem can be solved by using the same SA parameters (SPI, keys, etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in Figure 3.
这个问题可以通过为入站（SAi）和出站（SAo）SA使用相同的SA参数（SPI、密钥等）来解决，如图3所示。
The user SHOULD be given the choice of sharing the same SA among multiple interfaces or using a unique SA per interface.
用户可以选择在多个接口之间共享相同的SA，也可以为每个接口使用唯一的SA。
OSPFv3 supports running multiple instances over one interface using the "Instance Id" field contained in the OSPFv3 header. As IPsec does not support arbitrary fields in the protocol header to be used as the selectors, it is not possible to use different SAs for different OSPFv3 instances running over the same interface. Therefore, all OSPFv3 instances running over the same interface will have to use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not per-interface.
OSPFv3支持使用OSPFv3标头中包含的“实例Id”字段在一个接口上运行多个实例。由于IPsec不支持协议头中用作选择器的任意字段，因此无法对运行在同一接口上的不同OSPFv3实例使用不同的SAs。因此，在同一接口上运行的所有OSPFv3实例都必须使用相同的SA。在OSPFv3 RFC术语中，SA是每个链路，而不是每个接口。
A different SA than the SA of the underlying interface MUST be provided for virtual links. Packets sent on virtual links use unicast non-link local IPv6 addresses as the IPv6 source address, while packets sent on other interfaces use multicast and unicast link local addresses. This difference in the IPv6 source address differentiates the packets sent on virtual links from other OSPFv3 interface types.
必须为虚拟链接提供不同于基础接口SA的SA。在虚拟链路上发送的数据包使用单播非链路本地IPv6地址作为IPv6源地址，而在其他接口上发送的数据包使用多播和单播链路本地地址。IPv6源地址的这种差异将在虚拟链路上发送的数据包与其他OSPFv3接口类型区分开来。
As the virtual link end point IPv6 addresses are not known, it is not possible to install SPD/Security Association Database (SAD) entries at the time of configuration. The virtual link end point IPv6 addresses are learned during the routing table computation process. The packet exchange over the virtual links starts only after the discovery of the end point IPv6 addresses. In order to protect these exchanges, the routing module must install the corresponding SPD/SAD entries before starting these exchanges. Note that manual SA parameters are preconfigured but not installed in the SAD until the end point addresses are learned.
由于虚拟链路端点IPv6地址未知，因此无法在配置时安装SPD/安全关联数据库（SAD）条目。在路由表计算过程中学习虚拟链路端点IPv6地址。虚拟链路上的数据包交换仅在发现端点IPv6地址后开始。为了保护这些交换机，路由模块必须在启动这些交换机之前安装相应的SPD/SAD条目。请注意，手动SA参数是预配置的，但在读取端点地址之前不会安装在SAD中。
According to the OSPFv3 RFC [N2], the virtual neighbor's IP address is set to the first prefix with the "LA-bit" set from the list of prefixes in intra-area-prefix-Link State Advertisements (LSAs) originated by the virtual neighbor. But when it comes to choosing the source address for the packets that are sent over the virtual link, the RFC [N2] simply suggests using one of the router's own global IPv6 addresses. In order to install the required security rules for virtual links, the source address also needs to be predictable. Hence, routers that implement this specification MUST change the way the source and destination addresses are chosen for packets exchanged over virtual links when IPsec is enabled.
根据OSPFv3 RFC[N2]，虚拟邻居的IP地址被设置为第一前缀，其中“LA比特”是从虚拟邻居发起的区域内前缀链路状态播发（lsa）中的前缀列表中设置的。但在为通过虚拟链路发送的数据包选择源地址时，RFC[N2]只是建议使用路由器自己的一个全局IPv6地址。为了为虚拟链接安装所需的安全规则，源地址还需要是可预测的。因此，当启用IPsec时，实现此规范的路由器必须更改为通过虚拟链路交换的数据包选择源地址和目标地址的方式。
The first IPv6 address with the "LA-bit" set in the list of prefixes advertised in intra-area-prefix-LSAs in the transit area MUST be used as the source address for packets exchanged over the virtual link. When multiple intra-area-prefix-LSAs are originated, they are considered concatenated and are ordered by ascending Link State ID.
传输区域内区域前缀LSA中公布的前缀列表中设置了“LA位”的第一个IPv6地址必须用作通过虚拟链路交换的数据包的源地址。当多个区域内前缀LSA被发起时，它们被认为是串联的，并按升序链路状态ID排序。
The first IPv6 address with the "LA-bit" set in the list of prefixes received in intra-area-prefix-LSAs from the virtual neighbor in the transit area MUST be used as the destination address for packets exchanged over the virtual link. When multiple intra-area-prefix-LSAs are received, they are considered concatenated and are ordered by ascending Link State ID.
在区域内前缀LSA中从传输区域中的虚拟邻居接收的前缀列表中设置了“LA位”的第一个IPv6地址必须用作通过虚拟链路交换的数据包的目标地址。当接收到多个区域内前缀LSA时，它们被视为连接在一起，并按升序链路状态ID排序。
This makes both the source and destination addresses of packets exchanged over the virtual link predictable when IPsec is enabled.
这使得在启用IPsec时，通过虚拟链路交换的数据包的源地址和目标地址都是可预测的。
To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically.
为了维护链接的安全性，应该定期更改身份验证和加密密钥值。
The following three-step procedure SHOULD be provided to rekey the routers on a link without dropping OSPFv3 protocol packets or disrupting the adjacency.
应提供以下三步程序，以便在不丢弃OSPFv3协议包或中断相邻关系的情况下，对链路上的路由器重新设置密钥。
(1) For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
(1) 对于链路上的每个路由器，为使用新SPI和新密钥重新设置密钥的接口创建一个额外的入站SA。
(2) For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation should be atomic with respect to sending OSPFv3 packets on the link so that no OSPFv3 packets are sent without authentication/encryption.
(2) 对于链路上的每个路由器，使用新的SPI和键值替换原始出站SA。SA替换操作对于在链路上发送OSPFv3数据包来说应该是原子的，这样在没有身份验证/加密的情况下就不会发送OSPFv3数据包。
(3) For every router on the link, remove the original inbound SA.
(3) 对于链路上的每个路由器，删除原始入站SA。
Note that all routers on the link must complete step 1 before any begin step 2. Likewise, all the routers on the link must complete step 2 before any begin step 3.
请注意，链路上的所有路由器必须在开始任何步骤2之前完成步骤1。同样，链路上的所有路由器必须在任何开始步骤3之前完成步骤2。
One way to control the progression from one step to the next is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.
控制从一个步骤到下一个步骤的过程的一种方法是，每个路由器都有一个可配置的时间常数KeyRolloverInterval。路由器在给定链路上开始步骤1后，等待该间隔，然后移动到步骤2。同样，在移动到步骤2之后，它等待该间隔，然后移动到步骤3。
In order to achieve smooth key transition, all routers on a link should use the same value for KeyRolloverInterval and should initiate the key rollover process within this time period.
为了实现平稳的密钥转换，链路上的所有路由器都应使用相同的KeyRolloverInterval值，并应在此时间段内启动密钥翻转过程。
At the end of this procedure, all the routers on the link will have a single inbound and outbound SA for OSPFv3 with the new SPI and key values.
在该过程结束时，链路上的所有路由器将为OSPFv3提供一个具有新SPI和键值的入站和出站SA。
The configured value of KeyRolloverInterval should be long enough to allow the administrator to change keys on all the OSPFv3 routers. As this value can vary significantly depending upon the implementation and the deployment, it is left to the administrator to choose an appropriate value.
KeyRolloverInterval的配置值应足够长，以允许管理员更改所有OSPFv3路由器上的密钥。由于此值可能因实施和部署的不同而有很大差异，因此由管理员选择适当的值。
This section analyzes the security provided by manual keying and recommends that the encryption and authentication keys SHOULD be changed at least every 90 days.
本节分析手动密钥提供的安全性，并建议至少每90天更改一次加密和身份验证密钥。
The weakest security provided by the security mechanisms discussed in this specification is when NULL encryption (for ESP) or no encryption (for AH) is used with the HMAC-MD5 authentication. Any other algorithm combinations will at least be as hard to break as the ones mentioned above. This is shown by the following reasonable assumptions:
本规范中讨论的安全机制提供的最弱安全性是在HMAC-MD5身份验证中使用空加密（ESP）或不加密（AH）时。任何其他算法组合都至少与上述算法组合一样难以打破。以下合理假设表明了这一点：
o NULL Encryption and HMAC-SHA-1 Authentication will be more secure as HMAC-SHA-1 is considered to be more secure than HMAC-MD5.
o 空加密和HMAC-SHA-1身份验证将更安全，因为HMAC-SHA-1被认为比HMAC-MD5更安全。
o NON-NULL Encryption and NULL Authentication combination is not applicable as this specification mandates authentication when OSPFv3 security is enabled.
o 非空加密和空身份验证组合不适用，因为此规范要求在启用OSPFv3安全性时进行身份验证。
o Data Encryption Security (DES) Encryption and HMAC-MD5 Authentication will be more secure because of the additional security provided by DES.
o 数据加密安全性（DES）加密和HMAC-MD5身份验证将更加安全，因为DES提供了额外的安全性。
o Other encryption algorithms like 3DES and the Advanced Encryption Standard (AES) will be more secure than DES.
o 其他加密算法如3DES和高级加密标准（AES）将比DES更安全。
RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 signature option. The analysis provided in RFC 3562 is also applicable to this specification as the analysis is independent of data patterns.
RFC 3562[I4]分析了TCP MD5签名选项的密钥更新要求。RFC 3562中提供的分析也适用于本规范，因为分析独立于数据模式。
The IPsec protection barrier MUST be around the OSPF protocol. Therefore, all the inbound and outbound OSPF traffic goes through IPsec processing.
IPsec保护屏障必须围绕OSPF协议。因此，所有入站和出站OSPF流量都通过IPsec处理。
The SPD selection function MUST return an SPD with the following rule for all the interfaces that have OSPFv3 authentication/confidentiality disabled.
对于禁用OSPFv3身份验证/机密性的所有接口，SPD选择功能必须返回具有以下规则的SPD。
No. source destination protocol action 1 any any OSPF bypass
否。源-目标协议操作1任何OSPF旁路
The SPD selection function MUST return an SPD with the following rules for all the interfaces that have OSPFv3 authentication/confidentiality enabled.
对于启用OSPFv3身份验证/机密性的所有接口，SPD选择功能必须返回具有以下规则的SPD。
No. source destination protocol action
2 fe80::/10 any OSPF protect
3 fe80::/10 any ESP/OSPF or AH/OSPF protect
4 src/128 dst/128 OSPF protect
5 src/128 dst/128 ESP/OSPF or AH/OSPF protect
No. source destination protocol action
2 fe80::/10 any OSPF protect
3 fe80::/10 any ESP/OSPF or AH/OSPF protect
4 src/128 dst/128 OSPF protect
5 src/128 dst/128 ESP/OSPF or AH/OSPF protect
For rules 2 and 4, action "protect" means encrypting/calculating Integrity Check Value (ICV) and adding an ESP or AH header. For rules 3 and 5, action "protect" means decrypting/authenticating the packets and stripping the ESP or AH header.
对于规则2和4，“保护”操作意味着加密/计算完整性检查值（ICV）并添加ESP或AH头。对于规则3和5，操作“保护”意味着解密/验证数据包并剥离ESP或AH报头。
Rule 1 will bypass the OSPFv3 packets without any IPsec processing on the interfaces that have OSPFv3 authentication/confidentiality disabled.
规则1将在禁用OSPFv3身份验证/机密性的接口上绕过OSPFv3数据包，而不进行任何IPsec处理。
Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been secured with ESP/AH headers.
规则2和4将丢弃未使用ESP/AH头保护的入站OSPFv3数据包。
ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet secured with ESP or AH.
规则3和5中的ESP/OSPF或AH/OSPF意味着它是由ESP或AH保护的OSPF数据包。
Rules 2 and 3 are meant to secure the unicast and multicast OSPF packets that are not being exchanged over the virtual links.
规则2和3旨在保护未通过虚拟链路交换的单播和多播OSPF数据包。
Rules 4 and 5 are meant to secure the packets being exchanged over virtual links. These rules are installed after learning the virtual link end point IPv6 addresses. These rules MUST be installed in the SPD for the interfaces that are connected to the transit area for the virtual link. These rules MAY alternatively be installed on all the interfaces. If these rules are not installed on all the interfaces, clear text or malicious OSPFv3 packets with the same source and destination addresses as the virtual link end point IPv6 addresses will be delivered to OSPFv3. Though OSPFv3 drops these packets as they were not received on the right interface, OSPFv3 receives some clear text or malicious packets even when the security is enabled. Installing these rules on all the interfaces ensures that OSPFv3 does not receive these clear text or malicious packets when security is enabled. On the other hand, installing these rules on all the interfaces increases the processing overhead on the interfaces where there is no other IPsec processing. The decision of whether to install these rules on all the interfaces or on just the interfaces that are connected to the transit area is a private decision and doesn't affect the interoperability in any way. Hence it is an implementation choice.
规则4和5旨在保护通过虚拟链路交换的数据包。这些规则是在了解虚拟链路端点IPv6地址后安装的。对于连接到虚拟链路传输区域的接口，必须在SPD中安装这些规则。这些规则也可以安装在所有接口上。如果未在所有接口上安装这些规则，则具有与虚拟链路端点IPv6地址相同的源地址和目标地址的明文或恶意OSPFv3数据包将被发送到OSPFv3。尽管OSPFv3会丢弃这些数据包，因为它们不是在正确的接口上接收到的，但即使启用了安全性，OSPFv3也会接收一些明文或恶意数据包。在所有接口上安装这些规则可确保OSPFv3在启用安全性时不会收到这些明文或恶意数据包。另一方面，在所有接口上安装这些规则会增加没有其他IPsec处理的接口上的处理开销。是在所有接口上安装这些规则，还是只在连接到中转区的接口上安装这些规则，这是一个私人决定，不会以任何方式影响互操作性。因此，它是一种实现选择。
The implementations MUST allow the administrator to configure the cryptographic and authentication keys in hexadecimal format rather than restricting it to a subset of ASCII characters (letters, numbers, etc.). A restricted character set will reduce key entropy significantly as discussed in [I2].
实现必须允许管理员以十六进制格式配置加密和身份验证密钥，而不是将其限制为ASCII字符（字母、数字等）的子集。如[I2]所述，受限字符集将显著降低密钥熵。
Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.
由于在使用手动键控时无法使用当前标准提供完整的重播保护，因此建议的解决方案将无法提供针对重播攻击的保护。
Detailed analysis of various vulnerabilities of the routing protocols and OSPF in particular is discussed in [I3] and [I2]. The conclusion is that replay of OSPF packets can cause adjacencies to be disrupted, which can lead to a DoS attack on the network. It can also cause database exchange process to occur continuously thus causing CPU overload as well as micro loops in the network.
[I3]和[I2]详细分析了路由协议和OSPF的各种漏洞。结论是，OSPF数据包的重放可能会导致邻接中断，从而导致网络上的DoS攻击。它还可能导致数据库交换过程持续发生，从而导致CPU过载以及网络中的微循环。
This memo discusses the use of IPsec AH and ESP headers to provide security to OSPFv3 for IPv6. Hence, security permeates throughout this document.
本备忘录讨论了IPv6的安全性，并讨论了为ESP提供IPv6头的FVAH。因此，安全贯穿于本文件的始终。
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF vulnerabilities in two scenarios -- one with no authentication or simple password authentication and the other with cryptographic authentication. The solution described in this specification provides protection against all the vulnerabilities identified for scenarios with cryptographic authentication with the following exceptions:
OSPF安全漏洞分析[I2]在两种情况下识别OSPF漏洞——一种是没有身份验证或简单密码身份验证，另一种是密码身份验证。本规范中描述的解决方案可针对加密身份验证场景中识别的所有漏洞提供保护，但以下情况除外：
Limitations of manual key:
手动钥匙的限制：
This specification mandates the usage of manual keys. The following are the known limitations of the usage of manual keys.
本规范要求使用手动钥匙。以下是使用手动钥匙的已知限制。
o As the sequence numbers cannot be negotiated, replay protection cannot be provided. This leaves OSPF insecure against all the attacks that can be performed by replaying OSPF packets.
o 由于无法协商序列号，因此无法提供重播保护。这使得OSPF对所有可以通过重放OSPF数据包执行的攻击都不安全。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
o 手动钥匙通常寿命很长（经常更换它们是一项乏味的任务）。这使攻击者有足够的时间发现密钥。
o As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).
o 由于管理员正在手动配置密钥，因此配置的密钥可能很弱（至少存在已知的DES/3DES弱密钥）。
Impersonating attacks:
模拟攻击：
The usage of the same key on all the OSPF routers connected to a link leaves them all insecure against impersonating attacks if any one of the OSPF routers is compromised, malfunctioning, or misconfigured.
在连接到链路的所有OSPF路由器上使用相同的密钥会使它们在任何一个OSPF路由器受损、出现故障或配置错误时都不安全，无法抵御模拟攻击。
Detailed analysis of various vulnerabilities of routing protocols is discussed in [I3].
[I3]详细分析了路由协议的各种漏洞。
[N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[N1]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[N2]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[N3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[N3]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[N4]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[N5]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[N6]Eastlake 3rd，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N7]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[I1]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis", Work in Progress.
[I2]Jones，E.和O.Moigne，“OSPF安全漏洞分析”，正在进行中。
[I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", Work in Progress.
[I3]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，正在进行中。
[I4] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[I4]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
Acknowledgements
致谢
The authors would like to extend sincere thanks to Marc Solsona, Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas Manral, and Sam Hartman for providing useful information and critiques on this memo. The authors would like to extend special thanks to Acee Lindem for many editorial changes.
作者衷心感谢Marc Solsona、Janne Peltonen、John Cruz、Dhaval Shah、Abhay Roy、Paul Wells、Vishwas Manral和Sam Hartman为本备忘录提供了有用的信息和评论。作者要特别感谢Acee Lindem的许多编辑修改。
We would also like to thank members of the IPsec and OSPF WG for providing valuable review comments.
我们还要感谢IPsec和OSPF工作组的成员提供了宝贵的审查意见。
Authors' Addresses
作者地址
Mukesh Gupta Tropos Networks 555 Del Rey Ave Sunnyvale, CA 94085
Mukesh Gupta对流层网络加利福尼亚州桑尼维尔市德雷大道555号，邮编94085
Phone: 408-331-6889 EMail: mukesh.gupta@tropos.com
电话：408-331-6889电子邮件：mukesh。gupta@tropos.com
Nagavenkata Suresh Melam Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Nagavenkata Suresh Melam Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
Phone: 408-505-4392 EMail: nmelam@juniper.net
电话：408-505-4392电子邮件：nmelam@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。