Network Working Group R. Atkinson
Request for Comments: 4822 Extreme Networks
Obsoletes: 2082 M. Fanto
Updates: 2453 NIST
Category: Standards Track February 2007
Network Working Group R. Atkinson
Request for Comments: 4822 Extreme Networks
Obsoletes: 2082 M. Fanto
Updates: 2453 NIST
Category: Standards Track February 2007
RIPv2 Cryptographic Authentication
RIPv2加密身份验证
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
IESG Note
IESG注释
In the interests of encouraging rapid migration away from Keyed-MD5 and its known weakness, the IESG has approved this document even though it does not meet the guidelines in BCP 107 (RFC 4107). However, the IESG stresses that automated key management should be used to establish session keys and urges that the future work on key management described in Section 5.6 of this document should be performed as soon as possible.
为了鼓励快速迁移远离Keyed-MD5及其已知弱点，IESG批准了本文件，尽管它不符合BCP 107（RFC 4107）中的指南。然而，IESG强调应使用自动密钥管理来建立会话密钥，并敦促尽快执行本文件第5.6节中描述的未来密钥管理工作。
Abstract
摘要
This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section.
本说明描述了对最初在RFC 2082中指定的RIPv2加密身份验证机制的修订。本文件淘汰了RFC 2082，并更新了RFC 2453。本文档添加了SHA系列哈希算法如何与RIPv2加密身份验证一起使用的详细信息，而原始文档仅指定了Keyed-MD5的使用。此外，本文档澄清了对该机制进行主动攻击的潜在问题，并在“安全注意事项”部分添加了重要文本。
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIPv2 provides for unauthenticated service (as in classical RIP), or password authentication. Both are vulnerable to passive attacks currently widespread in the Internet. Well-understood security issues exist in routing protocols [Bell89]. Cleartext passwords, originally specified for use with RIPv2, are widely understood to be vulnerable to easily deployed passive attacks [HA94].
互联网的发展使我们意识到需要改进路由信息的身份验证。RIPv2提供未经验证的服务（如经典RIP）或密码验证。两者都容易受到目前互联网上广泛存在的被动攻击。路由协议中存在众所周知的安全问题[Bell89]。明文密码最初指定用于RIPv2，人们普遍认为它容易受到容易部署的被动攻击[HA94]。
The original RIPv2 cryptographic authentication specification, RFC 2082 [AB97], used the Keyed-MD5 cryptographic mechanism. While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. Further, some end users, particularly several different governments, require the use of the SHA hash function family rather than any other such function for policy reasons. Finally, the original specification uses a hashing construction widely believed to be weaker than the HMAC construction used with the algorithms added in this revision of the specification.
最初的RIPv2加密身份验证规范RFC2082[AB97]使用了Keyed-MD5加密机制。虽然没有公开发布对该机制的攻击，但一些报告[Dobb96a，Dobb96b]对MD5加密哈希函数的极限强度产生了担忧。此外，出于政策原因，一些最终用户，特别是几个不同的政府，要求使用SHA哈希函数系列，而不是任何其他此类函数。最后，原始规范使用了一种散列结构，人们普遍认为它比HMAC结构弱，HMAC结构与本规范修订版中添加的算法一起使用。
This document obsoletes the original specification, RFC 2082 [AB97]. This specification differs from RFC 2082 by adding support for the SHA family of hash algorithms and the HMAC technique, while retaining the original Keyed-MD5 algorithm and mode. As the original RIPv2 Cryptographic Authentication mechanism was algorithm-independent, backwards compatibility is retained. This requirement for backwards compatibility precludes making significant protocol changes. So, this document limits changes to the addition of support for an additional family of cryptographic algorithms. The original specification has been very widely implemented, is known to be widely interoperable, and is also widely deployed.
本文件废除了原始规范RFC 2082[AB97]。本规范与RFC2082的不同之处在于增加了对SHA系列哈希算法和HMAC技术的支持，同时保留了原始的Keyed-MD5算法和模式。由于原始RIPv2加密身份验证机制与算法无关，因此保留了向后兼容性。这种向后兼容性要求排除了对协议进行重大更改。因此，本文档将更改限制为添加对其他加密算法系列的支持。最初的规范已经得到了广泛的实现，众所周知，它具有广泛的互操作性，并且也得到了广泛的部署。
The authors do NOT believe that this specification is the final answer to RIPv2 authentication and encourage the reader to consult the Security Considerations section of this document for more details.
作者不认为本规范是RIPv2认证的最终答案，并鼓励读者参考本文档的安全注意事项部分了解更多详细信息。
If RIPv2 authentication is disabled, then only simple misconfigurations are detected. The original RIPv2 authentication mechanism relied upon reused cleartext passwords. Use of cleartext password authentication can protect against accidental misconfigurations if that were the only concern, but is not helpful from a security perspective. By simply capturing information on the wire -- straightforward even in a remote environment -- a hostile
如果禁用RIPv2身份验证，则只检测到简单的错误配置。最初的RIPv2身份验证机制依赖于重用的明文密码。使用明文密码身份验证可以防止意外的错误配置（如果这是唯一的问题），但从安全角度看没有帮助。通过简单地在电线上捕获信息——即使在远程环境中也很简单——一种敌对的方式
entity can read the cleartext RIPv2 password and use that knowledge to inject false information into the routing system via the RIPv2 routing protocol.
实体可以读取明文RIPv2密码，并使用该知识通过RIPv2路由协议将虚假信息注入路由系统。
This mechanism is intended to reduce the risk of a successful passive attack upon RIPv2 deployments. That is, deployment of this mechanism greatly reduces the vulnerability of the RIPv2-based routing system from a passive attack. When cryptographic authentication is enabled, we transmit the output of a keyed cryptographic one-way function in the authentication field of the RIPv2 packet, instead of sending a cleartext reusable password in the RIPv2 packet. The RIPv2 Authentication Key is known only to the authorized parties of the RIPv2 session. The RIPv2 Authentication Key is never sent over the network in the clear.
该机制旨在降低RIPv2部署成功被动攻击的风险。也就是说，这种机制的部署大大降低了基于RIPv2的路由系统遭受被动攻击的脆弱性。当启用加密身份验证时，我们在RIPv2数据包的身份验证字段中传输密钥加密单向函数的输出，而不是在RIPv2数据包中发送明文可重用密码。只有RIPv2的认证方知道RIPv2的认证密钥。RIPv2身份验证密钥永远不会以明文形式通过网络发送。
In this way, protection is afforded against forgery or message modification. While it is possible to replay a message until the sequence number changes, a sequence number can be used to reduce replay risks. The mechanism does not provide confidentiality, since messages stay in the clear. Since the objective of a routing protocol is to advertise the routing topology, confidentiality is not normally required for routing protocols.
这样，就提供了防止伪造或修改消息的保护。虽然可以重播消息直到序列号更改，但序列号可用于降低重播风险。该机制不提供机密性，因为消息保持透明。由于路由协议的目标是公布路由拓扑，因此路由协议通常不需要保密性。
Other relevant rationales for the approach are that MD5 and SHA-1 are both being used for other purposes and are therefore generally already present in IP routers, as is some form of password management.
该方法的其他相关原理是，MD5和SHA-1都用于其他目的，因此通常已经存在于IP路由器中，就像某种形式的密码管理一样。
In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [BCP14] and indicate requirement levels for compliant or conformant implementations.
在本文件中，“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”等词语应按照[BCP14]中所述进行解释，并表示合规或合规实施的要求级别。
Implementation requires use of a special packet format, special authentication procedures, and also management controls. Implementers need to remember that the Security Considerations section is an integral part of this specification and contains important parts of this specification.
实现需要使用特殊的数据包格式、特殊的身份验证过程以及管理控制。实现者需要记住，安全注意事项部分是本规范不可分割的一部分，并且包含本规范的重要部分。
The basic RIPv2 message format provides for an 8-octet header with an array of 20-octet records as its data content. When RIPv2 Cryptographic Authentication is enabled, the same header and content are used as with the original RIPv2 specification, but the 16-octet "Authentication" password field of the original RIPv2 specification is reused to contain a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number.
基本RIPv2消息格式提供了一个8个八位字节的报头，其中包含20个八位字节记录的数组作为其数据内容。当启用RIPv2加密身份验证时，使用与原始RIPv2规范相同的头和内容，但原始RIPv2规范的16个八位字节的“身份验证”密码字段被重用，以包含身份验证数据的数据包偏移量、密钥标识符、身份验证数据长度、，和非递减序列号。
AUTHENTICATION TYPE The "Authentication Type" is Cryptographic Hash Function, which is indicated by the value 3.
身份验证类型“身份验证类型”是加密哈希函数，由值3表示。
RIPv2 PACKET LENGTH An unsigned 16-bit offset from the start of the RIPv2 header to the end of the regular RIPv2 packet (not including the authentication trailer).
RIPv2数据包长度从RIPv2报头开始到常规RIPv2数据包结束的无符号16位偏移量（不包括身份验证尾部）。
KEY IDENTIFIER An unsigned 8-bit field that contains the Key Identifier or Key-ID. This, in combination with the network interface, identifies the RIPv2 Security Association in use for this packet. The RIPv2 Security Association, which is defined in Section 2.2 below, includes the Authentication Key that was used to create the Authentication Data for this RIPv2 message and other parameters. In implementations supporting more than one authentication algorithm, the RIPv2 Security Association also includes information about which authentication algorithm is in use for this message. A RIPv2 Security Association is always associated with an interface, rather than with a router. The actual cryptographic key is part of the RIPv2 Security Association.
密钥标识符包含密钥标识符或密钥ID的无符号8位字段。该字段与网络接口结合，用于标识此数据包使用的RIPv2安全关联。以下第2.2节中定义的RIPv2安全关联包括用于为此RIPv2消息和其他参数创建身份验证数据的身份验证密钥。在支持多个身份验证算法的实现中，RIPv2安全关联还包括关于此消息使用哪个身份验证算法的信息。RIPv2安全关联始终与接口关联，而不是与路由器关联。实际加密密钥是RIPv2安全关联的一部分。
AUTHENTICATION DATA LENGTH An unsigned 8-bit field that contains the length in octets of the trailing Authentication Data field. The presence of this field helps provide cryptographic algorithm independence.
身份验证数据长度一个无符号8位字段，其中包含尾随身份验证数据字段的长度（以八位字节为单位）。此字段的存在有助于提供加密算法独立性。
AUTHENTICATION DATA This field contains the cryptographic Authentication Data used to validate this packet. The length of this field is stored in the AUTHENTICATION DATA LENGTH field above.
身份验证数据此字段包含用于验证此数据包的加密身份验证数据。此字段的长度存储在上面的身份验证数据长度字段中。
SEQUENCE NUMBER An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing for all messages sent from a given source router with a given Key ID value.
序列号无符号32位序列号。对于从具有给定密钥ID值的给定源路由器发送的所有消息，序列号必须是非递减的。
The authentication trailer contains the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
身份验证尾部包含身份验证数据，该数据是密钥加密哈希函数的输出。有关计算此字段的详细信息，请参阅本节后面的小节。
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
+---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+
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
+---------------+---------------+-------------------------------+
| Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type=0x0003 |
+---------------+---------------+---------------+---------------+
| RIPv2 Packet Length | Key ID | Auth Data Len |
+---------------+---------------+---------------+---------------+
| Sequence Number (non-decreasing) |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| reserved must be zero |
+---------------+---------------+---------------+---------------+
| |
~ (RIPv2 Packet Length - 24) bytes of Data ~
| |
+---------------+---------------+---------------+---------------+
| 0xFFFF | 0x0001 |
+---------------+---------------+---------------+---------------+
| Authentication Data (variable length; 20 bytes with HMAC-SHA1)|
+---------------+---------------+---------------+---------------+
Understanding the RIPv2 Security Association concept is central to understanding this specification. A RIPv2 Security Association contains the set of shared authentication configuration parameters needed by the legitimate sender or any legitimate receiver.
理解RIPv2安全关联概念是理解本规范的核心。RIPv2安全关联包含合法发送方或任何合法接收方所需的共享身份验证配置参数集。
An implementation MUST be able to support at least 2 concurrent RIPv2 Security Associations on each RIP interface. This is a functional requirement for supporting key rollover. Support for key rollover is mandatory.
一个实现必须能够在每个RIP接口上支持至少2个并发RIPv2安全关联。这是支持键翻转的功能要求。必须支持密钥滚动。
The RIPv2 Security Association, defined below, is selected by the sender based on the outgoing router interface. Each RIPv2 Security Association has a lifetime and other configuration parameters
以下定义的RIPv2安全关联由发送方根据传出路由器接口选择。每个RIPv2安全关联都有一个生存期和其他配置参数
associated with it. In normal operation, a RIPv2 Security Association is never used outside its lifetime. Certain abnormal cases are discussed later in this document.
与之相关的。在正常操作中，RIPv2安全关联在其生存期之外从未使用过。本文件后面将讨论某些异常情况。
The minimum data items in a RIPv2 Security Association are as follows:
RIPv2安全关联中的最小数据项如下：
KEY-IDENTIFIER (KEY-ID) The unsigned 8-bit KEY-ID value is used to identify the RIPv2 Security Association in use for this packet.
KEY-IDENTIFIER（KEY-ID）无符号8位KEY-ID值用于标识此数据包使用的RIPv2安全关联。
The receiver uses the combination of the interface the packet was received upon and the KEY-ID value to uniquely identify the appropriate Security Association.
接收器使用接收数据包时的接口和密钥ID值的组合来唯一标识适当的安全关联。
The sender selects which RIPv2 Security Association to use based on the outbound interface for this RIPv2 packet and then places the correct KEY-ID value into that packet. If multiple valid and active RIPv2 Security Associations exist for a given outbound interface at the time a RIPv2 packet is sent, the sender may use any of those security associations to protect the packet.
发送方基于此RIPv2数据包的出站接口选择要使用的RIPv2安全关联，然后将正确的密钥ID值放入该数据包中。如果在发送RIPv2数据包时，给定出站接口存在多个有效且活动的RIPv2安全关联，则发送方可以使用这些安全关联中的任何一个来保护该数据包。
AUTHENTICATION ALGORITHM This specifies the cryptographic algorithm and algorithm mode used with the RIPv2 Security Association. This information is never sent in cleartext over the wire. Because this information is not sent on the wire, the implementer chooses an implementation specific representation for this information. At present, the following values are possible: KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
身份验证算法指定与RIPv2安全关联一起使用的加密算法和算法模式。此信息从不以明文形式通过网络发送。因为该信息不是通过线路发送的，所以实现者为该信息选择了特定于实现的表示。目前，以下值是可能的：KEYED-MD5、HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512。
AUTHENTICATION KEY This is the value of the cryptographic authentication key used with the associated Authentication Algorithm. It MUST NOT ever be sent over the network in cleartext via any protocol. The length of this key will depend on the Authentication Algorithm in use. Operators should take care to select unpredictable and strong keys, avoiding any keys known to be weak for the algorithm in use. [ESC05] contains helpful information on both key generation techniques and cryptographic randomness.
身份验证密钥这是与关联身份验证算法一起使用的加密身份验证密钥的值。它决不能通过任何协议以明文形式通过网络发送。此密钥的长度将取决于使用的身份验证算法。操作员应注意选择不可预测的强密钥，避免使用已知算法弱的任何密钥。[ESC05]包含有关密钥生成技术和密码随机性的有用信息。
SEQUENCE NUMBER This is an unsigned 32-bit number. For a given KEY-ID value and sender, this number MUST NOT decrease. In normal operation, the operator should rekey the RIPv2 session prior to reaching the maximum value. The initial value used in the sequence number is arbitrary. Receivers SHOULD keep track of the most recent sequence number received from a given sender.
序列号这是一个无符号的32位数字。对于给定的密钥ID值和发送方，此数字不得减少。在正常操作中，操作员应在达到最大值之前重新输入RIPv2会话。序列号中使用的初始值是任意的。接收方应跟踪从给定发送方接收的最新序列号。
START TIME This is a local representation of the day and time that this Security Association first becomes valid.
开始时间这是此安全关联首次生效的日期和时间的本地表示形式。
STOP TIME This is a local representation of the day and time that this Security Association becomes invalid (i.e., when it expires). It is permitted, but not recommended, for an operator to configure this to "never expire". The "never expire" value is not recommended operational practice because it reduces security as compared with periodic rekeying. Normally, a RIPv2 Security Association is deleted at its STOP TIME. However, there are certain pathological cases, which are discussed in Section 5.1.
停止时间这是此安全关联失效的日期和时间的本地表示（即，当它过期时）。允许但不建议操作员将其配置为“永不过期”。建议不要使用“永不过期”值，因为与定期密钥更新相比，它会降低安全性。通常，RIPv2安全关联在其停止时被删除。但是，也有某些病理病例，在第5.1节中讨论。
The authentication trailer consists of the Authentication Data, which is the output of the keyed cryptographic hash function. See later subsections of this section for details on computing this field.
身份验证尾部由身份验证数据组成，身份验证数据是密钥加密哈希函数的输出。有关计算此字段的详细信息，请参阅本节后面的小节。
When the authentication type is "Cryptographic Hash Function", message processing is changed in message creation and reception as compared with the original RIPv2 specification in [Mal94].
当认证类型为“加密哈希函数”时，与[Mal94]中的原始RIPv2规范相比，消息创建和接收中的消息处理发生了变化。
This section describes the message processing generically. Additional algorithm-dependent processing that is required is described in separate, subsequent sections of this document. As of this writing, there are 2 kinds of algorithm-dependent processing. One covers the "Keyed-MD5" algorithm. The other covers the "HMAC-SHA1" family of algorithms.
本节一般介绍消息处理。所需的其他算法相关处理将在本文档的后续单独章节中描述。在撰写本文时，有两种算法相关的处理。其中包括“Keyed-MD5”算法。另一个涉及“HMAC-SHA1”算法家族。
The RIPv2 Packet is created as usual, with these exceptions:
RIPv2数据包按常规创建，但有以下例外情况：
(1) The UDP checksum SHOULD be calculated, but MAY be set to zero because any of the cryptographic authentication mechanisms in this specification will provide stronger integrity protection than the standard UDP checksum.
(1) 应该计算UDP校验和，但可以设置为零，因为本规范中的任何加密身份验证机制都将提供比标准UDP校验和更强的完整性保护。
(2) The Authentication Type field indicates Cryptographic Authentication (3).
(2) 身份验证类型字段表示加密身份验证（3）。
(3) The Authentication "password" field is reused to store a packet offset to the Authentication Data, a Key Identifier, the Authentication Data Length, and a non-decreasing sequence number.
(3) 重新使用认证“密码”字段来存储认证数据的分组偏移量、密钥标识符、认证数据长度和非递减序列号。
See also Section 2.2 above on RIPv2 Security Association for other important background information.
有关其他重要背景信息，请参见上面关于RIPv2安全协会的第2.2节。
When creating the RIPv2 Packet, the following process is followed:
创建RIPv2数据包时，遵循以下过程：
(1) The Packet Length field of the RIPv2 header indicates the size of the main body of the RIPv2 packet.
(1) RIPv2报头的数据包长度字段指示RIPv2数据包主体的大小。
(2) An appropriate RIPv2 Security Association is selected for use with this packet, based on the outbound interface for the packet. Any valid RIPv2 Security Association for that outbound interface may be used. The Authentication Data Offset, Key Identifier, and Authentication Data Length fields are filled in appropriately.
(2) 根据数据包的出站接口，选择适当的RIPv2安全关联用于该数据包。可以使用该出站接口的任何有效RIPv2安全关联。正确填写身份验证数据偏移量、密钥标识符和身份验证数据长度字段。
(3) Algorithm-dependent processing occurs now, either for the "Keyed-MD5" algorithm or for the "HMAC-SHA1" algorithm family. See the respective sub-sections (below) for details of this algorithm-dependent processing.
(3) 依赖于算法的处理现在出现，无论是“Keyed-MD5”算法还是“HMAC-SHA1”算法系列。有关此算法相关处理的详细信息，请参见各小节（下文）。
(4) The resulting Authentication Data value is written into the Authentication Data field. The trailing pad (if any) is not actually transmitted, as it is entirely predictable from the message length and Authentication Algorithm in use.
(4) 生成的身份验证数据值将写入身份验证数据字段。尾随盘（如果有）实际上并不传输，因为它完全可以从使用的消息长度和身份验证算法中预测。
When the message is received, the process is reversed:
收到该消息后，该过程将反转：
(1) The received Authentication Data is set aside and stored for later use,
(1) 将接收到的认证数据放在一边并存储起来以供以后使用，
(2) The appropriate RIPv2 Security Association is determined from the value of the Key Identifier field and the interface the packet was received on. If there is no valid RIPv2 Security Association for the received Key Identifier on the interface that the packet was received on, then:
(2) 根据密钥标识符字段的值和接收数据包的接口确定适当的RIPv2安全关联。如果在接收数据包的接口上接收到的密钥标识符没有有效的RIPv2安全关联，则：
(a) all processing of the incoming packet ceases, and
(a) 对传入数据包的所有处理停止，并且
(b) a security event SHOULD be logged by the RIPv2 subsystem of the receiving system. That security event should indicate at
(b) 接收系统的RIPv2子系统应记录安全事件。该安全事件应在
least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that no valid RIPv2 Security Association was found for that interface and Key-ID combination.
至少包括收到坏数据包的日期/时间、收到的RIPv2数据包的源IP地址、密钥ID字段值、坏数据包到达的接口，以及未找到该接口和密钥ID组合的有效RIPv2安全关联的事实。
(3) Algorithm-dependent processing is performed, using the algorithm specified by the appropriate RIPv2 Security Association for this packet. This results in calculation of the Authentication Data based on the information in the received RIPv2 packet and information from the appropriate RIPv2 Security Association for that packet.
(3) 使用适当的RIPv2安全关联为此数据包指定的算法，执行与算法相关的处理。这导致基于接收到的RIPv2分组中的信息和来自该分组的适当RIPv2安全关联的信息来计算认证数据。
(4) The calculated Authentication Data result is compared with the received Authentication Data.
(4) 将计算出的认证数据结果与接收到的认证数据进行比较。
(5) If the calculated authentication data result does not match the received Authentication Data field, then:
(5) 如果计算的身份验证数据结果与接收的身份验证数据字段不匹配，则：
(a) the message MUST be discarded without being processed, and
(a) 必须在未经处理的情况下丢弃该消息，并且
(b) a security event SHOULD be logged by the RIPv2 subsystem of the receiving system. That security event SHOULD indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, the interface the bad packet arrived upon, and the fact that RIPv2 Authentication failed upon receipt of the packet.
(b) 接收系统的RIPv2子系统应记录安全事件。该安全事件应至少指示接收到坏数据包的日期/时间、接收到的RIPv2数据包的源IP地址、密钥ID字段值、坏数据包到达的接口，以及接收到数据包后RIPv2身份验证失败的事实。
(6) If the neighbor has been heard from recently enough to have viable routes in the local routing table, and the received sequence number is less than the last sequence number received, then the message MUST be discarded unprocessed. If the received sequence number is less than the last sequence number received, that fact SHOULD be logged as a security event. This logged security event SHOULD indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, and the fact that an out-of-order RIPv2 sequence number was received.
(6) 如果邻居最近收到足够多的消息，在本地路由表中有可行的路由，并且接收到的序列号小于最后接收到的序列号，则必须未经处理地丢弃消息。如果收到的序列号小于上次收到的序列号，则应将该事实记录为安全事件。此记录的安全事件应至少指示接收到坏数据包的日期/时间、接收到的RIPv2数据包的源IP地址、密钥ID字段值以及接收到无序RIPv2序列号的事实。
When connectivity to the neighbor has been lost, the receiver SHOULD be ready to accept either:
当与邻居的连接中断时，接收器应准备好接受以下任一情况：
- a message with a sequence number of zero.
- 序列号为零的消息。
- a message with a higher sequence number than the last received sequence number.
- 序列号高于上次接收序列号的报文。
(7) Acceptable messages are now truncated to the RIPv2 message itself, minus the authentication trailer, and are processed normally (i.e., in accordance with the RIPv2 base specification in RFC 2453 [Mal98]). The last received sequence number for this RIPv2 Security Association and sender is also updated.
(7) 可接受的消息现在被截断为RIPv2消息本身，减去认证尾部，并正常处理（即，根据RFC 2453[Mal98]中的RIPv2基本规范）。此RIPv2安全关联和发送方的上次接收序列号也将更新。
NOTA BENE: A router that has forgotten its current sequence number but remembers its Security Association MUST send its first packet with a sequence number of zero. This leaves a small opening for a replay attack. To reduce the risk of such attacks by precluding the situation where a router has forgotten its current sequence number, implementers SHOULD provide non-volatile storage for all components of a RIPv2 Security Association, and receiving systems SHOULD provide non-volatile storage for the last received sequence number from each sender. See also the Security Considerations section of this document.
NOTA BENE：忘记当前序列号但记住其安全关联的路由器必须发送序列号为零的第一个数据包。这为重播攻击留下了一个很小的空间。为了通过排除路由器忘记其当前序列号的情况来降低此类攻击的风险，实施者应为RIPv2安全关联的所有组件提供非易失性存储，而接收系统应为从每个发送方最后接收到的序列号提供非易失性存储。另请参见本文档的安全注意事项部分。
This section describes the algorithm-dependent processing steps applicable when the "Keyed-MD5" authentication algorithm is in use. The RIPv2 Authentication Key is always 16 octets when "Keyed-MD5" is in use.
本节描述了使用“Keyed-MD5”认证算法时适用的算法相关处理步骤。使用“Keyed-MD5”时，RIPv2身份验证密钥始终为16个八位字节。
(1) The RIPv2 Authentication Key is appended to the RIPv2 packet in memory.
(1) RIPv2身份验证密钥附加到内存中的RIPv2数据包。
(2) The Trailing Pad for MD5 and message length fields are added in memory. The diagram below shows how these additions appear when appended in memory:
(2) MD5的尾随键盘和消息长度字段添加到内存中。下图显示了添加到内存中时这些添加内容的显示方式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Key |
/ (16 octets long) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad octets (as defined by RFC 1321) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3) The Authentication Data is then calculated according to the MD5 algorithm defined by RFC 1321 [Rivest92].
(3) 然后根据RFC 1321[Rivest92]定义的MD5算法计算认证数据。
This section describes the processing steps for HMAC Authentication. While HMAC was originally documented in [KMC97], for this specification, the terminology used in [FIPS-198] is used. While the current specification only provides full details for HMAC Authentication using the National Institute of Standards and Technology (NIST) SHA-1 algorithm (and its direct derivatives), this same basic process could be used with other cryptographic hash functions in the future. Because the RIPv2 packet is only hashed once, the overhead of the double hashing in this process is negligible.
本节介绍HMAC身份验证的处理步骤。虽然HMAC最初记录在[KMC97]中，但本规范使用了[FIPS-198]中使用的术语。虽然当前规范仅提供了使用国家标准与技术研究所（NIST）SHA-1算法（及其直接衍生算法）进行HMAC认证的全部细节，但这一基本过程在未来也可用于其他加密哈希函数。因为RIPv2数据包只被散列一次，所以这个过程中的双重散列开销可以忽略不计。
The US NIST Secure Hash Standard (SHS), defined by [FIPS-180-2], includes specifications for SHA-1, SHA-256, SHA-384, and SHA-512. This specification defines processing for each of these.
由[FIPS-180-2]定义的美国NIST安全哈希标准（SHS）包括SHA-1、SHA-256、SHA-384和SHA-512的规范。本规范规定了每一项的处理。
The output of the cryptographic computations (e.g., HMAC-SHA1) is NOT truncated for RIPv2 Cryptographic Authentication.
对于RIPv2加密验证，加密计算的输出（例如HMAC-SHA1）不会被截断。
The Authentication Data Length is equal to the Message Digest Size for the hash algorithm in use.
身份验证数据长度等于正在使用的哈希算法的消息摘要大小。
Any key value known to be weak with an algorithm defined by the NIST Secure Hash Standard MUST NOT be used with such an algorithm in an implementation of this specification. US NIST is the authoritative source for public information on weak keys for those algorithms.
在本规范的实施中，NIST安全哈希标准定义的算法中已知较弱的任何键值不得与此类算法一起使用。美国NIST是这些算法弱密钥公开信息的权威来源。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:
在下面的算法描述中，使用了与[FIPS-198]一致的以下术语：
H is the specific hashing algorithm, for example, SHA-1 or SHA-256. Ko is the cryptographic key used with the hash algorithm. B is the block-size of H, measured in octets, not bits. Note that B is the internal block size, not the hash size. 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, not bits. For example, with SHA-1, L == 20. XOR is the exclusive-or operation. Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
H是特定的哈希算法，例如SHA-1或SHA-256。Ko是与哈希算法一起使用的加密密钥。B是H的块大小，以八位字节（而不是位）度量。请注意，B是内部块大小，而不是散列大小。对于SHA-1和SHA-256:B==64。对于SHA-384和SHA-512:B==128 L是散列的长度，以八位字节而不是位来度量。例如，对于SHA-1，L==20。XOR是异或运算。Opad是十六进制值0x5c，重复B次。Ipad是十六进制值0x36，重复B次。Apad是十六进制值0x878FE1F3，重复（1/4）次。
(1) PREPARATION OF KEY In this application, Ko is always L octets long.
(1) 在本应用程序中，Ko的长度始终为L个八位字节。
If the Authentication Key is L octets long, then Ko is set equal to the Authentication Key. If the Authentication Key is more than L octets long, then Ko is set to H(Authentication Key). If the Authentication Key is less than L octets long, then Ko is set to the Authentication Key with zeros appended to the end of the Authentication Key such that Ko is L octets long.
如果身份验证密钥的长度为L个八位字节，则Ko被设置为等于身份验证密钥。如果身份验证密钥的长度超过L个八位字节，则Ko被设置为H（身份验证密钥）。如果身份验证密钥的长度小于L个八位字节，则将Ko设置为身份验证密钥，并在身份验证密钥的末尾附加零，从而使Ko的长度为L个八位字节。
(2) FIRST HASH First, the RIPv2 packet's Authentication Data field is filled with the value Apad.
(2) 首先散列首先，RIPv2数据包的身份验证数据字段填充值Apad。
Then, a first hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (RIPv2 Packet))
然后，第一散列（也称为内部散列）按如下方式计算：第一散列=H（Ko-XOR-Ipad | |（RIPv2-Packet））
(3) SECOND HASH Then a second hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash)
(3) 第二个散列然后第二个散列，也称为外部散列，计算如下：第二个散列=H（Ko XOR Opad | | First HASH）
(4) RESULT The result Second-Hash becomes the authentication data that is sent in the Authentication Data field of the RIPv2 packet. The length of the Authentication Data field is always identical to the message digest size of the hash function H that is being used.
(4) 结果结果第二个哈希成为在RIPv2数据包的身份验证数据字段中发送的身份验证数据。身份验证数据字段的长度始终与正在使用的哈希函数H的消息摘要大小相同。
This also implies that use of hash functions with larger output sizes will also increase the size of the packet as transmitted on the wire.
这还意味着使用输出大小更大的哈希函数也会增加数据包在有线传输时的大小。
Key management is an important component of this mechanism and proper implementation is central to providing the intended level of risk reduction.
关键管理是该机制的一个重要组成部分，适当的实施对于提供预期的风险降低水平至关重要。
It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be configured or stored using protocols (e.g., RADIUS) or cryptographic algorithms that have known flaws.
强烈希望一个互联网协议中假设的安全漏洞不会自动危及其他互联网协议。不应使用具有已知缺陷的协议（如RADIUS）或加密算法配置或存储本规范的身份验证密钥。
Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface. Implementations MUST associate a specific Security Association lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key. Implementations also MUST support manual key distribution. An example of manual key distribution is having the privileged user typing in the key, key lifetime, and key identifier on the router console. An operator may configure the Security Association lifetime to infinite, which means that the session is never rekeyed. However, instead, it is strongly recommended that operators rekey regularly, using a moderately short Security Association lifetime (e.g., 24 hours).
实现必须支持同时存储多个密钥，尽管人们认识到一个接口上通常只有一个密钥处于活动状态。实现必须将特定的安全关联生存期（即日期/时间首次有效和日期/时间不再有效）和密钥标识符与每个密钥相关联。实现还必须支持手动密钥分发。手动密钥分发的一个示例是让特权用户在路由器控制台上键入密钥、密钥生存期和密钥标识符。操作员可以将安全关联生存期配置为无限，这意味着会话永远不会重新设置密钥。但是，强烈建议操作员定期重新输入密钥，使用较短的安全关联寿命（例如24小时）。
This specification requires support for at least two authentication algorithms, so the implementation MUST require that the authentication algorithm be specified for each key when the other key information is entered. Manual deletion of active Security Associations MUST be supported.
该规范要求至少支持两种认证算法，因此实现必须要求在输入其他密钥信息时为每个密钥指定认证算法。必须支持手动删除活动的安全关联。
It is likely that the IETF will define a standard key management protocol for use with routing protocols. It is strongly desirable to use an IETF standards-track key management protocol to distribute RIPv2 Authentication Keys among communicating RIPv2 implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key-ID field can be used as a hook between RIPv2 and such a future protocol.
IETF可能会定义一个用于路由协议的标准密钥管理协议。强烈希望使用IETF标准跟踪密钥管理协议在通信RIPv2实现之间分发RIPv2认证密钥。这样一个协议将提供可伸缩性，并显著减少人力管理负担。密钥ID字段可以用作RIPv2和这样的未来协议之间的挂钩。
Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all RIPv2 implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
密钥管理协议有着很长的历史，在协议首次公开后很长一段时间，人们就发现了这些微妙的缺陷。为了避免在发现此类缺陷时必须更改所有RIPv2实现，本规范中故意省略了集成密钥管理协议技术。
As with all security methods using keys, it is necessary to change the RIPv2 Authentication Key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one RIPv2 Authentication Key on a given interface at the same time.
与使用密钥的所有安全方法一样，有必要定期更改RIPv2身份验证密钥。为了在此类更改期间保持路由稳定性，实现必须能够在给定接口上同时存储和使用多个RIPv2身份验证密钥。
Each key will have its own Key Identifier (KEY-ID), which is stored locally. The combination of the Key Identifier and the interface associated with the message uniquely identifies the Authentication Algorithm and RIPv2 Authentication Key in use.
每个密钥都有自己的密钥标识符（key-ID），存储在本地。密钥标识符和与消息相关联的接口的组合唯一地标识正在使用的身份验证算法和RIPv2身份验证密钥。
As noted above in Section 2.3.1, the party creating the RIPv2 message will select a valid RIPv2 Security Association from the set of valid RIPv2 Security Associations for that interface. The receiver MUST use the Key Identifier and receiving interface to determine which RIPv2 Security Association to use for authentication of the received message. More than one RIPv2 Security Association MAY be associated with an interface at the same time. The receiver MUST NOT simply try all RIPv2 Security Associations (i.e., keys) that might be configured for RIPv2 on the receiving interface, as that creates an easily exploited denial-of-service attack on the RIP subsystem of the receiver. (At least one widely used implementation of the previous version of this specification violates these requirements as of the publication date of this document and has consequent security vulnerabilities.)
如上文第2.3.1节所述，创建RIPv2消息的一方将从该接口的有效RIPv2安全关联集合中选择一个有效的RIPv2安全关联。接收方必须使用密钥标识符和接收接口来确定用于对接收到的消息进行身份验证的RIPv2安全关联。一个接口可以同时关联多个RIPv2安全关联。接收方不得简单地尝试在接收接口上为RIPv2配置的所有RIPv2安全关联（即密钥），因为这会在接收方的RIP子系统上造成容易被利用的拒绝服务攻击。（截至本文件发布之日，本规范先前版本中至少有一个广泛使用的实现违反了这些要求，并因此存在安全漏洞。）
Hence, it is possible to have fairly smooth RIPv2 Security Association (i.e., key) rollovers, without losing legitimate RIPv2 messages due to an invalid shared key and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating RIPv2 system must be updated with the new RIPv2 Security Association (including the new key) several minutes before the current RIPv2 Security Association will expire and several minutes before the new RIPv2 Security Association lifetime begins. Also, the new RIPv2 Security Association should have a lifetime that starts several minutes before the old RIPv2 Security Association expires. This gives time for each system to learn of the new security association before that security association will be used. It also ensures that the new security association will begin use and the current security association will go out of use before the current security association's lifetime expires. For the duration of the overlap in security association lifetimes, a system may receive messages corresponding to either security association and successfully authenticate the message. The Key-ID in the received message is used to select the appropriate security association (i.e., key) to be used for authentication.
因此，可以实现相当平滑的RIPv2安全关联（即密钥）滚动，而不会因为无效的共享密钥而丢失合法的RIPv2消息，也不会要求人们立即更改所有密钥。为确保顺利过渡，必须在当前RIPv2安全关联到期前几分钟和新RIPv2安全关联生存期开始前几分钟，使用新的RIPv2安全关联（包括新密钥）更新每个通信RIPv2系统。此外，新的RIPv2安全关联的生存期应该在旧的RIPv2安全关联到期前几分钟开始。这使每个系统在使用新的安全关联之前有时间了解该安全关联。它还确保新的安全关联将开始使用，而当前安全关联将在当前安全关联的生存期到期之前停止使用。在安全关联生存期的重叠期间，系统可以接收与任一安全关联对应的消息，并成功地对该消息进行身份验证。接收到的消息中的密钥ID用于选择用于认证的适当安全关联（即密钥）。
For this specification, the term "conformance" has identical meaning to the phrase "full compliance".
对于本规范，术语“一致性”与短语“完全一致性”具有相同的含义。
The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm MUST be implemented by all conforming implementations. In addition, the HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be implemented. MD5 is defined in [Rivest92]. SHA-1, SHA-256, SHA-384, and SHA-512 have been defined by the US NIST in [FIPS-180-2].
密钥MD5认证算法和HMAC-SHA1算法必须由所有一致性实现实现。此外，应实现HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512算法。MD5在[Rivest92]中定义。美国NIST在[FIPS-180-2]中定义了SHA-1、SHA-256、SHA-384和SHA-512。
A conforming implementation MAY also support additional authentication algorithms, provided those additional algorithms are publicly and openly specified.
一致性实现还可以支持附加认证算法，前提是这些附加算法是公开指定的。
Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key rollover described under "Key Management Procedures". This also means that implementations MUST support at least 2 concurrent RIPv2 Security Associations.
如上所述的手动密钥分发必须得到所有一致性实施的支持。所有实施必须支持“密钥管理程序”中所述的平滑密钥翻转。这也意味着实现必须支持至少2个并发RIPv2安全关联。
The user documentation provided with the implementation ought to contain clear instructions on how to configure the implementation such that smooth key rollover occurs successfully.
与实现一起提供的用户文档应该包含关于如何配置实现的明确说明，以便顺利实现密钥滚动。
Implementations SHOULD support a standard key management protocol for secure distribution of RIPv2 Authentication Keys once such a key management protocol is standardized by the IETF.
一旦RIPv2认证密钥管理协议被IETF标准化，实施应支持标准密钥管理协议，以安全分发RIPv2认证密钥。
The Security Considerations section of this document is an integral part of the specification, not just a discussion of the protocol.
本文档的安全注意事项部分是规范的组成部分，而不仅仅是对协议的讨论。
This entire memo describes and specifies an authentication mechanism for the RIPv2 routing protocol that is believed to be secure against passive attacks. The term "passive attack" is defined in RFC 1704 [HA94]. The analysis contained in RFC 1704 motivated this work. Passive attacks are clearly widespread in the Internet at present [HA94].
整个备忘录描述并指定了RIPv2路由协议的身份验证机制，该机制被认为是针对被动攻击的安全机制。RFC 1704[HA94]中定义了术语“被动攻击”。RFC1704中包含的分析推动了这项工作。目前，被动攻击显然在互联网上非常普遍[HA94]。
Protection against active attacks is incomplete in this current specification. The main issue relative to active attacks lies in the need to support the case where another router has recently rebooted and that router lacks the non-volatile storage needed to remember the RIPv2 Security Association(s) and last received RIPv2 sequence number(s) across that reboot.
在当前规范中，针对主动攻击的保护不完整。与主动攻击相关的主要问题在于需要支持另一台路由器最近重新启动，并且该路由器缺少在重新启动过程中记住RIPv2安全关联和上次接收到的RIPv2序列号所需的非易失性存储的情况。
Two known pathological cases exist that MUST be handled by implementations. Both of these are failures of the network manager. Each of these should be exceedingly rare in normal operation.
存在两个必须由实现处理的已知病理情况。这两个都是网络管理器的故障。在正常操作中，每种情况都应该非常罕见。
(1) During key rollover, devices might exist that have not yet been successfully configured with the new key. Therefore, routers SHOULD implement an algorithm that detects the set of RIPv2 Security Associations being used by its neighbors, and transmit its messages using both the new and old RIPv2 Security
(1) 在密钥翻转期间，可能存在尚未使用新密钥成功配置的设备。因此，路由器应该实现一种算法，检测其邻居正在使用的RIPv2安全关联集，并使用新的和旧的RIPv2安全关联来传输其消息
Associations (i.e., keys) until all of the neighbors are using the new security association or the lifetime of the old security association expires. Under normal circumstances, this elevated transmission rate will exist for a single RIP update interval.
关联（即密钥），直到所有邻居都在使用新安全关联或旧安全关联的生存期到期。在正常情况下，此提升的传输速率将在单个RIP更新间隔内存在。
(2) In the event that the last RIPv2 Security Association of an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router MUST send a "last RIPv2 Security Association expiration" notification to the network manager (e.g., via SYSLOG, SNMP, and/or other means) and SHOULD treat that last Security Association as having an infinite lifetime until the lifetime is extended, the Security Association is deleted by network management, or a new security association is configured.
(2) 如果接口的最后一个RIPv2安全关联过期，则不能恢复到未经验证的状态，也不建议中断路由。因此，路由器必须向网络管理器发送“最后一个RIPv2安全关联到期”通知（例如，通过系统日志、SNMP和/或其他方式），并应将该最后一个安全关联视为具有无限生存期，直到生存期延长，网络管理删除该安全关联，或者配置了新的安全关联。
In some circumstances, the practice described in (2) can leave an opening to an active attack on the RIPv2 routing subsystem. Therefore, any actual occurrence of a RIPv2 Security Association expiration MUST cause a security event to be logged by the implementation. This log item MUST include at least a note that the RIPv2 Authentication Key expired, the RIP routing protocol instance(s) affected, the routing interfaces affected, the Key-ID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice to help detect active attacks on the RIPv2 routing subsystem. Further, implementations SHOULD provide a configuration knob ("fail secure") to let a network operator prefer to have the RIPv2 routing fail when the last key expires, rather than continue using RIPv2 in an insecure manner.
在某些情况下，（2）中描述的实践可能会为RIPv2路由子系统上的主动攻击留下漏洞。因此，任何实际发生的RIPv2安全关联过期都必须导致实现记录安全事件。此日志项必须至少包括一条注释，说明RIPv2身份验证密钥已过期、受影响的RIP路由协议实例、受影响的路由接口、受影响的密钥ID以及当前日期/时间。鼓励操作员检查此类日志，作为操作安全实践，以帮助检测RIPv2路由子系统上的主动攻击。此外，实现应该提供一个配置旋钮（“fail-secure”），让网络运营商在最后一个密钥过期时更愿意让RIPv2路由失败，而不是继续以不安全的方式使用RIPv2。
Also, the use of SNMP, even SNMPv3 with cryptographic authentication and cryptographic confidentiality enabled, to modify or configure the RIPv2 Security Associations, or any component of the security association (for example, the cryptographic key), is NOT RECOMMENDED. This practice would create a potential for a cascading vulnerability, whereby a compromise in the SNMP security implementation would necessarily lead to a compromise not only of the local routing table (which could be accessed via SNMP) but also of all other routers that receive RIPv2 packets (directly or indirectly) from the compromised router.
此外，不建议使用SNMP（甚至启用了加密身份验证和加密机密性的SNMPv3）来修改或配置RIPv2安全关联或安全关联的任何组件（例如，加密密钥）。这种做法可能会产生级联漏洞，因此SNMP安全实施中的危害必然不仅会导致本地路由表（可通过SNMP访问）的危害，还会导致从受损路由器（直接或间接）接收RIPv2数据包的所有其他路由器的危害。
Similarly, the use of protocols not designed and evaluated for use in key management (e.g., RADIUS, Diameter) to configure the security association is also NOT RECOMMENDED. Reading the Security Associations via SNMP is allowed, but the information is to be treated as security-sensitive and protected by using the priv mode.
同样，也不建议使用未设计和评估用于密钥管理的协议（例如，RADIUS、Diameter）来配置安全关联。允许通过SNMP读取安全关联，但应将信息视为安全敏感信息，并使用priv模式进行保护。
Also, the use of SNMP to configure which form of RIPv2 authentication is in use is also NOT RECOMMENDED because of a similar cascading failure issue. Any future revision of the RIPv2 Management Information Base (MIB) [MB94] should consider making the rip2IfConfAuthType object read-only. Further, this object would need a new enum value to accommodate the RIPv2 cryptographic authentication type. In addition, the compliance statement for this MIB does not have a MIN-ACCESS for this object. At a minimum, if the MIB is updated, a new compliance statement SHOULD be written for this object that allows this object to be implemented as read-only. For the rip2ifConfAuthKey object, since this object always returns ''H when read, the object's MIN-ACCESS in any revised compliance statement SHOULD be not-accessible if the MIB is updated.
此外，由于类似的级联故障问题，也不建议使用SNMP配置使用哪种形式的RIPv2身份验证。RIPv2管理信息库（MIB）的任何未来版本[M94]都应该考虑使RiPiFiffAsTeType对象只读。此外，该对象需要一个新的枚举值来适应RIPv2加密身份验证类型。此外，此MIB的符合性声明对此对象没有最小访问权限。至少，如果MIB已更新，则应为此对象编写一个新的符合性声明，以允许此对象以只读方式实现。对于rip2ifConfAuthKey对象，由于此对象在读取时始终返回“H”，因此如果MIB更新，则任何修订的符合性声明中的对象的最小访问权限都不应被访问。
Further, for similar reasons, any future revisions to the RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any objects that would permit the writing of any RIPv2 Security Association or RIPv2 Security Association component (e.g., the cryptographic key).
此外，出于类似的原因，RIPv2管理信息库（MIB）的任何未来版本都应弃用或省略允许写入任何RIPv2安全关联或RIPv2安全关联组件（例如，加密密钥）的任何对象。
Also, it is RECOMMENDED that any future revisions to the RIPv2 Management Information Base (MIB) consider adding MIB objects to hold information about any RIPv2 security events that might have occurred, and MIB objects that could be used to read the set of security events that have been logged by the RIPv2 subsystem. For each security event mentioned in this document, it is also RECOMMENDED that appropriate notifications be included, with a MAX-ACCESS of Accessible-for-notify, in any future versions of the RIPv2 MIB module.
此外，建议对RIPv2管理信息库（MIB）的任何未来修订都考虑添加MIB对象来保存可能发生的任何RIPv2安全事件的信息，以及MIB对象，这些对象可以用于读取由RIPv2子系统记录的安全事件集。对于本文档中提到的每个安全事件，还建议在RIPv2 MIB模块的任何未来版本中包括适当的通知，并具有可访问的最大通知访问权限。
For the past several years, manual configuration (e.g., via a console) has been commonly used to create and modify RIPv2 Security Associations. There are a number of large-scale RIP deployments today that successfully use manual configuration of RIPv2 Security Associations. There are also sites that use scripts (e.g., combining Tcl/Expect, PERL, and SSHv2) with a site-specific configuration database and secure console connections to dynamically manage all aspects of their router configurations, including their RIPv2 Security Associations. This last approach is similar to the current IETF approach to Network Configuration (NetConf) standards.
在过去几年中，通常使用手动配置（例如通过控制台）来创建和修改RIPv2安全关联。目前有许多大型RIP部署成功地使用了RIPv2安全关联的手动配置。还有一些站点使用脚本（例如，将Tcl/Expect、PERL和SSHv2与特定于站点的配置数据库和安全控制台连接相结合）来动态管理其路由器配置的所有方面，包括其RIPv2安全关联。最后一种方法类似于当前的IETF网络配置方法（NetConf）标准。
Recent IETF Multicast Security (MSEC) working group efforts into multicast key management appear promising. Several large RIPv2 deployments happen to also have deployed the Kerberos authentication system. Recent IETF work into the use of Kerberos for Internet Key Negotiation (KINK) also seems relevant; one might use Kerberos to support RIPv2 key management functions for use at sites that have already deployed Kerberos. It is hoped that in the future the IETF will standardize a key management protocol suitable for managing RIPv2 Security Associations.
最近IETF多播安全（MSEC）工作组在多播密钥管理方面的努力似乎很有希望。几个大型RIPv2部署碰巧也部署了Kerberos身份验证系统。IETF最近在使用Kerberos进行Internet密钥协商（KINK）方面的工作似乎也很相关；可以使用Kerberos支持RIPv2密钥管理功能，以便在已部署Kerberos的站点上使用。希望未来IETF将标准化适用于管理RIPv2安全关联的密钥管理协议。
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating RIPv2 implementations. This mechanism also depends on the RIPv2 Authentication Key being kept confidential by all parties. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
用户需要了解，该机制提供的安全性的质量完全取决于所实现的身份验证算法的强度、所使用密钥的强度以及所有通信RIPv2实现中安全机制的正确实现。该机制还取决于各方对RIPv2身份验证密钥保密。如果其中任何一项不正确或不够安全，则不会为该机制的用户提供真正的安全性。
Use of high-assurance development methods is RECOMMENDED for implementations of this specification, in order to reduce the risk of subtle implementation flaws that might adversely impact the operational risk reduction that this specification seeks to provide.
建议对本规范的实施使用高保证开发方法，以降低细微实施缺陷的风险，这些缺陷可能会对本规范试图提供的运营风险降低产生不利影响。
Confidentiality is not provided by this mechanism. It is generally considered that an IP routing protocol does not require confidentiality, as the purpose of any routing protocols is to disseminate information about the topology of the network.
此机制不提供机密性。一般认为，IP路由协议不需要保密，因为任何路由协议的目的都是传播有关网络拓扑的信息。
Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption SHOULD be used when protection against traffic analysis is required [CKHD89].
还未提供针对流量分析的保护。当需要流量分析保护时，应使用批量链路加密等机制[CKHD89]。
Separately, the receipt of a RIPv2 packet using cryptographic authentication but containing an invalid or unknown Key-ID value might indicate an active attack on the RIP routing subsystem and is a significant security event. Therefore, any actual receipt of a RIPv2 packet using cryptographic authentication and containing an unknown, expired, or otherwise invalid KEY-ID value SHOULD cause a security event to be logged by the implementation. This log item SHOULD include at least the fact that the invalid KEY-ID was received, the source IP address of the packet containing the invalid KEY-ID, the
另外，接收到使用加密身份验证但包含无效或未知密钥ID值的RIPv2数据包可能表示对RIP路由子系统的主动攻击，这是一个重要的安全事件。因此，任何使用加密身份验证并包含未知、过期或无效密钥ID值的RIPv2数据包的实际接收都会导致实现记录安全事件。此日志项应至少包括接收到无效密钥ID的事实、包含无效密钥ID的数据包的源IP地址以及
interface(s) the packet was received on, the KEY-ID received, and the current date/time.
接收数据包的接口、接收到的密钥ID和当前日期/时间。
A subtle user-interface consideration also should be noted. If a user interface only permits the entry of human-readable text (e.g., a password in US-ASCII format) for use as a cryptographic key, significant numbers of bits of the cryptographic key in use become predictable, thereby reducing the strength of the key in this context. For this reason, implementations of this specification SHOULD support the entry of RIPv2 cryptographic authentication keys in hexadecimal format.
还应注意微妙的用户界面考虑。如果用户界面仅允许输入人类可读文本（例如，US-ASCII格式的密码）以用作加密密钥，则使用中的加密密钥的大量比特将变得可预测，从而降低该上下文中密钥的强度。因此，本规范的实现应支持以十六进制格式输入RIPv2加密身份验证密钥。
Specification and deployment of a standards-track key management protocol that supports this RIPv2 cryptographic authentication mechanism would be a significant next step in operational risk reduction and might actually increase the ease of deployment and operation of this mechanism. Such specification is beyond the scope of this document. Recent IETF work in MSEC and KINK working groups appears promising in this regard. Recent IETF work in the NETCONF working group towards standardizing methods for secure configuration management of routers is also relevant.
规范和部署支持此RIPv2加密身份验证机制的标准跟踪密钥管理协议将是降低操作风险的重要下一步，并可能实际增加此机制的部署和操作难度。此类规范超出了本文件的范围。在这方面，MSEC和KINK工作组最近的IETF工作似乎很有希望。NETCONF工作组最近在路由器安全配置管理方法标准化方面的IETF工作也与此相关。
Finally, we observe that this mechanism is not the final word on RIPv2 authentication. Rather, it is believed that this particular mechanism represents a significant risk reduction over previous methods (e.g., plaintext passwords), while remaining straightforward to implement correctly and also straightforward to deploy.
最后，我们观察到，这种机制并不是RIPv2身份验证的最终决定。相反，人们认为，与以前的方法（例如明文密码）相比，这种特定的机制可以显著降低风险，同时保持正确实施和部署的简单性。
User communities that believe this mechanism is not adequate to their needs are encouraged to consider using digital signatures with RIPv2. [MBW97] specifies the use of OSPF with Digital signatures; that document might be a starting point for creating such a specification for the RIPv2 protocol. Digital signatures are significantly more expensive computationally and are also significantly more difficult to deploy operationally, as compared with the mechanism specified here. However, it appears likely that much of the mechanism in this document could be reused with digital signatures.
相信这个机制不适合他们的需求的用户社区被鼓励考虑使用RIPv2的数字签名。[MBW97]规定使用带有数字签名的OSPF；该文档可能是为RIPv2协议创建此类规范的起点。与这里指定的机制相比，数字签名在计算上要昂贵得多，在操作上部署起来也要困难得多。然而，本文件中的大部分机制似乎可以与数字签名一起重用。
Fred Baker was co-author of the earlier RIPv2 MD5 Authentication document [AB97]. This document is a direct derivative of that earlier document, though it has been significantly reworked. The current authors would like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of versions of this document.
Fred Baker是早期RIPv2 MD5认证文件[AB97]的共同作者。本文件是该早期文件的直接衍生版本，但经过了大量修改。现任作者感谢（美国）NIST的比尔·伯尔、蒂姆·波尔克、约翰·凯尔西和莫里斯·德沃金对本文件版本的审查。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Mal98] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[Mal98]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf>.
[FIPS-180-2]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-22002年8月<http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf>。
[FIPS-198] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002, <http://csrc.nist.gov/publications/ fips/fips198/fips-198a.pdf>.
[FIPS-198]国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，FIPS PUB 198，2002年3月<http://csrc.nist.gov/publications/ fips/fips198/fips-198a.pdf>。
[AB97] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[AB97]Baker，F.和R.Atkinson，“RIP-2 MD5认证”，RFC 2082，1997年1月。
[Bell89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[Bell89]S.Bellovin，“TCP/IP协议套件中的安全问题”，《ACM计算机通信评论》，第19卷，第2期，第32-48页，1989年4月。
[CKHD89] Cole Jr, Raymond, Donald Kallgren, Richard Hale, and John R. Davis, "Multilevel Secure Mixed-Media Communication Networks", Proceedings of the IEEE Military Communications Conference (MILCOM '89), IEEE, 1989.
[CKHD89]Cole Jr、Raymond、Donald Kallgren、Richard Hale和John R.Davis，“多级安全混合媒体通信网络”，IEEE军事通信会议记录（MILCOM'89），IEEE，1989年。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, 2 May 1996. (Presented at 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年夏季。
[ESC05] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ESC05]伊斯特莱克，D.，3，席勒，J.，和S.克罗克，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[KMC97] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[KMC97]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[Mal94] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, November 1994.
[Mal94]Malkin，G.，“RIP版本2-携带附加信息”，RFC 17231994年11月。
[MB94] Malkin, G. and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, November 1994.
[MB94]Malkin，G.和F.Baker，“RIP版本2 MIB扩展”，RFC 17241994年11月。
[MBW97] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[MBW97]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[Rivest92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[Rivest92]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
Authors' Addresses
作者地址
R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
R.阿特金森极限网络美国加利福尼亚州圣克拉拉门罗街3585号，邮编95051
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
M. Fanto (US) National Institute of Standards and Technology Gaithersburg, MD 20878 USA
M.Fanto（美国）美国马里兰州盖瑟斯堡国家标准与技术研究所20878
Phone: +1 (301) 975-2000
EMail: mattjf@umd.edu
Web: http://csrc.nist.gov
Phone: +1 (301) 975-2000
EMail: mattjf@umd.edu
Web: http://csrc.nist.gov
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。