Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7166 Alcatel-Lucent
Obsoletes: 6506 V. Manral
Category: Standards Track Ionos Corp.
ISSN: 2070-1721 A. Lindem
Ericsson
March 2014
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7166 Alcatel-Lucent
Obsoletes: 6506 V. Manral
Category: Standards Track Ionos Corp.
ISSN: 2070-1721 A. Lindem
Ericsson
March 2014
Supporting Authentication Trailer for OSPFv3
支持OSPFv3的身份验证拖车
Abstract
摘要
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.
目前，OSPF for IPv6（OSPFv3）使用IPsec作为验证协议数据包的唯一机制。这种行为不同于其他路由协议（OSPFv2、中间系统到中间系统（is-is）、RIP和下一代路由信息协议（RIPng））中的身份验证机制。在某些环境中，已发现IPsec难以配置和维护，因此无法使用。本文档定义了另一种对OSPFv3协议包进行身份验证的机制，以便OSPFv3不仅依赖IPsec进行身份验证。
The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.
OSPFv3身份验证尾部最初在RFC 6506中定义。本文件通过提供修订的定义（包括程序的澄清和完善）淘汰了RFC 6506。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7166.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7166.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements ...............................................4
1.2. Summary of Changes from RFC 6506 ...........................4
2. Proposed Solution ...............................................5
2.1. AT-Bit in Options Field ....................................5
2.2. Basic Operation ............................................6
2.3. IPv6 Source Address Protection .............................6
3. OSPFv3 Security Association .....................................7
4. Authentication Procedure ........................................9
4.1. Authentication Trailer .....................................9
4.1.1. Sequence Number Wrap ...............................11
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
4.3. Cryptographic Authentication Procedure ....................12
4.4. Cross-Protocol Attack Mitigation ..........................12
4.5. Cryptographic Aspects .....................................12
4.6. Message Verification ......................................15
5. Migration and Backward Compatibility ...........................16
6. Security Considerations ........................................17
7. IANA Considerations ............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................19
Appendix A. Acknowledgments .......................................22
1. Introduction ....................................................3
1.1. Requirements ...............................................4
1.2. Summary of Changes from RFC 6506 ...........................4
2. Proposed Solution ...............................................5
2.1. AT-Bit in Options Field ....................................5
2.2. Basic Operation ............................................6
2.3. IPv6 Source Address Protection .............................6
3. OSPFv3 Security Association .....................................7
4. Authentication Procedure ........................................9
4.1. Authentication Trailer .....................................9
4.1.1. Sequence Number Wrap ...............................11
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
4.3. Cryptographic Authentication Procedure ....................12
4.4. Cross-Protocol Attack Mitigation ..........................12
4.5. Cryptographic Aspects .....................................12
4.6. Message Verification ......................................15
5. Migration and Backward Compatibility ...........................16
6. Security Considerations ........................................17
7. IANA Considerations ............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................19
Appendix A. Acknowledgments .......................................22
Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF for IPv6 (OSPFv3) [RFC5340] does not include the AuType and Authentication fields in its headers for authenticating protocol packets. Instead, OSPFv3 relies on the IPsec protocols Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] to provide integrity, authentication, and/or confidentiality.
与开放式最短路径第一版本2（OSPFv2）[RFC2328]不同，用于IPv6的OSPF（OSPFv3）[RFC5340]在其标头中不包括用于验证协议数据包的AuType和身份验证字段。相反，OSPFv3依赖IPsec协议认证头（AH）[RFC4302]和封装安全负载（ESP）[RFC4303]来提供完整性、认证和/或机密性。
[RFC4552] describes how IPv6 AH and ESP extension headers can be used to provide authentication and/or confidentiality to OSPFv3.
[RFC4552]描述了如何使用IPv6 AH和ESP扩展头为OSPFv3提供身份验证和/或机密性。
However, there are some environments, e.g., Mobile Ad Hoc Networks (MANETs), where IPsec is difficult to configure and maintain; this mechanism cannot be used in such environments.
然而，在某些环境中，例如移动自组织网络（MANET），IPsec很难配置和维护；这种机制不能在这种环境中使用。
[RFC4552] discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The primary problem is the lack of a suitable key management mechanism, as OSPFv3 adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. This forces the system administrator to use manually configured Security Associations (SAs) and cryptographic keys to provide the authentication and, if desired, confidentiality services.
[RFC4552]详细讨论了使用手动配置的密钥而不是一些自动密钥管理协议（如Internet密钥交换版本2（IKEv2）[RFC5996]）背后的原因。主要问题是缺乏合适的密钥管理机制，因为OSPFv3邻接是在一对多的基础上形成的，并且大多数密钥管理机制是为一对一通信模型设计的。这迫使系统管理员使用手动配置的安全关联（SA）和加密密钥来提供身份验证和（如果需要）保密服务。
Regarding replay protection, [RFC4552] states that:
关于重播保护，[RFC4552]指出：
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.
由于在使用手动键控时无法使用当前标准提供完整的重播保护，因此建议的解决方案将无法提供针对重播攻击的保护。
Since there is no replay protection provided, there are a number of vulnerabilities in OSPFv3 that have been discussed in [RFC6039].
由于没有提供重播保护，OSPFv3中存在许多漏洞，这些漏洞已在[RFC6039]中讨论过。
While techniques exist to identify ESP-NULL packets [RFC5879], these techniques are generally not implemented in the data planes of OSPFv3 routers. This makes it very difficult for implementations to examine OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g., Hello packets, over the other types.
虽然存在识别ESP-NULL数据包的技术[RFC5879]，但这些技术通常不在OSPFv3路由器的数据平面中实现。这使得实现很难检查OSPFv3数据包并将某些OSPFv3数据包类型（例如，Hello数据包）优先于其他类型。
This document defines a mechanism that works similarly to OSPFv2 [RFC5709] to provide authentication to OSPFv3 packets and solves the problems related to replay protection and deterministically disambiguating different OSPFv3 packets as described above.
本文件定义了一种类似于OSPFv2[RFC5709]的机制，用于为OSPFv3数据包提供身份验证，并解决了与重播保护和如上所述确定消除不同OSPFv3数据包歧义相关的问题。
This document adds support for the Secure Hash Algorithms (SHAs) defined in the US NIST Secure Hash Standard (SHS), which is specified by NIST FIPS 180-4. [FIPS-180-4] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used.
本文件增加了对美国NIST安全哈希标准（SHS）中定义的安全哈希算法（SHA）的支持，该标准由NIST FIPS 180-4规定。[FIPS-180-4]包括SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。使用NIST FIPS 198-1[FIPS-198-1]中定义的哈希消息认证码（HMAC）认证模式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document includes the following changes from RFC 6506 [RFC6506]:
本文件包括对RFC 6506[RFC6506]的以下更改：
1. Sections 2.2 and 4.2 explicitly state that the Link-Local Signaling (LLS) block checksum calculation is omitted when an OSPFv3 Authentication Trailer is used for OSPFv3 authentication. The LLS data block is included in the authentication digest calculation, and computation of a checksum is unnecessary. Clarification of this issue was documented in an erratum.
1. 第2.2节和第4.2节明确规定，当OSPFv3认证拖车用于OSPFv3认证时，忽略链路本地信令（LLS）块校验和计算。LLS数据块包括在认证摘要计算中，不需要计算校验和。该问题的澄清记录在勘误表中。
2. Section 3 previously recommended usage of an expired key for transmitted OSPFv3 packets when no valid keys existed. This statement has been removed.
2. 第3节先前建议在不存在有效密钥的情况下，对传输的OSPFv3数据包使用过期密钥。此声明已被删除。
3. Section 4.5 includes a correction to the key preparation to use the Protocol-Specific Authentication Key (Ks) rather than the Authentication Key (K) as the initial key (Ko). This problem was also documented in an erratum.
3. 第4.5节包括对密钥准备的更正，以使用协议特定身份验证密钥（Ks）而不是身份验证密钥（K）作为初始密钥（Ko）。该问题也记录在勘误表中。
4. Section 4.5 also includes a discussion of the choice of key length to be the hash length (L) rather than the block size (B). The discussion of this choice was included to clarify an issue raised in a rejected erratum.
4. 第4.5节还讨论了将密钥长度选择为散列长度（L）而不是块大小（B）。对这一选择的讨论是为了澄清被否决的勘误表中提出的一个问题。
5. Sections 4.1 and 4.6 indicate that sequence number checking is dependent on OSPFv3 packet type in order to account for packet prioritization as specified in [RFC4222]. This was an omission from RFC 6506 [RFC6506].
5. 第4.1节和第4.6节指出，序列号检查取决于OSPFv3数据包类型，以说明[RFC4222]中规定的数据包优先级。这是RFC 6506[RFC6506]中的遗漏。
6. Section 4.6 explicitly states that OSPFv3 packets with a nonexistent or expired Security Association (SA) will be dropped.
6. 第4.6节明确规定，不存在或已过期安全关联（SA）的OSPFv3数据包将被丢弃。
7. Section 5 includes guidance on the precise actions required for an OSPFv3 router providing a backward-compatible transition mode.
7. 第5节包括提供向后兼容转换模式的OSPFv3路由器所需的精确操作指南。
To perform non-IPsec Cryptographic Authentication, OSPFv3 routers append a special data block, henceforth referred to as the Authentication Trailer, to the end of the OSPFv3 packets. The length of the Authentication Trailer is not included in the length of the OSPFv3 packet but is included in the IPv6 payload length, as shown in Figure 1.
为了执行非IPsec加密身份验证，OSPFv3路由器在OSPFv3数据包的末尾附加一个特殊的数据块，此后称为身份验证尾部。身份验证尾部的长度不包括在OSPFv3数据包的长度中，而是包括在IPv6有效负载长度中，如图1所示。
+---------------------+ -- -- +----------------------+
| IPv6 Payload Length | ^ ^ | IPv6 Payload Length |
| PL = OL + LL | | | | PL = OL + LL + AL |
| | v v | |
+---------------------+ -- -- +----------------------+
| OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL |
| | | OSPFv3 | | |
|.....................| | Packet | |......................|
| | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | |
+---------------------+ -- -- +----------------------+
| | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS |
| LL = LLS Data | | Block | | LL = LLS Data |
| Block Length | v Length v | Block Length |
+---------------------+ -- -- +----------------------+
^ | |
AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + |
v | Digest Length |
-- +----------------------+
+---------------------+ -- -- +----------------------+
| IPv6 Payload Length | ^ ^ | IPv6 Payload Length |
| PL = OL + LL | | | | PL = OL + LL + AL |
| | v v | |
+---------------------+ -- -- +----------------------+
| OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL |
| | | OSPFv3 | | |
|.....................| | Packet | |......................|
| | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | |
+---------------------+ -- -- +----------------------+
| | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS |
| LL = LLS Data | | Block | | LL = LLS Data |
| Block Length | v Length v | Block Length |
+---------------------+ -- -- +----------------------+
^ | |
AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + |
v | Digest Length |
-- +----------------------+
Figure 1: Authentication Trailer in OSPFv3
图1:OSPFv3中的身份验证拖车
The presence of the Link-Local Signaling (LLS) [RFC5613] block is determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 Hello and Database Description packets. If present, the LLS data block is included along with the OSPFv3 packet in the Cryptographic Authentication computation.
链路本地信令（LLS）[RFC5613]块的存在由OSPFv3 Hello和数据库描述数据包中OSPFv3选项字段中的L位设置确定。如果存在，LLS数据块与OSPFv3分组一起包括在加密认证计算中。
RFC 6506 introduced the AT-bit ("AT" stands for "Authentication Trailer") into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all the packets on this link will include an Authentication Trailer. For OSPFv3 Hello and Database Description packets, the
RFC 6506在OSPFv3选项字段中引入了AT位（“AT”代表“认证拖车”）。OSPFv3路由器必须在OSPFv3 Hello和数据库描述数据包中设置AT位，以指示此链路上的所有数据包都将包含一个身份验证尾部。对于OSPFv3 Hello和数据库描述数据包
AT-bit indicates that the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database Description setting is preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types that don't include an OSPFv3 Options field will use the setting from the neighbor data structure to determine whether or not the AT is expected.
AT位表示存在AT。对于其他OSPFv3数据包类型，OSPFv3 Hello/数据库描述设置中的OSPFv3 AT位设置保留在OSPFv3邻居数据结构中。不包括OSPFv3选项字段的OSPFv3数据包类型将使用邻居数据结构中的设置来确定是否需要AT。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
Figure 2: OSPFv3 Options Field
图2:OSPFv3选项字段
The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 Hello and Database Description packets that contain an Authentication Trailer.
如上图所示，必须在所有包含身份验证尾部的OSPFv3 Hello和数据库描述数据包中设置AT位。
The procedure followed for computing the Authentication Trailer is much the same as those described in [RFC5709] and [RFC2328]. One difference is that the LLS data block, if present, is included in the Cryptographic Authentication computation.
计算认证尾部所遵循的过程与[RFC5709]和[RFC2328]中所述的过程大致相同。一个区别是，LLS数据块（如果存在）包括在加密身份验证计算中。
The way the authentication data is carried in the Authentication Trailer is very similar to how it is done in the case of [RFC2328]. The only difference between the OSPFv2 Authentication Trailer and the OSPFv3 Authentication Trailer is that information in addition to the message digest is included. The additional information in the OSPFv3 Authentication Trailer is included in the message digest computation and is therefore protected by OSPFv3 Cryptographic Authentication as described herein.
认证数据在认证拖车中的传输方式与[RFC2328]的情况非常相似。OSPFv2身份验证尾部和OSPFv3身份验证尾部之间的唯一区别在于，除了包含消息摘要之外，还包含其他信息。OSPFv3认证尾部中的附加信息包括在消息摘要计算中，因此如本文所述，由OSPFv3加密认证保护。
Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and Link-Local Signaling Cryptographic Authentication [RFC5613], checksum calculation and verification are omitted for both the OSPFv3 header checksum and the LLS data block when the OSPFv3 authentication mechanism described in this specification is used.
与OSPFv2加密身份验证[RFC2328]和链路本地信令加密身份验证[RFC5613]一致，当使用本规范中描述的OSPFv3身份验证机制时，OSPFv3报头校验和和和LLS数据块的校验和计算和验证都被省略。
While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, the IPv6 source address is learned from OSPFv3 Hello packets and copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is susceptible to Man-in-the-Middle attacks where the IPv6 source address is modified. To thwart such attacks, the IPv6 source address
虽然OSPFv3始终使用路由器ID来标识OSPFv3邻居，但IPv6源地址从OSPFv3 Hello数据包中学习并复制到邻居数据结构[RFC5340]。因此，在修改IPv6源地址的情况下，OSPFv3容易受到中间人攻击。为了阻止此类攻击，IPv6源地址
will be included in the message digest calculation and protected by OSPFv3 authentication. Refer to Section 4.5 for details. This is different than the procedure specified in [RFC5709] but consistent with [MANUAL-KEY].
将包含在消息摘要计算中，并受OSPFv3身份验证保护。详见第4.5节。这与[RFC5709]中规定的程序不同，但与[MANUAL-KEY]一致。
An OSPFv3 Security Association (SA) contains a set of parameters shared between any two legitimate OSPFv3 speakers.
OSPFv3安全关联（SA）包含任意两个合法OSPFv3扬声器之间共享的一组参数。
Parameters associated with an OSPFv3 SA are as follows:
与OSPFv3 SA相关的参数如下：
o Security Association Identifier (SA ID)
o 安全关联标识符（SA ID）
This is a 16-bit unsigned integer used to uniquely identify an OSPFv3 SA, as manually configured by the network operator.
这是一个16位无符号整数，用于唯一标识OSPFv3 SA，由网络运营商手动配置。
The receiver determines the active SA by looking at the SA ID field in the incoming protocol packet.
接收器通过查看传入协议包中的SA ID字段来确定活动SA。
The sender, based on the active configuration, selects an SA to use and puts the correct Key ID value associated with the SA in the OSPFv3 protocol packet. If multiple valid and active OSPFv3 SAs exist for a given interface, the sender may use any of those SAs to protect the packet.
发送方根据活动配置选择要使用的SA，并将与SA关联的正确密钥ID值放入OSPFv3协议包中。如果给定接口存在多个有效且活动的OSPFv3 SA，则发送方可以使用这些SA中的任何一个来保护数据包。
Using SA IDs makes changing keys while maintaining protocol operation convenient. Each SA ID specifies two independent parts: the authentication algorithm and the Authentication Key, as explained below.
使用SA ID可以在维护协议操作的同时方便地更改密钥。每个SA ID指定两个独立的部分：身份验证算法和身份验证密钥，如下所述。
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.
通常，实现将允许网络运营商在密钥链中配置一组密钥，其中链中的每个密钥具有固定的生存期。这些机制的实际运作超出了本文件的范围。
Note that each SA ID can indicate a key with a different authentication algorithm. This allows the introduction of new authentication mechanisms without disrupting existing OSPFv3 adjacencies.
请注意，每个SA ID可以使用不同的身份验证算法指示密钥。这允许引入新的身份验证机制，而不会中断现有的OSPFv3邻接。
o Authentication Algorithm
o 认证算法
This signifies the authentication algorithm to be used with this OSPFv3 SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information.
这表示将与此OSPFv3 SA一起使用的身份验证算法。此信息从不以明文形式通过电线发送。因为该信息不是通过线路发送的，所以实现者为该信息选择了特定于实现的表示。
Currently, the following algorithms are supported:
目前，支持以下算法：
* HMAC-SHA-1,
* HMAC-SHA-1，
* HMAC-SHA-256,
* HMAC-SHA-256，
* HMAC-SHA-384, and
* HMAC-SHA-384，以及
* HMAC-SHA-512.
* HMAC-SHA-512。
o Authentication Key
o 认证密钥
This value denotes the Cryptographic Authentication Key associated with this OSPFv3 SA. The length of this key is variable and depends upon the authentication algorithm specified by the OSPFv3 SA.
此值表示与此OSPFv3 SA关联的加密身份验证密钥。此密钥的长度是可变的，取决于OSPFv3 SA指定的身份验证算法。
o KeyStartAccept
o 按键开始接受
This value indicates the time that this OSPFv3 router will accept packets that have been created with this OSPFv3 SA.
此值表示此OSPFv3路由器将接受使用此OSPFv3 SA创建的数据包的时间。
o KeyStartGenerate
o 键值开始生成
This value indicates the time that this OSPFv3 router will begin using this OSPFv3 SA for OSPFv3 packet generation.
此值表示此OSPFv3路由器将开始使用此OSPFv3 SA生成OSPFv3数据包的时间。
o KeyStopGenerate
o 密钥生成
This value indicates the time that this OSPFv3 router will stop using this OSPFv3 SA for OSPFv3 packet generation.
此值表示此OSPFv3路由器将停止使用此OSPFv3 SA生成OSPFv3数据包的时间。
o KeyStopAccept
o Keyspaccept
This value indicates the time that this OSPFv3 router will stop accepting packets generated with this OSPFv3 SA.
此值表示此OSPFv3路由器停止接受使用此OSPFv3 SA生成的数据包的时间。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept is left unspecified, the time will default to 0, and the key will be used immediately. If KeyStopGenerate or KeyStopAccept is left unspecified, the time will default to infinity, and the key's lifetime will be infinite. When a new key replaces an old key, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
为了实现平滑的密钥转换，KeyStartAccept应该小于KeyStartGenerate，KeyspGenerate应该小于Keyspaccept。如果未指定KeyStartGenerate或KeyStartAccept，则时间将默认为0，并且将立即使用该键。如果KeyStopGenerate或keystopacept未指定，则时间将默认为无穷大，并且密钥的生存期将是无限的。当新密钥替换旧密钥时，新密钥的KeyStartGenerate时间必须小于或等于旧密钥的KeyspGenerate时间。
Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, the network operator SHOULD be notified, and the OSPFv3 packet MUST NOT be transmitted unauthenticated.
密钥存储应在系统重新启动期间保持不变，无论是热重启还是冷重启，以避免操作问题。如果与接口相关的最后一个密钥过期，则应通知网络运营商，且未经验证不得传输OSPFv3数据包。
The Authentication Trailer that is appended to the OSPFv3 protocol packet is described below:
附加到OSPFv3协议分组的认证尾部描述如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Authentication Trailer Format
图3：认证拖车格式
The various fields in the Authentication Trailer are as follows:
身份验证尾部中的各个字段如下所示：
o Authentication Type
o 身份验证类型
This 16-bit field identifies the type of authentication. The following values are defined in this specification:
此16位字段标识身份验证的类型。本规范中定义了以下值：
0 - Reserved. 1 - HMAC Cryptographic Authentication as described herein.
0-保留。1-如本文所述的HMAC加密认证。
o Auth Data Len
o 验证数据长度
This is the length in octets of the Authentication Trailer (AT), including both the 16-octet fixed header and the variable-length message digest.
这是身份验证尾部（AT）的长度（以八位字节为单位），包括16位八位字节的固定头和可变长度消息摘要。
o Reserved
o 含蓄的
This field is reserved. It SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
此字段是保留的。发送协议数据包时应将其设置为0，在接收协议数据包时必须忽略。
o Security Association Identifier (SA ID)
o 安全关联标识符（SA ID）
This 16-bit field maps to the authentication algorithm and the secret key used to create the message digest appended to the OSPFv3 protocol packet.
此16位字段映射到身份验证算法和用于创建附加到OSPFv3协议包的消息摘要的密钥。
Though the SA ID implies the algorithm, the HMAC output size should not be used by implementers as an implicit hint, because additional algorithms may be defined in the future that have the same output size.
尽管SA ID暗示了算法，但HMAC输出大小不应被实现者用作隐式提示，因为将来可能会定义具有相同输出大小的其他算法。
o Cryptographic Sequence Number
o 密码序列号
This is a 64-bit strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every OSPFv3 packet sent by the OSPFv3 router. Upon reception, the sequence number MUST be greater than the sequence number in the last accepted OSPFv3 packet of the same OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is considered a replayed packet and dropped. OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
这是一个64位严格递增的序列号，用于防止重播攻击。对于OSPFv3路由器发送的每个OSPFv3数据包，必须增加64位序列号。在接收时，序列号必须大于发送OSPFv3邻居最后接受的相同OSPFv3分组类型的OSPFv3分组中的序列号。否则，将OSPFv3分组视为重播分组并丢弃。如果按照[RFC4222]中的建议对不同类型的OSPFv3数据包进行优先级排序，则它们可能会无序到达。
OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). One mechanism for accomplishing this would be to use the high-order 32 bits of the sequence number as a wrap/boot count that is incremented anytime the OSPFv3 router loses its sequence number state. Sequence number wrap is described in Section 4.1.1.
实现本规范的OSPFv3路由器必须使用可用机制，在OSPFv3路由器的部署生命周期内（包括冷重启），保持序列号严格递增的特性。实现这一点的一种机制是使用序列号的高阶32位作为包裹/引导计数，该计数在OSPFv3路由器丢失其序列号状态时递增。第4.1.1节描述了序列号包装。
o Authentication Data
o 认证数据
This field contains variable data that is carrying the digest for the protocol packet and optional LLS data block.
此字段包含携带协议包摘要和可选LLS数据块的变量数据。
When incrementing the sequence number for each transmitted OSPFv3 packet, the sequence number should be treated as an unsigned 64-bit value. If the lower-order 32-bit value wraps, the higher-order 32-bit value should be incremented and saved in non-volatile storage. If by some chance the OSPFv3 router is deployed long enough that there is a possibility that the 64-bit sequence number may wrap, all keys, independent of their key distribution mechanism, MUST be reset to avoid the possibility of replay attacks. Once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage.
增加每个传输的OSPFv3数据包的序列号时，序列号应视为无符号64位值。如果低阶32位值换行，则高阶32位值应递增并保存在非易失性存储器中。如果碰巧OSPFv3路由器部署的时间足够长，以致64位序列号可能会被包装，则必须重置所有密钥（独立于密钥分发机制），以避免重播攻击的可能性。更换钥匙后，可以将高阶序列号重置为0并保存到非易失性存储器中。
Both the checksum calculation and verification are omitted for the OSPFv3 header checksum and the LLS data block checksum [RFC5613] when the OSPFv3 authentication mechanism described in this specification is used. This implies the following:
当使用本规范中描述的OSPFv3认证机制时，OSPFv3报头校验和和和LLS数据块校验和[RFC5613]的校验和计算和验证都被省略。这意味着：
o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum computation is omitted, and the OSPFv3 header checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest.
o 对于要传输的OSPFv3数据包，省略OSPFv3报头校验和计算，并且在计算OSPFv3认证尾消息摘要之前，OSPFv3报头校验和应设置为0。
o For OSPFv3 packets including an LLS data block to be transmitted, the OSPFv3 LLS data block checksum computation is omitted, and the OSPFv3 LLS data block checksum SHOULD be set to 0 prior to computation of the OSPFv3 Authentication Trailer message digest.
o 对于包括要传输的LLS数据块的OSPFv3分组，省略OSPFv3 LLS数据块校验和计算，并且在计算OSPFv3认证尾消息摘要之前，OSPFv3 LLS数据块校验和应设置为0。
o For received OSPFv3 packets including an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. However, if the OSPFv3 packet does include a non-zero OSPFv3 header checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification.
o 对于接收到的包含OSPFv3身份验证尾部的OSPFv3数据包，必须省略OSPFv3报头校验和验证。但是，如果OSPFv3数据包包含非零OSPFv3报头校验和，则接收方不会修改该数据包，只会将其包含在OSPFv3认证尾消息摘要验证中。
o For received OSPFv3 packets including an LLS data block and OSPFv3 Authentication Trailer, LLS data block checksum verification MUST be omitted. However, if the OSPFv3 packet does include an LLS data block with a non-zero checksum, it will not be modified by the receiver and will simply be included in the OSPFv3 Authentication Trailer message digest verification.
o 对于接收到的包括LLS数据块和OSPFv3身份验证尾部的OSPFv3数据包，必须省略LLS数据块校验和验证。然而，如果OSPFv3数据包确实包括具有非零校验和的LLS数据块，则接收机不会修改该数据块，而只会将其包括在OSPFv3认证尾消息摘要验证中。
As noted earlier, the SA ID maps to the authentication algorithm and the secret key used to generate and verify the message digest. This specification discusses the computation of OSPFv3 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode.
如前所述，SA ID映射到用于生成和验证消息摘要的认证算法和密钥。本规范讨论了在哈希消息认证码（HMAC）模式下使用NIST SHS系列算法时，OSPFv3加密认证数据的计算。
The currently valid algorithms (including mode) for OSPFv3 Cryptographic Authentication include:
OSPFv3加密身份验证的当前有效算法（包括模式）包括：
o HMAC-SHA-1,
o HMAC-SHA-1，
o HMAC-SHA-256,
o HMAC-SHA-256，
o HMAC-SHA-384, and
o HMAC-SHA-384，以及
o HMAC-SHA-512.
o HMAC-SHA-512。
Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512.
其中，本规范的实现必须至少包括对HMAC-SHA-256的支持，并应包括对HMAC-SHA-1的支持，还可能包括对HMAC-SHA-384和HMAC-SHA-512的支持。
Implementations of this specification MUST use HMAC-SHA-256 as the default authentication algorithm.
本规范的实现必须使用HMAC-SHA-256作为默认身份验证算法。
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key prior to use. Other protocols using Cryptographic Authentication as specified herein MUST similarly append their respective Cryptographic Protocol IDs to their keys in this step. Refer to the IANA Considerations (Section 7).
为了防止对共享公共密钥的协议的跨协议重放攻击，在使用前将两个八位组OSPFv3加密协议ID附加到身份验证密钥。在此步骤中，使用本文规定的加密身份验证的其他协议必须类似地将其各自的加密协议ID附加到其密钥。请参阅IANA注意事项（第7节）。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198-1], is used:
在下面的算法描述中，使用了与[FIPS-198-1]一致的以下术语：
H is the specific hashing algorithm (e.g., SHA-256).
H是特定的散列算法（例如，SHA-256）。
K is the Authentication Key from the OSPFv3 Security Association.
K是来自OSPFv3安全关联的身份验证密钥。
Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet OSPFv3 Cryptographic Protocol ID.
Ks是一种特定于协议的身份验证密钥，通过将身份验证密钥（K）与两个八位组OSPFv3加密协议ID相加获得。
Ko is the cryptographic key used with the hash algorithm.
Ko是与哈希算法一起使用的加密密钥。
B is the block size of H, measured in octets rather than bits. Note that B is the internal block size, not the hash size.
B是H的块大小，以八位字节而不是位来测量。请注意，B是内部块大小，而不是散列大小。
For SHA-1 and SHA-256: B == 64
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
L是散列的长度，以八位字节而不是位来度量。
XOR is the exclusive-or operation.
XOR是异或运算。
Opad is the hexadecimal value 0x5c repeated B times.
Opad是十六进制值0x5c，重复B次。
Ipad is the hexadecimal value 0x36 repeated B times.
Ipad是十六进制值0x36，重复B次。
Apad is a value that is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets.
Apad是一个与哈希输出或消息摘要长度相同的值。前16个八位字节包含IPv6源地址，后跟重复（L-16）/4次的十六进制值0x878FE1F3。这意味着哈希输出的长度始终至少为16个八位字节。
1. Preparation of the Key
1. 钥匙的准备
The OSPFv3 Cryptographic Protocol ID is appended to the Authentication Key (K), yielding a Protocol-Specific Authentication Key (Ks). In this application, Ko is always L octets long. While [RFC2104] supports a key that is up to B octets long, this application uses L as the Ks length consistent with [RFC4822], [RFC5310], and [RFC5709]. According to [FIPS-198-1], Section 3, keys greater than L octets do not significantly increase the function strength. Ks is computed as follows:
OSPFv3加密协议ID附加到认证密钥（K）后，产生协议特定的认证密钥（Ks）。在此应用程序中，Ko的长度始终为L个八位字节。虽然[RFC2104]支持长度不超过B个八位字节的密钥，但此应用程序使用L作为与[RFC4822]、[RFC5310]和[RFC5709]一致的Ks长度。根据[FIPS-198-1]第3节，大于L个八位组的键不会显著增加功能强度。Ks的计算如下：
If Ks is L octets long, then Ko is equal to Ks. If Ks is more than L octets long, then Ko is set to H(Ks). If Ks is less than L octets long, then Ko is set to the value of Ks, with zeros appended to the end of Ks such that Ko is L octets long.
如果Ks是L个八位字节长，那么Ko等于Ks。如果Ks的长度超过L个八位字节，那么Ko被设置为H（Ks）。如果Ks的长度小于L个八位字节，则将Ko设置为Ks的值，并在Ks的末尾附加零，以使Ko的长度为L个八位字节。
2. First-Hash
2. 第一散列
First, the OSPFv3 packet's Authentication Data field in the Authentication Trailer is filled with the value Apad. This is very similar to the appendage described in [RFC2328], Appendix D.4.3, Items (6)(a) and (6)(d)).
首先，用值Apad填充身份验证尾部中OSPFv3数据包的身份验证数据字段。这与[RFC2328]附录D.4.3第（6）（a）项和第（6）（D）项中描述的附录非常相似。
Then, a First-Hash, also known as the inner hash, is computed as follows:
然后，第一散列（也称为内部散列）计算如下：
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
第一个Hash=H（Ko-XOR-Ipad | |（OSPFv3数据包））
When XORing Ko and Ipad, Ko will be padded with zeros to the length of Ipad.
当XORing Ko和Ipad时，Ko将用零填充到Ipad的长度。
Implementation Note: The First-Hash above includes the Authentication Trailer as well as the OSPFv3 packet as per [RFC2328], Appendix D.4.3, and the LLS data block, if present [RFC5613].
实施说明：上述第一个散列包括身份验证尾部以及符合[RFC2328]附录D.4.3的OSPFv3数据包，以及LLS数据块（如果存在[RFC5613]）。
The definition of Apad (above) ensures that it is always the same length as the hash output. This is consistent with RFC 2328. Note that the "(OSPFv3 Packet)" referenced in the First-Hash function above includes both the optional LLS data block and the OSPFv3 Authentication Trailer.
Apad（如上）的定义确保它始终与散列输出的长度相同。这与RFC 2328一致。注意，上面第一个散列函数中引用的“（OSPFv3包）”包括可选的LLS数据块和OSPFv3认证尾部。
The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; for SHA-384, 48 octets; and for SHA-512, 64 octets.
SHA-1的摘要长度为20个八位字节；对于SHA-256，32个八位字节；对于SHA-384，48个八位组；对于SHA-512，64个八位组。
3. Second-Hash
3. 第二散列
Then a Second-Hash, also known as the outer hash, is computed as follows:
然后，第二个散列（也称为外部散列）计算如下：
Second-Hash = H(Ko XOR Opad || First-Hash)
第二个散列=H（Ko-XOR-Opad | |第一个散列）
When XORing Ko and Opad, Ko will be padded with zeros to the length of Opad.
当XORing Ko和Opad时，Ko将用零填充到Opad的长度。
4. Result
4. 后果
The resulting Second-Hash becomes the authentication data that is sent in the Authentication Trailer of the OSPFv3 packet. The length of the authentication data is always identical to the message digest size of the specific hash function H that is being used.
产生的第二散列成为在OSPFv3分组的认证尾部中发送的认证数据。身份验证数据的长度始终与正在使用的特定哈希函数H的消息摘要大小相同。
This also means that the use of hash functions with larger output sizes will also increase the size of the OSPFv3 packet as transmitted on the wire.
这也意味着使用具有更大输出大小的散列函数也将增加在线传输的OSPFv3数据包的大小。
Implementation Note: [RFC2328], Appendix D specifies that the Authentication Trailer is not counted in the OSPF packet's own Length field but is included in the packet's IP Length field. Similar to this, the Authentication Trailer is not included in the OSPFv3 header length but is included in the IPv6 header payload length.
实施说明：[RFC2328]，附录D规定认证尾部不计入OSPF数据包自身的长度字段，而是包含在数据包的IP长度字段中。与此类似，身份验证尾部不包括在OSPFv3报头长度中，而是包括在IPv6报头有效负载长度中。
A router would determine that OSPFv3 is using an Authentication Trailer (AT) by examining the AT-bit in the Options field in the OSPFv3 header for Hello and Database Description packets. The specification in the Hello and Database Description options indicates that other OSPFv3 packets will include the Authentication Trailer.
路由器将通过检查OSPFv3报头中选项字段中的AT位来确定OSPFv3正在使用身份验证尾部（AT），以查找Hello和数据库描述数据包。Hello和Database Description选项中的规范指出，其他OSPFv3数据包将包括身份验证尾部。
The AT is accessed using the OSPFv3 packet header length to access the data after the OSPFv3 packet and, if an LLS data block [RFC5613] is present, using the LLS data block length to access the data after the LLS data block. The L-bit in the OSPFv3 options in Hello and Database Description packets is examined to determine if an LLS data block is present. If an LLS data block is present (as specified by the L-bit), it is included along with the OSPFv3 Hello or Database Description packet in the Cryptographic Authentication computation.
使用OSPFv3包头长度访问AT，以访问OSPFv3包后的数据，如果存在LLS数据块[RFC5613]，则使用LLS数据块长度访问LLS数据块后的数据。检查Hello和数据库描述数据包中OSPFv3选项中的L位，以确定是否存在LLS数据块。如果存在LLS数据块（由L位指定），则它将与OSPFv3 Hello或数据库描述数据包一起包含在加密身份验证计算中。
Due to the placement of the AT following the LLS data block and the fact that the LLS data block is included in the Cryptographic Authentication computation, OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in the OSPFv3 options and using the length in the LLS data block to access the AT. It is RECOMMENDED that OSPFv3 routers supporting this specification fully support OSPFv3 Link-Local Signaling [RFC5613].
由于AT位于LLS数据块之后，且LLS数据块包含在加密身份验证计算中，支持本规范的OSPFv3路由器必须至少支持检查OSPFv3选项中的L位，并使用LLS数据块中的长度访问AT。建议支持此规范的OSPFv3路由器完全支持OSPFv3链路本地信令[RFC5613]。
If usage of the AT, as specified herein, is configured for an OSPFv3 link, OSPFv3 Hello and Database Description packets with the AT-bit clear in the options will be dropped. All OSPFv3 packet types will be dropped if the AT is configured for the link and the IPv6 header length is less than the amount necessary to include an Authentication Trailer.
如果如本文所述，为OSPFv3链路配置AT的使用，则将丢弃选项中AT位为clear的OSPFv3 Hello和数据库描述分组。如果为链路配置了AT，并且IPv6报头长度小于包含身份验证尾部所需的长度，则所有OSPFv3数据包类型都将被丢弃。
The receiving interface's OSPFv3 SA is located using the SA ID in the received AT. If the SA is not found, or if the SA is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPFv3 packet is dropped.
接收接口的OSPFv3 SA使用接收AT中的SA ID定位。如果找不到SA，或者SA接收无效（即当前时间<KeyStartAccept或当前时间>=Keyspaccept），则OSPFv3数据包被丢弃。
If the cryptographic sequence number in the AT is less than or equal to the last sequence number in the last OSPFv3 packet of the same OSPFv3 type successfully received from the neighbor, the OSPFv3
如果AT中的加密序列号小于或等于从邻居成功接收到的相同OSPFv3类型的最后一个OSPFv3数据包中的最后一个序列号，则OSPFv3
packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 packets of different types may arrive out of order if they are prioritized as recommended in [RFC4222].
必须丢弃数据包，并记录错误事件。如果按照[RFC4222]中的建议对不同类型的OSPFv3数据包进行优先级排序，则它们可能会无序到达。
Authentication-algorithm-dependent processing needs to be performed, using the algorithm specified by the appropriate OSPFv3 SA for the received packet.
需要使用适当的OSPFv3 SA为接收的数据包指定的算法来执行认证算法相关的处理。
Before an implementation performs any processing, it needs to save the values of the Authentication Data field from the Authentication Trailer appended to the OSPFv3 packet.
在实现执行任何处理之前，它需要保存附加到OSPFv3数据包的认证尾部的认证数据字段的值。
It should then set the Authentication Data field with Apad before the authentication data is computed (as described in Section 4.5). The calculated data is compared with the received authentication data in the Authentication Trailer. If the two do not match, the packet MUST be discarded, and an error event SHOULD be logged.
然后，在计算身份验证数据之前，应使用Apad设置身份验证数据字段（如第4.5节所述）。将计算出的数据与认证拖车中接收到的认证数据进行比较。如果两者不匹配，则必须丢弃数据包，并记录错误事件。
After the OSPFv3 packet has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for each OSPFv3 packet type received from the neighbor. The saved cryptographic sequence numbers will be used for replay checking for subsequent packets received from the neighbor.
成功验证OSPFv3数据包后，实现必须存储从邻居接收的每个OSPFv3数据包类型的64位加密序列号。保存的加密序列号将用于重播检查从邻居接收的后续数据包。
All OSPFv3 routers participating on a link SHOULD be migrated to OSPFv3 authentication at the same time. As with OSPFv2 authentication, a mismatch in the SA ID, Authentication Type, or message digest will result in failure to form an adjacency. For multi-access links, communities of OSPFv3 routers could be migrated using different Interface Instance IDs. However, at least one router would need to form adjacencies between both the OSPFv3 routers including and not including the Authentication Trailer. This would result in sub-optimal routing as well as added complexity and is only recommended in cases where authentication is desired on the link and migrating all the routers on the link at the same time isn't feasible.
所有参与链路的OSPFv3路由器应同时迁移到OSPFv3身份验证。与OSPFv2身份验证一样，SA ID、身份验证类型或消息摘要中的不匹配将导致无法形成邻接。对于多访问链路，可以使用不同的接口实例ID迁移OSPFv3路由器社区。然而，至少一个路由器将需要在包括和不包括认证拖车的两个OSPFv3路由器之间形成邻接。这将导致次优路由以及增加复杂性，仅在需要在链路上进行身份验证且同时迁移链路上的所有路由器不可行的情况下才建议这样做。
In support of uninterrupted deployment, an OSPFv3 router implementing this specification MAY implement a transition mode where it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets. This is provided as a
为了支持不间断部署，实现本规范的OSPFv3路由器可以实现转换模式，其中它在发送的分组中包括认证尾，但在接收的分组中不验证该信息。这是作为
transition aid for networks in the process of migrating to the authentication mechanism described in this specification. More specifically:
迁移到本规范中描述的身份验证机制过程中的网络过渡辅助工具。更具体地说：
1. OSPFv3 routers in transition mode will include the OSPFv3 Authentication Trailer in transmitted packets and set the AT-bit in the Options field of transmitted Hello and Database Description packets. OSPFv3 routers receiving these packets and not having authentication configured will ignore the Authentication Trailer and AT-bit.
1. 处于转换模式的OSPFv3路由器将在传输的数据包中包含OSPFv3认证拖车，并在传输的Hello和数据库描述数据包的选项字段中设置AT位。接收这些数据包且未配置身份验证的OSPFv3路由器将忽略身份验证尾部和AT位。
2. OSPFv3 routers in transition mode will also calculate and set the OSPFv3 header checksum and the LLS data block checksum in transmitted packets so that they will not be dropped by OSPFv3 routers without authentication configured.
2. 处于转换模式的OSPFv3路由器还将计算并设置传输数据包中的OSPFv3报头校验和和和LLS数据块校验和，以便在未配置身份验证的情况下，OSPFv3路由器不会丢弃这些校验和。
3. OSPFv3 routers in transition mode will authenticate received packets that either have the AT-bit set in the Options field for Hello or Database Description packets or are from a neighbor that previously set the AT-bit in the Options field of successfully authenticated Hello and Database Description packets.
3. 处于转换模式的OSPFv3路由器将对接收到的数据包进行身份验证，这些数据包要么在Hello或数据库描述数据包的选项字段中设置了AT位，要么来自之前在成功身份验证的Hello和数据库描述数据包的选项字段中设置了AT位的邻居。
4. OSPFv3 routers in transition mode will also accept packets without the Options field AT-bit set in Hello and Database Description packets. These packets will be assumed to be from OSPFv3 routers without authentication configured, and they will not be authenticated. Additionally, the OSPFv3 header checksum and LLS data block checksum will be validated.
4. 处于转换模式的OSPFv3路由器也将接受在Hello和数据库描述数据包中未设置位的选项字段的数据包。假设这些数据包来自未配置身份验证的OSPFv3路由器，并且它们不会被身份验证。此外，将验证OSPFv3报头校验和和和LLS数据块校验和。
This document proposes extensions to OSPFv3 that would make it more secure than OSPFv3 as defined in [RFC5340]. It does not provide confidentiality, as a routing protocol contains information that does not need to be kept secret. It does, however, provide means to authenticate the sender of packets that are of interest. It addresses all the security issues that have been identified in [RFC6039] and [RFC6506].
本文件建议对OSPFv3进行扩展，使其比[RFC5340]中定义的OSPFv3更安全。它不提供机密性，因为路由协议包含不需要保密的信息。然而，它确实提供了对感兴趣的数据包的发送者进行身份验证的方法。它解决了[RFC6039]和[RFC6506]中确定的所有安全问题。
It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet but rather is being used to confirm that the packet has indeed been issued by a router that has access to the Authentication Key.
应当注意，本文档中描述的认证方法不是用于认证数据包的特定发起人，而是用于确认数据包确实是由能够访问认证密钥的路由器发出的。
Deployments SHOULD use sufficiently long and random values for the Authentication Key so that guessing and other cryptographic attacks on the key are not feasible in their environments. Furthermore, it
部署应为身份验证密钥使用足够长的随机值，以便在其环境中不可能对密钥进行猜测和其他加密攻击。此外，它
is RECOMMENDED that Authentication Keys incorporate at least 128 pseudorandom bits to minimize the risk of such attacks. In support of these recommendations, management systems SHOULD support hexadecimal input of Authentication Keys.
建议身份验证密钥至少包含128个伪随机位，以将此类攻击的风险降至最低。为了支持这些建议，管理系统应支持认证密钥的十六进制输入。
Deployments that support a transitionary state but interoperate with routers that do not support this authentication method may be exposed to unauthenticated data during the transition period.
支持过渡状态但与不支持此身份验证方法的路由器互操作的部署可能在过渡期间暴露于未经身份验证的数据。
The mechanism described herein is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the effort required for an adversary to successfully attack the OSPFv3 protocol, while not causing undue implementation, deployment, or operational complexity.
本文描述的机制并不完善，也不需要完善。相反，这种机制意味着对手成功攻击OSPFv3协议所需的努力显著增加，同时不会造成不当的实施、部署或操作复杂性。
Refer to [RFC4552] for additional considerations on manual keying.
有关手动键控的其他注意事项，请参阅[RFC4552]。
This document obsoletes RFC 6506; thus, IANA has updated the references in existing registries that pointed to RFC 6506 to point to this document. This is the only IANA action requested by this document.
本文件淘汰RFC 6506；因此，IANA更新了现有注册中心中指向RFC 6506的参考文献，以指向本文件。这是本文件要求的唯一IANA行动。
IANA previously allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 bits)" registry as described in Section 2.1.
IANA先前在“OSPFv3选项（24位）”注册表中分配了AT位（0x000400），如第2.1节所述。
IANA previously created the "Open Shortest Path First v3 (OSPFv3) Authentication Trailer Options" registry. This registry includes the "OSPFv3 Authentication Types" registry, which defines valid values for the Authentication Type field in the OSPFv3 Authentication Trailer. The registration procedure is Standards Action [RFC5226].
IANA之前创建了“开放最短路径优先v3（OSPFv3）认证拖车选项”注册表。此注册表包括“OSPFv3身份验证类型”注册表，该注册表为OSPFv3身份验证尾部中的身份验证类型字段定义有效值。注册程序为标准行动[RFC5226]。
+-------------+-----------------------------------+
|Value | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
+-------------+-----------------------------------+
|Value | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
OSPFv3 Authentication Types
OSPFv3身份验证类型
Finally, IANA previously created the "Keying and Authentication for Routing Protocols (KARP) Parameters" registry. This registry includes the "Cryptographic Protocol ID" registry, which provides
最后，IANA先前创建了“路由协议（KARP）参数的键控和身份验证”注册表。此注册表包括“加密协议ID”注册表，该注册表提供
unique protocol-specific values for cryptographic applications, including but not limited to prevention of cross-protocol replay attacks. Values can be assigned for both native IPv4/IPv6 protocols and UDP/TCP protocols. The registration procedure is Standards Action.
加密应用程序的唯一协议特定值，包括但不限于防止跨协议重播攻击。可以为本机IPv4/IPv6协议和UDP/TCP协议分配值。注册程序是标准行动。
+-------------+----------------------+
| Value/Range | Designation |
+-------------+----------------------+
| 0 | Reserved |
| | |
| 1 | OSPFv3 |
| | |
| 2-65535 | Unassigned |
+-------------+----------------------+
+-------------+----------------------+
| Value/Range | Designation |
+-------------+----------------------+
| 0 | Reserved |
| | |
| 1 | OSPFv3 |
| | |
| 2-65535 | Unassigned |
+-------------+----------------------+
Cryptographic Protocol ID
加密协议ID
[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月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[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月。
[FIPS-180-4] US National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS-180-4]美国国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-42012年3月。
[FIPS-198-1] US National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008.
[FIPS-198-1]美国国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，FIPS PUB 198-12008年7月。
[MANUAL-KEY] Bhatia, M., Hartman, S., and D. Zhang, "Security Extension for OSPFv2 when using Manual Key Management", Work in Progress, February 2011.
[手动密钥]Bhatia，M.，Hartman，S.，和D.Zhang，“使用手动密钥管理时OSPFv2的安全扩展”，正在进行的工作，2011年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC4222] Choudhury, G., Ed., "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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5613]Zinin，A.，Roy，A.，Nguyen，L.，Friedman，B.，和D.Yeung，“OSPF链路本地信令”，RFC 5613，2009年8月。
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL Packets", RFC 5879, May 2010.
[RFC5879]Kivinen，T.和D.McDonald，“检测ESP-NULL数据包的启发式”，RFC 5879，2010年5月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[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月。
First and foremost, thanks to the US National Institute of Standards and Technology for their work on the SHA [FIPS-180-4] and HMAC [FIPS-198-1].
首先，感谢美国国家标准与技术研究所在SHA[FIPS-180-4]和HMAC[FIPS-198-1]方面的工作。
Thanks also need to go to the authors of the HMAC-SHA authentication RFCs, including [RFC4822], [RFC5310], and [RFC5709]. The basic HMAC-SHA procedures were originally described by Ran Atkinson in [RFC4822].
还需要感谢HMAC-SHA认证RFC的作者，包括[RFC4822]、[RFC5310]和[RFC5709]。基本HMAC-SHA程序最初由Ran Atkinson在[RFC4822]中描述。
Also, thanks to Ran Atkinson for help in the analysis of RFC 6506 errata.
另外，感谢Ran Atkinson在RFC 6506勘误表分析中提供的帮助。
Thanks to Srinivasan K L and Marek Karasek for their identification and submission of RFC 6506 errata.
感谢Srinivasan K L和Marek Karasek的鉴定和RFC 6506勘误表的提交。
Thanks to Sam Hartman for discussions on replay mitigation and the use of a 64-bit strictly increasing sequence number. Also, thanks to Sam for comments during IETF last call with respect to the OSPFv3 SA and the sharing of keys between protocols.
感谢Sam Hartman关于重播缓解和使用64位严格递增序列号的讨论。另外，感谢Sam在IETF最后一次呼叫期间对OSPFv3 SA和协议间密钥共享的评论。
Thanks to Michael Barnes for numerous comments and strong input on the coverage of LLS by the Authentication Trailer (AT).
感谢Michael Barnes就认证预告片（AT）对LLS的报道发表的大量评论和有力的意见。
Thanks to Marek Karasek for providing the specifics with respect to backward-compatible transition mode.
感谢Marek Karasek提供有关向后兼容转换模式的详细信息。
Thanks to Michael Dubrovskiy and Anton Smirnov for comments on document revisions.
感谢Michael Dubrovskiy和Anton Smirnov对文件修订的意见。
Thanks to Rajesh Shetty for numerous comments, including the suggestion to include an Authentication Type field in the Authentication Trailer for extendibility.
感谢Rajesh Shetty的众多评论，包括建议在认证拖车中包含一个认证类型字段以实现可扩展性。
Thanks to Uma Chunduri for suggesting that we may want to protect the IPv6 source address even though OSPFv3 uses the Router ID for neighbor identification.
感谢Uma Chunduri建议我们可能希望保护IPv6源地址，即使OSPFv3使用路由器ID进行邻居识别。
Thanks to Srinivasan K L, Shraddha H, Alan Davey, Russ White, Stan Ratliff, and Glen Kent for their support and review comments.
感谢Srinivasan K L、Shraddha H、Alan Davey、Russ White、Stan Ratliff和Glen Kent的支持和评论。
Thanks to Alia Atlas for comments made under the purview of the Routing Directorate review.
感谢Alia Atlas在路由理事会审查范围内提出的意见。
Thanks to Stephen Farrell for comments during the IESG review. Stephen was also involved in the discussion of cross-protocol attacks.
感谢Stephen Farrell在IESG审查期间的评论。Stephen还参与了跨协议攻击的讨论。
Thanks to Brian Carpenter for comments made during the Gen-ART review.
感谢Brian Carpenter在Gen ART review期间发表的评论。
Thanks to Victor Kuarsingh for the OPS-DIR review.
感谢Victor Kuarsingh的OPS-DIR审查。
Thanks to Brian Weis for the SEC-DIR review.
感谢Brian Weis的SEC-DIR审查。
Authors' Addresses
作者地址
Manav Bhatia Alcatel-Lucent Bangalore India
印度班加罗尔朗讯公司
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
Vishwas Manral Ionios公司，美国加利福尼亚州圣何塞摩尔帕克大道4100号，邮编95117
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com
Acee Lindem Ericsson 301 Midenhall Way Cary, NC 27513 USA
美国北卡罗来纳州米登霍尔大道301号，邮编27513
EMail: acee.lindem@ericsson.com
EMail: acee.lindem@ericsson.com