Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 6094 Alcatel-Lucent
Category: Informational V. Manral
ISSN: 2070-1721 IP Infusion
February 2011
Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 6094 Alcatel-Lucent
Category: Informational V. Manral
ISSN: 2070-1721 IP Infusion
February 2011
Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
路由协议的加密认证算法实现要求摘要
Abstract
摘要
The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.
路由协议开放最短路径第一版本2（OSPFv2）、中间系统到中间系统（IS-IS）和路由信息协议（RIP）目前定义了用于验证协议包的明文和MD5（消息摘要5）方法。最近，为了对RIP、IS-IS和OSPF的路由协议数据包进行身份验证，已经努力添加对SHA（安全哈希算法）哈希函数家族的支持。
To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.
为了鼓励不同实现之间的互操作性，我们必须指定预期的最小算法集，从而确保至少有一种算法是所有实现的共同算法。
Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.
类似地，IPv6的RIP（RIPng）和OSPFv3支持IPsec算法来验证它们的协议包。
This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time.
本文档检查了当前可用的算法集，互操作性和有效的加密身份验证保护是主要考虑因素。这些路由协议的加密认证要求在不同的实现中使用相同的算法。新指定的算法应该在路由协议实现中实现并可用，这是可取的，因为它们可能在将来某个时候被提升到需求中。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6094.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6094.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
2. Intermediate System to Intermediate System (IS-IS) ..............4
2.1. Authentication Scheme Selection ............................4
2.2. Authentication Algorithm Selection .........................5
3. Open Shortest Path First Version 2 (OSPFv2) .....................5
3.1. Authentication Scheme Selection ............................6
3.2. Authentication Algorithm Selection .........................6
4. Open Shortest Path First Version 3 (OSPFv3) .....................7
5. Routing Information Protocol Version 2 (RIPv2) ..................7
5.1. Authentication Scheme Selection ............................7
5.2. Authentication Algorithm Selection .........................8
6. Routing Information Protocol for IPv6 (RIPng) ...................8
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
1. Introduction ....................................................3
2. Intermediate System to Intermediate System (IS-IS) ..............4
2.1. Authentication Scheme Selection ............................4
2.2. Authentication Algorithm Selection .........................5
3. Open Shortest Path First Version 2 (OSPFv2) .....................5
3.1. Authentication Scheme Selection ............................6
3.2. Authentication Algorithm Selection .........................6
4. Open Shortest Path First Version 3 (OSPFv3) .....................7
5. Routing Information Protocol Version 2 (RIPv2) ..................7
5.1. Authentication Scheme Selection ............................7
5.2. Authentication Algorithm Selection .........................8
6. Routing Information Protocol for IPv6 (RIPng) ...................8
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Most routing protocols include three different types of authentication schemes: Null authentication, cleartext password, and cryptographic authentication. Null authentication is equivalent to having no authentication scheme at all.
大多数路由协议包括三种不同类型的身份验证方案：空身份验证、明文密码和加密身份验证。空身份验证等同于根本没有身份验证方案。
In a cleartext scheme, also known as a "simple password" scheme, the password is exchanged completely unprotected, and anyone with physical access to the network can learn the password and compromise the integrity of the routing domain. The simple password scheme protects against accidental establishment of routing sessions in a given domain, but beyond that it offers no additional protection.
在明文方案（也称为“简单密码”方案）中，密码交换完全不受保护，任何物理访问网络的人都可以学习密码并破坏路由域的完整性。简单密码方案可防止在给定域中意外建立路由会话，但除此之外，它不提供额外的保护。
In a cryptographic authentication scheme, routers share a secret key that is used to generate a message authentication code for each of the protocol packets. Today, routing protocols that implement message authentication codes often use a Keyed-MD5 [RFC1321] digest. The recent escalating series of attacks on MD5 raise concerns about its remaining useful lifetime.
在加密认证方案中，路由器共享一个密钥，该密钥用于为每个协议包生成消息认证码。今天，实现消息身份验证代码的路由协议通常使用Keyed-MD5[RFC1321]摘要。最近针对MD5的一系列不断升级的攻击引起了人们对其剩余使用寿命的担忧。
These attacks may not necessarily result in direct vulnerabilities for Keyed-MD5 digests as message authentication codes because the colliding message may not correspond to a syntactically correct protocol packet. The known collision, pre-image, and second pre-image attacks [RFC4270] on MD5 may not increase the effectiveness of the key recovery attacks on HMAC-MD5. Regardless, there is a need felt to deprecate MD5 [RFC1321] as the basis for the Hashed Message Authentication Code (HMAC) algorithm in favor of stronger digest algorithms.
这些攻击不一定会导致Keyed-MD5摘要作为消息身份验证码的直接漏洞，因为冲突消息可能不对应于语法正确的协议包。MD5上已知的冲突、预映像和第二预映像攻击[RFC4270]可能不会提高HMAC-MD5上密钥恢复攻击的有效性。无论如何，有必要反对将MD5[RFC1321]作为哈希消息身份验证码（HMAC）算法的基础，以支持更强的摘要算法。
In light of these considerations, there are proposals to replace HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is currently mandated in RIPv2 [RFC2453] IS-IS [ISO] [RFC1195], and Keyed-MD5 in OSPFv2 [RFC2328].
鉴于这些考虑因素，有人提议将HMAC-MD5替换为键控HMAC-SHA[SHS]摘要，其中HMAC-MD5目前在RIPv2[RFC2453]is-is[ISO][RFC1195]中强制执行，而键控MD5在OSPFv2[RFC2328]中强制执行。
OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
OSPFv3[RFC5340]和RIPng[RFC2080]依赖IPv6身份验证头（AH）[RFC4302]和IPv6封装安全负载（ESP）[RFC4303]来提供完整性、身份验证和/或机密性。
However, the nature of cryptography is that algorithmic improvement is an ongoing process, as is the exploration and refinement of attack vectors. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of preferred algorithm should favor the minimization of the likelihood of it being compromised quickly.
然而，密码学的本质是算法改进是一个持续的过程，攻击向量的探索和细化也是如此。今天被认为很强大的算法明天可能会被证明很弱。有鉴于此，首选算法的选择应该有利于将其快速受损的可能性降至最低。
It should be recognized that preferred algorithm(s) will change over time to adapt to the evolving threats. At any particular time, the mandatory-to-implement algorithm(s) might not be specified in the base protocol specification. As protocols are extended, the preference for presently stronger algorithms presents a problem regarding the question of interoperability of existing and future implementations with respect to standards, and also regarding operational preference for the configuration as deployed.
应该认识到，首选算法将随着时间的推移而变化，以适应不断演变的威胁。在任何特定时间，基本协议规范中都可能未指定实现算法的强制要求。随着协议的扩展，对当前更强算法的偏好提出了一个问题，即现有和未来实现在标准方面的互操作性问题，以及部署配置的操作偏好问题。
It is expected that an implementation should support the changing of security (authentication) keys. Changing the symmetric key used in any HMAC algorithm on a periodic basis is good security practice. Operators need to plan for this.
预期实现应支持更改安全（身份验证）密钥。定期更改任何HMAC算法中使用的对称密钥是良好的安全实践。运营商需要为此制定计划。
Implementations can support in-service key change so that no control packets are lost. During an in-service/in-band key change, more than one key can be active for receiving packets for a session. Some protocols support a key identifier that allows the two peers of a session to have multiple keys simultaneously for a session.
实现可以支持服务内密钥更改，从而不会丢失控制数据包。在服务中/带内密钥更改期间，可以有多个密钥处于活动状态以接收会话的数据包。一些协议支持密钥标识符，该标识符允许会话的两个对等方同时拥有会话的多个密钥。
However, these protocols currently manage keys manually (i.e., via operator intervention) or dynamically based on some timer or security protocol.
然而，这些协议目前手动（即通过操作员干预）或基于某些计时器或安全协议动态地管理密钥。
The IS-IS specification allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The base specification [ISO] had provisions only for cleartext passwords. [RFC5304] extends the authentication capabilities by providing cryptographic authentication for IS-IS PDUs. It mandates support for HMAC-MD5.
IS-IS规范允许通过PDU中的认证TLV（TLV 10）对其协议数据单元（PDU）进行认证。基本规范[ISO]只规定了明文密码。[RFC5304]通过为IS-IS PDU提供加密身份验证，扩展了身份验证功能。它要求支持HMAC-MD5。
[RFC5310] adds support for the use of any cryptographic hash function for authenticating IS-IS PDUs. In addition to this, [RFC5310] also details how IS-IS can use the HMAC construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions to secure IS-IS PDUs.
[RFC5310]增加了对使用任何加密哈希函数对IS-IS PDU进行身份验证的支持。除此之外，[RFC5310]还详细说明了IS-IS如何使用HMAC构造以及安全哈希算法（SHA）系列加密哈希函数来保护IS-IS PDU。
In order for IS-IS implementations to securely interoperate, they must support one or more authentication schemes in common. This section specifies the preference for standards-conformant IS-IS implementations that use accepted authentication schemes.
为了使IS-IS实现能够安全地互操作，它们必须共同支持一个或多个身份验证方案。本节指定了使用公认身份验证方案的符合标准的IS-IS实现的首选项。
The earliest interoperability requirement for authentication as stated by [ISO] [RFC1195] required all implementations to support a
[ISO][RFC1195]所述的最早的认证互操作性要求要求所有实现都支持
cleartext password. This authentication scheme's utility is limited to precluding the accidental introduction of a new IS into a broadcast domain. Operators should not use this scheme, as it provides no protection against an attacker with access to the broadcast domain: anyone can determine the secret password through inspection of the PDU. This mechanism does not provide any significant level of security and should be avoided.
明文密码。该认证方案的实用性仅限于防止将新is意外引入广播域。运营商不应使用此方案，因为它无法防止攻击者访问广播域：任何人都可以通过检查PDU来确定密码。此机制不提供任何显著的安全级别，应避免使用。
[RFC5304] defined the cryptographic authentication scheme for IS-IS. HMAC-MD5 was the only algorithm specified; hence, it is mandated. [RFC5310] defined a generic cryptographic scheme and added support for additional algorithms. Implementations should support [RFC5310], as it defines the generic cryptographic authentication scheme.
[RFC5304]定义了IS-IS的加密身份验证方案。HMAC-MD5是唯一指定的算法；因此，它是强制性的。[RFC5310]定义了通用加密方案，并增加了对其他算法的支持。实现应该支持[RFC5310]，因为它定义了通用加密身份验证方案。
For IS-IS implementations to securely interoperate, they must have support for one or more authentication algorithms in common.
为了实现安全的互操作，IS-IS实现必须支持一个或多个通用的身份验证算法。
This section details the authentication algorithm requirements for standards-conformant IS-IS implementations.
本节详细介绍符合标准的IS-IS实现的认证算法要求。
The following are the available options for authentication algorithms:
以下是身份验证算法的可用选项：
o [RFC5304] mandates the use of HMAC-MD5.
o [RFC5304]强制使用HMAC-MD5。
o [RFC5310] does not require a particular algorithm but instead supports any digest algorithm (i.e., cryptographic hash functions).
o [RFC5310]不需要特定算法，而是支持任何摘要算法（即加密哈希函数）。
As noted earlier, there is a desire to deprecate MD5. IS-IS implementations will likely migrate to an authentication scheme supported by [RFC5310], because it is algorithm agnostic. Possible digest algorithms include SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Picking at least one mandatory-to-implement algorithm is imperative to ensuring interoperability.
如前所述，人们希望反对MD5。IS-IS实现可能会迁移到[RFC5310]支持的身份验证方案，因为它与算法无关。可能的摘要算法包括SHA-1、SHA-224、SHA-256、SHA-384和SHA-512。为确保互操作性，必须至少选择一个强制算法来实现。
[RFC2328] includes three different types of authentication schemes: Null authentication, cleartext password (defined as "simple password" in [RFC2328]), and cryptographic authentication. Null authentication is semantically equivalent to no authentication.
[RFC2328]包括三种不同类型的身份验证方案：空身份验证、明文密码（在[RFC2328]中定义为“简单密码”）和密码身份验证。空身份验证在语义上等同于无身份验证。
In the cryptographic authentication scheme, the OSPFv2 routers on a common network/subnet are configured with a shared secret that is used to generate a Keyed-MD5 digest for each packet. A monotonically
在加密认证方案中，公共网络/子网上的OSPFv2路由器配置有一个共享密钥，用于为每个数据包生成密钥MD5摘要。单调的
increasing sequence number scheme is used to protect against replay attacks.
增加序列号方案用于防止重播攻击。
[RFC5709] adds support for the use of the SHA family of hash algorithms for authentication of OSPFv2 packets.
[RFC5709]增加了对使用SHA系列哈希算法对OSPFv2数据包进行身份验证的支持。
For OSPF implementations to securely interoperate, they must have one or more authentication schemes in common.
为了使OSPF实现能够安全地互操作，它们必须有一个或多个共同的身份验证方案。
While all implementations will have Null authentication since it's mandated by [RFC2328], its use is not appropriate in any context where the operator wishes to authenticate OSPFv2 packets in their network.
虽然由于[RFC2328]强制要求，所有实现都将具有空身份验证，但在运营商希望对其网络中的OSPFv2数据包进行身份验证的任何上下文中，都不适合使用空身份验证。
While all implementations will also support a cleartext password since it's mandated by [RFC2328], its use is only appropriate when the operator wants to preclude the accidental introduction of a router into the domain. This scheme is patently not useful when an operator wants to authenticate the OSPFv2 packets.
由于[RFC2328]强制使用明文密码，因此所有实现也将支持明文密码，但只有当运营商希望防止意外将路由器引入域时，才适合使用明文密码。当运营商想要验证OSPFv2数据包时，此方案显然没有用处。
Cryptographic authentication is a mandatory scheme defined in [RFC2328], and all conformant implementations must support this.
加密身份验证是[RFC2328]中定义的强制性方案，所有一致性实现都必须支持这一点。
For OSPFv2 implementations to securely interoperate, they must support one or more cryptographic authentication algorithms in common.
为了使OSPFv2实现能够安全地互操作，它们必须共同支持一个或多个加密身份验证算法。
The following are the available options for authentication algorithms:
以下是身份验证算法的可用选项：
o [RFC2328] specifies the use of Keyed-MD5.
o [RFC2328]指定Keyed-MD5的使用。
o [RFC5709] specifies the use of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512, and also mandates support for HMAC-SHA-256 (HMAC-SHA-1 is optional).
o [RFC5709]指定HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的使用，并强制支持HMAC-SHA-256（HMAC-SHA-1是可选的）。
As noted earlier, there is a desire to deprecate MD5. Some alternatives for MD5 are listed in [RFC5709].
如前所述，人们希望反对MD5。[RFC5709]中列出了MD5的一些备选方案。
Possible digest algorithms include SHA-1, SHA-256, SHA-384, and SHA-512. Picking one mandatory-to-implement algorithm is imperative to ensuring interoperability.
可能的摘要算法包括SHA-1、SHA-256、SHA-384和SHA-512。为确保互操作性，必须选择一个强制算法来实现。
OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
OSPFv3[RFC5340]依靠IPv6身份验证头（AH）[RFC4302]和IPv6封装安全有效负载（ESP）[RFC4303]来提供完整性、身份验证和/或机密性。
[RFC4552] mandates the use of ESP for authenticating OSPFv3 packets. The implementations could also provide support for using AH to protect these packets.
[RFC4552]强制使用ESP对OSPFv3数据包进行身份验证。这些实现还可以支持使用AH来保护这些数据包。
The algorithm requirements for AH and ESP are described in [RFC4835] as follows:
AH和ESP的算法要求在[RFC4835]中描述如下：
o [RFC2404] mandates HMAC-SHA-1-96.
o [RFC2404]授权HMAC-SHA-1-96。
o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely that this will be mandated at some future time.
o [RFC3566]将AES-XCBC-MAC-96表示为“应该”，但很可能在未来某个时间强制执行。
RIPv2, originally specified in [RFC1388] and then in [RFC1723], has been updated and published as STD 56, [RFC2453]. If the Address Family Identifier of the first (and only the first) entry in the RIPv2 message is 0xFFFF, then the remainder of the entry contains the authentication information. The [RFC2453] version of the protocol provides for authenticating packets using a cleartext password (defined as "simple password" in [RFC2453]) not more than 16 octets in length.
最初在[RFC1388]和[RFC1723]中指定的RIPv2已更新并发布为STD 56[RFC2453]。如果RIPv2消息中第一个（且仅第一个）条目的地址族标识符为0xFFFF，则该条目的其余部分包含身份验证信息。协议的[RFC2453]版本规定使用明文密码（在[RFC2453]中定义为“简单密码”）验证数据包，长度不超过16个八位字节。
[RFC2082] added support for Keyed-MD5 authentication, where a digest is appended to the end of the RIP packet. [RFC4822] obsoleted [RFC2082] and added the SHA family of hash algorithms to the list of cryptographic authentications that can be used to protect RIPv2, whereas [RFC2082] previously specified only the use of Keyed-MD5.
[RFC2082]增加了对Keyed-MD5身份验证的支持，其中RIP数据包的末尾追加了摘要。[RFC4822]淘汰了[RFC2082]，并将SHA系列哈希算法添加到可用于保护RIPv2的加密身份验证列表中，而[RFC2082]先前仅指定使用Keyed-MD5。
For RIPv2 implementations to securely interoperate, they must support one or more authentication schemes in common.
为了使RIPv2实现能够安全地互操作，它们必须共同支持一个或多个身份验证方案。
While all implementations will support a cleartext password since it's mandated by [RFC2453], its use is only appropriate when the operator wants to preclude the accidental introduction of a router into the domain. This scheme is patently not useful when an operator wants to authenticate the RIPv2 packets.
由于[RFC2453]强制使用明文密码，因此所有实现都将支持明文密码，但只有当运营商希望防止意外将路由器引入域时，才适合使用明文密码。当操作员想要验证RIPv2数据包时，此方案显然没有用处。
[RFC2082] mandates the use of an authentication scheme that uses Keyed-MD5. However, [RFC2082] has been obsoleted by [RFC4822]. Compliant implementations must provide support for an authentication scheme that uses Keyed-MD5 but should recognize that this is superseded by cryptographic authentication as defined in [RFC4822].
[RFC2082]强制使用使用Keyed-MD5的身份验证方案。但是，[RFC2082]已被[RFC4822]淘汰。兼容实现必须支持使用Keyed-MD5的身份验证方案，但应认识到该方案已被[RFC4822]中定义的加密身份验证所取代。
Implementations should provide support for [RFC4822], as it specifies the RIPv2 cryptographic authentication schemes.
实现应该提供对[RFC4822]的支持，因为它指定了RIPv2加密身份验证方案。
For RIPv2 implementations to securely interoperate, they must support one or more authentication algorithms in common.
为了使RIPv2实现能够安全地互操作，它们必须共同支持一个或多个身份验证算法。
The following are the available options for authentication algorithms:
以下是身份验证算法的可用选项：
o [RFC2082] specifies the use of Keyed-MD5.
o [RFC2082]指定Keyed-MD5的使用。
o [RFC4822] specifies the use of Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
o [RFC4822]指定Keyed-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的使用。
As noted earlier, there is a desire to deprecate MD5. Some alternatives for MD5 are listed in [RFC4822]. Possible digest algorithms include SHA-1, SHA-256, SHA-384, and SHA-512. Picking one mandatory-to-implement algorithm is imperative to ensuring interoperability.
如前所述，人们希望反对MD5。[RFC4822]中列出了MD5的一些备选方案。可能的摘要算法包括SHA-1、SHA-256、SHA-384和SHA-512。为确保互操作性，必须选择一个强制算法来实现。
RIPng [RFC2080] relies on the IPv6 Authentication Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in order to provide integrity, authentication, and/or confidentiality.
RIPng[RFC2080]依靠IPv6身份验证头（AH）[RFC4302]和IPv6封装安全有效负载（ESP）[RFC4303]来提供完整性、身份验证和/或机密性。
The algorithm requirements for AH and ESP are described in [RFC4835] as follows:
AH和ESP的算法要求在[RFC4835]中描述如下：
o [RFC2404] mandates HMAC-SHA-1-96.
o [RFC2404]授权HMAC-SHA-1-96。
o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely that this will be mandated at some future time.
o [RFC3566]将AES-XCBC-MAC-96表示为“应该”，但很可能在未来某个时间强制执行。
The cryptographic mechanisms referenced in this document provide only authentication algorithms. These algorithms do not provide confidentiality. Encrypting the content of the packet and thereby providing confidentiality is not considered in the definition of the routing protocols.
本文档中引用的加密机制仅提供身份验证算法。这些算法不提供机密性。在路由协议的定义中不考虑对分组的内容进行加密从而提供机密性。
The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function and on the size and quality of the key. The feasibility of attacking the integrity of routing protocol messages protected by keyed digests may be significantly more limited than that of other data; however, preference for one family of algorithms over another may also change independently of the perceived risk to a particular protocol.
HMAC的加密强度取决于基础哈希函数的加密强度以及密钥的大小和质量。攻击受密钥摘要保护的路由协议消息的完整性的可行性可能比其他数据的完整性受到明显限制；然而，对一系列算法的偏好也可能独立于对特定协议的感知风险而改变。
To ensure greater security, the keys used should be changed periodically, and implementations must be able to store and use more than one key at the same time. Operational experience suggests that the lack of periodic rekeying is a source of significant exposure and that the lifespan of shared keys in the network is frequently measured in years.
为了确保更高的安全性，应该定期更改使用的密钥，并且实现必须能够同时存储和使用多个密钥。运营经验表明，缺乏定期密钥更新是严重暴露的一个原因，网络中共享密钥的使用寿命通常以年为单位。
While simple password schemes are well represented in the document series and in conformant implementations of the protocols, the inability to offer either integrity or identity protection are sufficient reason to strongly discourage their use.
虽然简单的密码方案在文档系列和协议的一致性实现中得到了很好的体现，但无法提供完整性或身份保护是强烈反对使用它们的充分理由。
This document concerns itself with the selection of cryptographic algorithms for use in the authentication of routing protocol packets being exchanged between adjacent routing processes. The cryptographic algorithms identified in this document are not known to be broken at the current time, and ongoing cryptographic research so far leads us to believe that they will likely remain secure in the foreseeable future. We expect that new revisions of this document will be issued in the future to reflect current thinking on the algorithms that various routing protocols should employ to ensure interoperability between disparate implementations.
本文档涉及选择加密算法，用于验证在相邻路由进程之间交换的路由协议数据包。本文件中确定的加密算法目前尚未被破坏，目前正在进行的加密研究使我们相信，它们在可预见的未来可能仍然安全。我们预计，本文件的新修订版将在未来发布，以反映各种路由协议应采用的算法的当前想法，以确保不同实现之间的互操作性。
We would like to thank Joel Jaeggli, Sean Turner, and Adrian Farrel for their comments and feedback on this document, which resulted in significant improvement of the same.
我们要感谢Joel Jaeggli、Sean Turner和Adrian Farrel对本文件的评论和反馈，这些评论和反馈导致了本文件的重大改进。
[ISO] "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service", ISO/IEC 10589:1992 (ISO 8473).
[ISO]“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统路由信息交换协议”，ISO/IEC 10589:1992（ISO 8473）。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[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月。
[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月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1388, January 1993.
[RFC1388]Malkin，G.，“RIP版本2包含附加信息”，RFC 1388，1993年1月。
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[RFC1723]Malkin，G.，“RIP版本2-携带附加信息”，RFC 17231994年11月。
[RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[RFC2082]Baker，F.和R.Atkinson，“RIP-2 MD5认证”，RFC 2082，1997年1月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[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月。
[SHS] "Secure Hash Standard (SHS)", National Institute of Standards and Technology (NIST) FIPS Publication 180-3, October 2008.
[SHS]“安全哈希标准（SHS）”，国家标准与技术研究所（NIST）FIPS出版物180-3，2008年10月。
Authors' Addresses
作者地址
Manav Bhatia Alcatel-Lucent Bangalore India
印度班加罗尔朗讯公司
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral IP Infusion 1188 E. Arques Ave. Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔阿克斯大道东1188号维斯瓦斯曼拉尔IP输液厂，邮编94089
Phone: 408-400-1900 EMail: vishwas@ipinfusion.com
电话：408-400-1900电子邮件：vishwas@ipinfusion.com