Network Working Group M. Bhatia
Request for Comments: 5709 Alcatel-Lucent
Updates: 2328 V. Manral
Category: Standards Track IP Infusion
M. Fanto
Aegis Data Security
R. White
M. Barnes
Cisco Systems
T. Li
Ericsson
R. Atkinson
Extreme Networks
October 2009
Network Working Group M. Bhatia
Request for Comments: 5709 Alcatel-Lucent
Updates: 2328 V. Manral
Category: Standards Track IP Infusion
M. Fanto
Aegis Data Security
R. White
M. Barnes
Cisco Systems
T. Li
Ericsson
R. Atkinson
Extreme Networks
October 2009
OSPFv2 HMAC-SHA Cryptographic Authentication
OSPFv2 HMAC-SHA加密身份验证
Abstract
摘要
This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328.
本文档描述了国家标准与技术研究所（NIST）安全哈希标准算法系列如何与OSPF版本2的内置加密身份验证机制一起使用。这将更新但不会取代RFC 2328中指定的加密身份验证机制。
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 and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
A variety of risks exist when deploying any routing protocol [Bell89]. This document provides an update to OSPFv2 Cryptographic Authentication, which is specified in Appendix D of RFC 2328. This document does not deprecate or supercede RFC 2328. OSPFv2, itself, is defined in RFC 2328 [RFC2328].
部署任何路由协议时都存在各种风险[Bell89]。本文件提供了RFC 2328附录D中规定的OSPFv2加密认证的更新。本文件不反对或取代RFC 2328。OSPFv2本身在RFC2328[RFC2328]中定义。
This document adds support for Secure Hash Algorithms (SHA) defined in the US NIST Secure Hash Standard (SHS), which is defined by NIST FIPS 180-2. [FIPS-180-2] 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 is used [FIPS-198].
本文件增加了对美国NIST安全哈希标准（SHS）中定义的安全哈希算法（SHA）的支持，该标准由NIST FIPS 180-2定义。[FIPS-180-2]包括SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。使用NIST FIPS 198中定义的哈希消息认证码（HMAC）认证模式[FIPS-198]。
It is believed that [RFC2104] is mathematically identical to [FIPS-198] and it is also believed that algorithms in [RFC4634] are mathematically identical to [FIPS-180-2].
人们认为[RFC2104]在数学上与[FIPS-198]相同，也认为[RFC4634]中的算法在数学上与[FIPS-180-2]相同。
The creation of this addition to OSPFv2 was driven by operator requests that they be able to use the NIST SHS family of algorithms in the NIST HMAC mode, instead of being forced to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic Authentication. Cryptographic matters are discussed in more detail in the Security Considerations section of this document.
操作员要求他们能够在NIST HMAC模式下使用NIST SHS系列算法，而不是被迫在OSPFv2加密身份验证中使用Keyed-MD5算法和模式。本文档的“安全注意事项”部分将更详细地讨论加密问题。
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]中所述进行解释。
All OSPF protocol exchanges can be authenticated. The OSPF packet header (see Appendix A.3.1 of RFC 2328) includes an Authentication Type field and 64 bits of data for use by the appropriate authentication scheme (determined by the Type field).
所有OSPF协议交换都可以通过身份验证。OSPF数据包头（见RFC 2328附录A.3.1）包括一个认证类型字段和64位数据，供适当的认证方案（由类型字段确定）使用。
The authentication type is configurable on a per-interface (or, equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis.
身份验证类型可在每个接口（或等效地，在每个网络/子网）的基础上配置。还可以根据每个接口配置其他身份验证数据。
OSPF authentication types 0, 1, and 2 are defined by RFC 2328. This document provides an update to RFC 2328 that is only applicable to Authentication Type 2, "Cryptographic Authentication".
OSPF身份验证类型0、1和2由RFC 2328定义。本文档提供了对RFC 2328的更新，该更新仅适用于认证类型2“加密认证”。
Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks [RFC1704].
使用此身份验证类型，将在连接到公共网络/子网的所有路由器中配置共享密钥。对于每个OSPF协议包，密钥用于生成/验证附加到OSPF包末尾的“消息摘要”。消息摘要是OSPF协议包和密钥的单向函数。由于密钥永远不会通过网络发送，因此提供了针对被动攻击的保护[RFC1704]。
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification discusses the computation of OSPFv2 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode. Please also see RFC 2328, Appendix D.
用于生成和验证消息摘要的算法由密钥隐式指定。本规范讨论了在哈希消息认证码（HMAC）模式下使用NIST SHS算法系列时，OSPFv2加密认证数据的计算。另请参见RFC 2328，附录D。
With the additions in this document, the currently valid algorithms (including mode) for OSPFv2 Cryptographic Authentication include:
通过本文件中的补充，目前用于OSPFv2加密身份验证的有效算法（包括模式）包括：
Keyed-MD5 (defined in RFC 2328, Appendix D) HMAC-SHA-1 (defined here) HMAC-SHA-256 (defined here) HMAC-SHA-384 (defined here) HMAC-SHA-512 (defined here)
Keyed-MD5（定义见RFC 2328附录D）HMAC-SHA-1（定义见此处）HMAC-SHA-256（定义见此处）HMAC-SHA-384（定义见此处）HMAC-SHA-512（定义见此处）
Of the above, implementations of this specification MUST include support for at least:
在上述各项中，本规范的实施必须至少包括对以下各项的支持：
HMAC-SHA-256
HMAC-SHA-256
and SHOULD include support for:
并应包括支持：
HMAC-SHA-1
HMAC-SHA-1
and SHOULD also (for backwards compatibility with existing implementations and deployments) include support for:
并且还应（为了与现有实现和部署向后兼容）包括对以下各项的支持：
Keyed-MD5
键控MD5
and MAY also include support for:
还可能包括对以下方面的支持：
HMAC-SHA-384 HMAC-SHA-512
HMAC-SHA-384 HMAC-SHA-512
An implementation of this specification MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value that is configured into that OSPFv2 router.
本规范的实现必须允许网络运营商配置该实现支持的任何身份验证算法，以便与配置到该OSPFv2路由器中的任何给定KeyID值一起使用。
The overall cryptographic authentication process defined in Appendix D of RFC 2328 remains unchanged. However, the specific cryptographic details (i.e., SHA rather than MD5, HMAC rather than Keyed-Hash) are defined herein. To reduce the potential for confusion, this section minimises the repetition of text from RFC 2328, Appendix D, which is incorporated here by reference [RFC2328].
RFC 2328附录D中定义的整体加密身份验证过程保持不变。然而，这里定义了特定的密码细节（即，SHA而不是MD5，HMAC而不是键控散列）。为了减少混淆的可能性，本节尽量减少RFC 2328附录D中文本的重复，该附录通过引用[RFC2328]并入此处。
First, following the procedure defined in RFC 2328, Appendix D, select the appropriate OSPFv2 Security Association for use with this packet and set the KeyID field to the KeyID value of that OSPFv2 Security Association.
首先，按照RFC 2328附录D中定义的程序，选择与此数据包一起使用的适当OSPFv2安全关联，并将KeyID字段设置为该OSPFv2安全关联的KeyID值。
Second, set the Authentication Type to Cryptographic Authentication, and set the Authentication Data Length field to the length (measured in bytes, not bits) of the cryptographic hash that will be used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2 Cryptographic Authentication, the Authentication Data Length is equal to the normal hash output length (measured in bytes) for the specific NIST SHS algorithm in use. For example, with NIST SHA-256, the Authentication Data Length is 32 bytes.
其次，将身份验证类型设置为Cryptographic Authentication，并将身份验证数据长度字段设置为将要使用的加密散列的长度（以字节为单位，而不是以位为单位）。当任何NIST SHS算法在HMAC模式下使用OSPFv2加密身份验证时，身份验证数据长度等于所用特定NIST SHS算法的正常哈希输出长度（以字节为单位）。例如，对于NIST SHA-256，身份验证数据长度为32字节。
Third, the 32-bit cryptographic sequence number is set in accordance with the procedures in RFC 2328, Appendix D that are applicable to the Cryptographic Authentication type.
第三，根据RFC 2328附录D中适用于加密认证类型的程序设置32位加密序列号。
Fourth, the message digest is then calculated and appended to the OSPF packet, as described below in Section 3.3. The KeyID, Authentication Algorithm, and Authentication Key to be used for calculating the digest are all components of the selected OSPFv2 Security Association. Input to the authentication algorithm consists of the OSPF packet and the secret key.
第四，然后计算消息摘要并将其附加到OSPF数据包中，如下文第3.3节所述。用于计算摘要的密钥ID、身份验证算法和身份验证密钥都是所选OSPFv2安全关联的组件。认证算法的输入由OSPF数据包和密钥组成。
This document uses the term OSPFv2 Security Association (OSPFv2 SA) to refer to the authentication key information defined in Section D.3 of RFC 2328. The OSPFv2 protocol does not include an in-band mechanism to create or manage OSPFv2 Security Associations. The parameters of an OSPFv2 Security Association are updated to be:
本文件使用术语OSPFv2安全关联（OSPFv2 SA）来指RFC 2328第D.3节中定义的认证密钥信息。OSPFv2协议不包括用于创建或管理OSPFv2安全关联的带内机制。OSPFv2安全关联的参数更新为：
Key Identifier (KeyID) This is an 8-bit unsigned value used to uniquely identify an OSPFv2 SA and is configured either by the router administrator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver uses this to locate the appropriate OSPFv2 SA to use. The sender puts this KeyID value in the OSPF packet based on the active OSPF configuration.
密钥标识符（KeyID）这是一个8位无符号值，用于唯一标识OSPFv2 SA，由路由器管理员（或将来可能由IETF指定的某个密钥管理协议）配置。接收器使用此信息定位要使用的适当OSPFv2 SA。发送方根据活动OSPF配置将此KeyID值放入OSPF数据包中。
Authentication Algorithm This indicates the authentication algorithm (and also the cryptographic mode, such as HMAC) to be used. This information SHOULD never be sent over the wire in cleartext form. At present, valid values are Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
认证算法这表示要使用的认证算法（以及加密模式，如HMAC）。此信息不应以明文形式通过网络发送。目前，有效值为Keyed-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512。
Authentication Key This is the cryptographic key used for cryptographic authentication with this OSPFv2 SA. This value SHOULD never be sent over the wire in cleartext form. This is noted as "K" in Section 3.3 below.
身份验证密钥这是用于使用此OSPFv2 SA进行加密身份验证的加密密钥。此值不应以明文形式通过导线发送。这在下文第3.3节中被称为“K”。
Key Start Accept The time that this OSPF router will accept packets that have been created with this OSPF Security Association.
Key Start Accept此OSPF路由器将接受使用此OSPF安全关联创建的数据包的时间。
Key Start Generate The time that this OSPF router will begin using this OSPF Security Association for OSPF packet generation.
密钥开始生成此OSPF路由器开始使用此OSPF安全关联生成OSPF数据包的时间。
Key Stop Generate The time that this OSPF router will stop using this OSPF Security Association for OSPF packet generation.
密钥停止生成此OSPF路由器将停止使用此OSPF安全关联生成OSPF数据包的时间。
Key Stop Accept The time that this OSPF router will stop accepting packets generated with this OSPF Security Association.
Key Stop Accept此OSPF路由器将停止接受使用此OSPF安全关联生成的数据包的时间。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left
为了实现平滑的密钥转换，KeyStartAccept应小于KeyStartGenerate，KeyspGenerate应小于Keyspaccept。如果保留KeyStopGenerate和KeyStopAccept
unspecified, the key's lifetime is infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
未指定，密钥的生存期是无限的。当新密钥替换旧密钥时，新密钥的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, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
密钥存储应在系统重新启动期间保持不变，无论是热重启还是冷重启，以避免操作问题。如果与接口关联的最后一个密钥过期，则无法恢复到未经验证的状态，并且不建议中断路由。因此，路由器应向网络管理器发送“上次验证密钥到期”通知，并将密钥视为具有无限生存期，直到延长生存期、通过网络管理删除密钥或配置新密钥为止。
This describes the computation of the Authentication Data value when any NIST SHS algorithm is used in the HMAC mode with OSPFv2 Cryptographic Authentication.
这描述了当任何NIST SHS算法在HMAC模式下使用OSPFv2加密认证时，认证数据值的计算。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:
在下面的算法描述中，使用了与[FIPS-198]一致的以下术语：
H is the specific hashing algorithm (e.g., SHA-256).
H是特定的散列算法（例如，SHA-256）。
K is the Authentication Key for the OSPFv2 security association.
K是OSPFv2安全关联的身份验证密钥。
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 well that B is the internal block size, not the hash size.
B是H的块大小，以八位字节而不是位来测量。请注意，B是内部块大小，而不是散列大小。
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
For SHA-1 and SHA-256: B == 64
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 the hexadecimal value 0x878FE1F3 repeated (L/4) times.
Apad是十六进制值0x878FE1F3，重复（1/4）次。
Implementation note: This definition of Apad means that Apad is always the same length as the hash output.
实现说明：此Apad定义意味着Apad始终与哈希输出长度相同。
(1) PREPARATION OF KEY In this application, Ko is always L octets long.
(1) 在本应用程序中，Ko的长度始终为L个八位字节。
If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K), such that Ko is L octets long.
如果身份验证密钥（K）的长度为L个八位字节，则Ko等于K。如果身份验证密钥（K）的长度超过L个八位字节，则Ko设置为H（K）。如果认证密钥（K）的长度小于L个八位字节，则将Ko设置为认证密钥（K），并在认证密钥（K）的末尾附加零，使得Ko的长度为L个八位字节。
(2) FIRST-HASH First, the OSPFv2 packet's Authentication Trailer (which is the appendage described in RFC 2328, Section D.4.3, Page 233, items (6)(a) and (6)(d)) is filled with the value Apad, and the Authentication Type field is set to 2.
(2) 首先，OSPFv2数据包的认证尾部（即RFC 2328第D.4.3节第233页第（6）（a）项和第（6）（D）项中描述的附件）填充值Apad，认证类型字段设置为2。
Then, a First-Hash, also known as the inner hash, is computed as follows:
然后，第一散列（也称为内部散列）计算如下：
First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet))
第一个Hash=H（Ko-XOR-Ipad | |（OSPFv2包））
Implementation Notes: Note that the First-Hash above includes the Authentication Trailer containing the Apad value, as well as the OSPF packet, as per RFC 2328, Section D.4.3.
实施说明：注意，根据RFC 2328，第D.4.3节，上面的第一个散列包括包含Apad值的身份验证尾部以及OSPF数据包。
The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. The "(OSPFv2 Packet)" mentioned in the First-Hash (above) does include the OSPF Authentication Trailer.
Apad（如上）的定义确保它始终与散列输出的长度相同。这与RFC 2328一致。第一个散列（上面）中提到的“（OSPFv2数据包）”不包括OSPF认证尾部。
The digest length for SHA-1 is 20 bytes; for SHA-256, 32 bytes; for SHA-384, 48 bytes; and for SHA-512, 64 bytes.
SHA-1的摘要长度为20字节；对于SHA-256，32字节；对于SHA-384，48字节；对于SHA-512，64字节。
(3) SECOND-HASH Then a Second-Hash, also known as the outer hash, is computed as follows:
(3) 第二个散列然后第二个散列，也称为外部散列，计算如下：
Second-Hash = H(Ko XOR Opad || First-Hash)
第二个散列=H（Ko-XOR-Opad | |第一个散列）
(4) RESULT The resulting Second-Hash becomes the Authentication Data that is sent in the Authentication Trailer of the OSPFv2 packet. The length of the Authentication Trailer is always identical to the message digest size of the specific hash function H that is being used.
(4) 结果产生的第二个散列成为在OSPFv2数据包的认证尾部中发送的认证数据。身份验证尾部的长度始终与正在使用的特定哈希函数H的消息摘要大小相同。
This also means that the use of hash functions with larger output sizes will also increase the size of the OSPFv2 packet as transmitted on the wire.
这也意味着使用具有更大输出大小的散列函数也将增加在线传输的OSPFv2数据包的大小。
Implementation Note: RFC 2328, 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.
实施说明：RFC 2328，附录D规定认证尾部不计入OSPF数据包自身的长度字段，而是包含在数据包的IP长度字段中。
Message verification follows the procedure defined in RFC 2328, except that the cryptographic calculation of the message digest follows the procedure in Section 3.3 above when any NIST SHS algorithm in the HMAC mode is in use. Kindly recall that the cryptographic algorithm/mode in use is indicated implicitly by the KeyID of the received OSPFv2 packet.
消息验证遵循RFC 2328中定义的程序，但当使用HMAC模式下的任何NIST SHS算法时，消息摘要的加密计算遵循上述第3.3节中的程序。请记住，使用的加密算法/模式由接收到的OSPFv2数据包的密钥ID隐式指示。
Implementation Notes: One must save the received digest value before calculating the expected digest value, so that after that calculation the received value can be compared with the expected value to determine whether to accept that OSPF packet.
实施说明：在计算预期摘要值之前，必须保存接收到的摘要值，以便在该计算之后，可以将接收到的值与预期值进行比较，以确定是否接受该OSPF数据包。
RFC 2328, Section D.4.3 (6) (c) should be read very closely prior to implementing the above. With SHA algorithms in HMAC mode, Apad is placed where the MD5 key would be put if Keyed-MD5 were in use.
在实施上述内容之前，应仔细阅读RFC 2328第D.4.3（6）（c）节。在HMAC模式下使用SHA算法时，Apad被放置在使用Keyed-MD5时MD5密钥的位置。
Using KeyIDs makes changing the active OSPFv2 SA convenient. An implementation can choose to associate a lifetime with each OSPFv2 SA and can thus automatically switch to a different OSPFv2 SA based on the lifetimes of the configured OSPFv2 SA(s).
使用KeyIDs可以方便地更改活动OSPFv2 SA。实现可以选择将生存期与每个OSPFv2 SA相关联，并且因此可以基于所配置的OSPFv2 SA的生存期自动切换到不同的OSPFv2 SA。
After changing the active OSPFv2 SA, the OSPF sender will use the (different) KeyID value associated with the newly active OSPFv2 SA. The receiver will use this new KeyID to select the appropriate (new) OSPFv2 SA to use with the received OSPF packet containing the new KeyID value.
更改活动OSPFv2 SA后，OSPF发送方将使用与新活动OSPFv2 SA相关联的（不同的）KeyID值。接收机将使用该新的KeyID来选择适当的（新的）OSPFv2 SA，以便与包含新的KeyID值的接收到的OSPF分组一起使用。
Because the KeyID field is present, the receiver does not need to try all configured OSPFv2 Security Associations with any received OSPFv2 packet. This can mitigate some of the risks of a Denial-of-Service (DoS) attack on the OSPF instance, but does not entirely prevent all conceivable DoS attacks. For example, an on-link adversary still could generate OSPFv2 packets that are syntactically valid but that contain invalid Authentication Data, thereby forcing the receiver(s) to perform expensive cryptographic computations to discover that the packets are invalid.
由于存在KeyID字段，接收器不需要尝试所有配置的OSPFv2安全关联与任何接收到的OSPFv2数据包。这可以减轻对OSPF实例的拒绝服务（DoS）攻击的一些风险，但不能完全防止所有可能的DoS攻击。例如，链路上的对手仍然可以生成语法上有效但包含无效认证数据的OSPFv2分组，从而迫使接收器执行昂贵的密码计算以发现分组无效。
This document enhances the security of the OSPFv2 routing protocol by adding, to the existing OSPFv2 Cryptographic Authentication method, support for the algorithms defined in the NIST Secure Hash Standard (SHS) using the Hashed Message Authentication Code (HMAC) mode, and by adding support for the Hashed Message Authentication Code (HMAC) mode.
本文件通过在现有OSPFv2加密认证方法中添加对NIST安全哈希标准（SHS）中使用哈希消息认证码（HMAC）模式定义的算法的支持，并通过添加对哈希消息认证码（HMAC）模式的支持，增强了OSPFv2路由协议的安全性。
This provides several alternatives to the existing Keyed-MD5 mechanism. There are published concerns about the overall strength of the MD5 algorithm ([Dobb96a], [Dobb96b], [Wang04]). While those published concerns apply to the use of MD5 in other modes (e.g., use of MD5 X.509v3/PKIX digital certificates), they are not an attack upon Keyed-MD5, which is what OSPFv2 specified in RFC 2328. There are also published concerns about the SHA algorithm [Wang05] and also concerns about the MD5 and SHA algorithms in the HMAC mode ([RR07], [RR08]). Separately, some organisations (e.g., the US government) prefer NIST algorithms, such as the SHA family, over other algorithms for local policy reasons.
这为现有的Keyed-MD5机制提供了几种替代方案。有人对MD5算法的整体强度表示担忧（[Dobb96a]、[Dobb96b]、[Wang04]）。虽然这些已发布的关注点适用于在其他模式下使用MD5（例如，使用MD5 X.509v3/PKIX数字证书），但它们不是对Keyed-MD5的攻击，这是RFC 2328中OSPFv2规定的攻击。也有关于SHA算法[Wang05]以及HMAC模式下的MD5和SHA算法的问题（[RR07]、[RR08]）。另外，出于当地政策原因，一些组织（如美国政府）更喜欢NIST算法，如SHA家族，而不是其他算法。
The value Apad is used here primarily for consistency with IETF specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822] and IS-IS SHA [RFC5310] and to minimise OSPF protocol processing changes in Section D.4.3 of RFC 2328 [RFC2328].
此处使用Apad值主要是为了与RIPv2 SHA[RFC4822]和is-is SHA[RFC5310]的HMAC-SHA认证的IETF规范保持一致，并尽量减少RFC 2328[RFC2328]第D.4.3节中OSPF协议处理的变化。
The quality of the security provided by the Cryptographic Authentication option depends completely on the strength of the cryptographic algorithm and cryptographic mode in use, the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. Accordingly, the use of high assurance development methods is recommended. It also requires that all parties maintain the secrecy of the shared secret key. [RFC4086] provides guidance on methods for generating cryptographically random bits.
加密身份验证选项提供的安全质量完全取决于使用的加密算法和加密模式的强度、使用的密钥的强度以及所有通信OSPF实现中安全机制的正确实现。因此，建议使用高保证开发方法。它还要求各方维护共享密钥的保密性。[RFC4086]提供生成加密随机位的方法指南。
This mechanism is vulnerable to a replay attack by any on-link node. An on-link node could record a legitimate OSPF packet sent on the link, then replay that packet at the next time the recorded OSPF packet's sequence number is valid. This replay attack could cause significant routing disruptions within the OSPF domain.
此机制容易受到链路上任何节点的重播攻击。链路上节点可以记录在链路上发送的合法OSPF数据包，然后在下一次记录的OSPF数据包的序列号有效时重播该数据包。此重播攻击可能会在OSPF域内造成重大路由中断。
Ideally, for example, to prevent the preceding attack, each OSPF Security Association would be replaced by a new and different OSPF Security Association before any sequence number were reused. As of the date this document was published, no form of automated key management has been standardised for OSPF. So, as of the date this document was published, common operational practice has been to use the same OSPF Authentication Key for very long periods of time. This operational practice is undesirable for many reasons. Therefore, it is clearly desirable to develop and standardise some automated key-management mechanism for OSPF.
理想情况下，例如，为了防止前面的攻击，在重用任何序列号之前，每个OSPF安全关联都将被一个新的和不同的OSPF安全关联替换。截至本文件发布之日，OSPF尚未标准化任何形式的自动密钥管理。因此，自本文档发布之日起，常见的操作实践是在很长一段时间内使用相同的OSPF身份验证密钥。由于许多原因，这种操作实践是不可取的。因此，显然需要为OSPF开发和标准化一些自动化的密钥管理机制。
Because all of the currently specified algorithms use symmetric cryptography, one cannot authenticate precisely which OSPF router sent a given packet. However, one can authenticate that the sender knew the OSPF Security Association (including the OSPFv2 SA's parameters) currently in use.
由于目前所有指定的算法都使用对称加密，因此无法准确地验证哪个OSPF路由器发送了给定的数据包。但是，可以验证发送方是否知道当前正在使用的OSPF安全关联（包括OSPFv2 SA的参数）。
Because a routing protocol contains information that need not be kept secret, privacy is not a requirement. However, authentication of the messages within the protocol is of interest in order to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into the routing system.
因为路由协议包含不需要保密的信息，所以不需要保密。然而，为了降低对手通过故意向路由系统中注入虚假信息而危害路由系统的风险，需要对协议内的消息进行认证。
The technology in this document enhances an authentication mechanism for OSPFv2. The mechanism described here is not perfect and need not be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking OSPFv2, as compared with plain-text authentication or null authentication, while not causing undue implementation, deployment, or operational complexity. Denial-of-Service attacks are not generally preventable in a useful networking protocol [VK83].
本文中的技术增强了OSPFv2的身份验证机制。这里描述的机制并不完美，也不需要完美。相反，与纯文本身份验证或空身份验证相比，此机制代表了攻击OSPFv2的对手的工作功能的显著增加，同时不会导致不当的实现、部署或操作复杂性。在有用的网络协议中，拒绝服务攻击通常是不可预防的[VK83]。
Because of implementation considerations, including the need for backwards compatibility, this specification uses the same mechanism as specified in RFC 2328 and limits itself to adding support for additional cryptographic hash functions. Also, some large network operators have indicated they prefer to retain the basic mechanism defined in RFC 2328, rather than migrate to IP Security, due to deployment and operational considerations. If all the OSPFv2 routers supported IPsec, then IPsec tunnels could be used in lieu of this mechanism [RFC4301]. This would, however, relegate the topology to point-to-point adjacencies over the mesh of IPsec tunnels.
由于实现方面的考虑，包括向后兼容性的需要，本规范使用RFC 2328中指定的相同机制，并将其自身限制为添加对附加加密哈希函数的支持。此外，一些大型网络运营商表示，出于部署和运营方面的考虑，他们更愿意保留RFC 2328中定义的基本机制，而不是迁移到IP安全。如果所有OSPFv2路由器都支持IPsec，则可以使用IPsec隧道来代替此机制[RFC4301]。然而，这将使拓扑降级为IPsec隧道网格上的点对点邻接。
If a stronger authentication were believed to be required, then the use of a full digital signature [RFC2154] would be an approach that should be seriously considered. Use of full digital signatures would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, and thereby provide much stronger integrity protection for the OSPF routing domain.
如果认为需要更强的认证，那么使用完整数字签名[RFC2154]将是一种值得认真考虑的方法。使用完整的数字签名将能够精确认证发起每个OSPF链路状态公告的OSPF路由器，从而为OSPF路由域提供更强的完整性保护。
The OSPF Authentication Codes registry entry for Cryptographic Authentication (Registry Code 2) has been updated to refer to this document as well as to RFC 2328.
加密身份验证的OSPF身份验证代码注册表项（注册表代码2）已更新，以参考本文档以及RFC 2328。
The authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of portions of this document that are directly derived from the closely related work on RIPv2 Cryptographic Authentication [RFC4822].
作者要感谢（美国）NIST的Bill Burr、Tim Polk、John Kelsey和Morris Dworkin对本文件中直接源自RIPv2加密身份验证密切相关工作的部分内容的审查[RFC4822]。
David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (in alphabetical order by last name) provided feedback on earlier versions of this document. That feedback has greatly improved both the technical content and the readability of the current document.
David Black、Nevil Brownlee、Acee Lindem和Hilarie Orman（按姓氏字母顺序）就本文档的早期版本提供了反馈。这种反馈大大改进了本文件的技术内容和可读性。
Henrik Levkowetz's Internet Draft tools were very helpful in preparing this document and are much appreciated.
Henrik Levkowetz的互联网草稿工具对编写本文件非常有帮助，非常感谢。
[FIPS-180-2] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
[FIPS-180-2]美国国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-22002，2002年8月。
[FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002.
[FIPS-198]美国国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，FIPS PUB 198，2002年3月。
[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月。
[Bell89] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[Bell89]Bellovin，S.，“TCP/IP协议套件中的安全问题”，ACM计算机通信评论，第19卷，第2期，第32-48页，1989年4月。
[Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at the Rump Session of EuroCrypt 1996.)
[Dobb96a]Dobbertin，H，“MD5压缩的密码分析”，技术报告，1996年5月2日。（1996年在EuroCrypt的Rump会议上提出。）
[Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, Summer 1996.
[Dobb96b]Dobbertin，H，“最近一次攻击后MD5的状态”，CryptoBytes，第2卷，第2期，1996年夏季。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704]Haller，N.和R.Atkinson，“互联网认证”，RFC17041994年10月。
[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月。
[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月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4634]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（SHA和HMAC-SHA）”，RFC 46342006年7月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[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月。
[RR07] Rechberger, C. and V. Rijmen, "On Authentication with HMAC and Non-random Properties", Financial Cryptography and Data Security, Lecture Notes in Computer Science, Volume 4886/2008, Springer-Verlag, Berlin, December 2007.
[RR07]Rechberger，C.和V.Rijmen，“关于HMAC和非随机属性的身份验证”，金融密码学和数据安全，计算机科学课堂讲稿，第4886/2008卷，Springer Verlag，柏林，2007年12月。
[RR08] Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC when Instantiated with Popular Hash Functions", Journal of Universal Computer Science, Volume 14, Number 3, pp. 347-376, 1 February 2008.
[RR08]Rechberger，C.和V.Rijmen，“使用流行哈希函数实例化NMAC/HMAC时的新结果”，《通用计算机科学杂志》，第14卷，第3期，第347-376页，2008年2月1日。
[VK83] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[VK83]Voydock，V.和S.Kent，“高级网络中的安全机制”，ACM计算调查，第15卷，第2期，1983年6月。
[Wang04] Wang, X., et alia, "Collisions for Hash Functions MD4,
MD5, HAVAL-128, and RIPEMD", August 2004, IACR,
http://eprint.iacr.org/2004/199
[Wang04] Wang, X., et alia, "Collisions for Hash Functions MD4,
MD5, HAVAL-128, and RIPEMD", August 2004, IACR,
http://eprint.iacr.org/2004/199
[Wang05] Wang, X., et alia, "Finding Collisions in the Full SHA-1" Proceedings of Crypto 2005, Lecture Notes in Computer Science, Volume 3621, pp. 17-36, Springer-Verlag, Berlin, August 31, 2005.
[Wang05]Wang，X.，et alia，“在完整的SHA-1中发现碰撞”，2005年加密学报，计算机科学课堂讲稿，第3621卷，第17-36页，柏林斯普林格·维拉格，2005年8月31日。
Authors' Addresses
作者地址
Manav Bhatia Alcatel-Lucent Bangalore, India
印度班加罗尔朗讯公司
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral IP Infusion Almora, Uttarakhand India
印度北部阿尔莫拉的维什瓦斯·曼拉尔
EMail: vishwas@ipinfusion.com
EMail: vishwas@ipinfusion.com
Matthew J. Fanto Aegis Data Security Dearborn, MI USA
Matthew J.Fanto Aegis数据安全美国密苏里州迪尔伯恩
EMail: mfanto@aegisdatasecurity.com
EMail: mfanto@aegisdatasecurity.com
Russ I. White Cisco Systems 7025 Kit Creek Road P.O. Box 14987 RTP, NC 27709 USA
Russ I.White Cisco Systems 7025 Kit Creek Road邮政信箱14987 RTP，美国北卡罗来纳州27709
EMail: riw@cisco.com
EMail: riw@cisco.com
M. Barnes Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道225号，邮编95134
EMail: mjbarnes@cisco.com
EMail: mjbarnes@cisco.com
Tony Li Ericsson 300 Holger Way San Jose, CA 95134 USA
托尼·李·爱立信美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: tony.li@tony.li
EMail: tony.li@tony.li
Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
Randall J.Atkinson极限网络美国加利福尼亚州圣克拉拉门罗街3585号，邮编95051
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com