Network Working Group F. Baker
Request for Comments: 2747 Cisco
Category: Standards Track B. Lindell
USC/ISI
M. Talwar
Microsoft
January 2000
Network Working Group F. Baker
Request for Comments: 2747 Cisco
Category: Standards Track B. Lindell
USC/ISI
M. Talwar
Microsoft
January 2000
RSVP Cryptographic Authentication
RSVP加密认证
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
本文档描述了RSVP的INTEGRITY对象的格式和使用，以提供逐跳完整性和RSVP消息的身份验证。
The Resource ReSerVation Protocol RSVP [1] is a protocol for setting up distributed state in routers and hosts, and in particular for reserving resources to implement integrated service. RSVP allows particular users to obtain preferential access to network resources, under the control of an admission control mechanism. Permission to make a reservation will depend both upon the availability of the requested resources along the path of the data, and upon satisfaction of policy rules.
资源预留协议RSVP[1]是用于在路由器和主机中建立分布式状态的协议，特别是用于预留资源以实现集成服务的协议。RSVP允许特定用户在准入控制机制的控制下优先访问网络资源。是否允许进行预订将取决于数据路径上请求的资源的可用性，以及是否满足策略规则。
To ensure the integrity of this admission control mechanism, RSVP requires the ability to protect its messages against corruption and spoofing. This document defines a mechanism to protect RSVP message integrity hop-by-hop. The proposed scheme transmits an authenticating digest of the message, computed using a secret Authentication Key and a keyed-hash algorithm. This scheme provides protection against forgery or message modification. The INTEGRITY object of each RSVP message is tagged with a one-time-use sequence
为了确保此接纳控制机制的完整性，RSVP需要能够保护其消息免受损坏和欺骗。本文档定义了一种逐跳保护RSVP消息完整性的机制。所提出的方案传输消息的认证摘要，该摘要使用秘密认证密钥和密钥哈希算法计算。该方案提供了防止伪造或修改消息的保护。每个RSVP消息的完整性对象都使用一次性使用序列进行标记
number. This allows the message receiver to identify playbacks and hence to thwart replay attacks. The proposed mechanism does not afford confidentiality, since messages stay in the clear; however, the mechanism is also exportable from most countries, which would be impossible were a privacy algorithm to be used. Note: this document uses the terms "sender" and "receiver" differently from [1]. They are used here to refer to systems that face each other across an RSVP hop, the "sender" being the system generating RSVP messages.
数字这允许消息接收器识别回放，从而阻止回放攻击。提议的机制不提供保密性，因为信息保持透明；然而，该机制也可从大多数国家出口，如果使用隐私算法，这是不可能的。注：本文件使用的术语“发件人”和“收件人”与[1]不同。在这里，它们用于指通过RSVP跃点相互面对的系统，“发送方”是生成RSVP消息的系统。
The message replay prevention algorithm is quite simple. The sender generates packets with monotonically increasing sequence numbers. In turn, the receiver only accepts packets that have a larger sequence number than the previous packet. To start this process, a receiver handshakes with the sender to get an initial sequence number. This memo discusses ways to relax the strictness of the in-order delivery of messages as well as techniques to generate monotonically increasing sequence numbers that are robust across sender failures and restarts.
消息重播预防算法非常简单。发送方生成序列号单调递增的数据包。反过来，接收器只接受序列号大于前一个数据包的数据包。要开始这个过程，接收方与发送方握手以获得初始序列号。本备忘录讨论了放松消息按顺序传递的严格性的方法，以及生成单调递增序列号的技术，这些序列号在发送方故障和重新启动时都很稳定。
The proposed mechanism is independent of a specific cryptographic algorithm, but the document describes the use of Keyed-Hashing for Message Authentication using HMAC-MD5 [7]. As noted in [7], there exist stronger hashes, such as HMAC-SHA1; where warranted, implementations will do well to make them available. However, in the general case, [7] suggests that HMAC-MD5 is adequate to the purpose at hand and has preferable performance characteristics. [7] also offers source code and test vectors for this algorithm, a boon to those who would test for interoperability. HMAC-MD5 is required as a baseline to be universally included in RSVP implementations providing cryptographic authentication, with other proposals optional (see Section 6 on Conformance Requirements).
所提出的机制独立于特定的加密算法，但本文档描述了使用HMAC-MD5将密钥散列用于消息身份验证[7]。如[7]所述，存在更强的散列，如HMAC-SHA1；在保证的情况下，实现将很好地使它们可用。然而，在一般情况下，[7]表明HMAC-MD5足以满足当前目的，并具有更好的性能特征。[7] 还提供了该算法的源代码和测试向量，这对那些测试互操作性的人来说是一个福音。HMAC-MD5被要求作为基线，普遍包含在提供加密身份验证的RSVP实现中，其他方案是可选的（参见第6节一致性要求）。
The RSVP checksum MAY be disabled (set to zero) when the INTEGRITY object is included in the message, as the message digest is a much stronger integrity check.
当完整性对象包含在消息中时，RSVP校验和可能被禁用（设置为零），因为消息摘要是一个更强的完整性检查。
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 [8].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[8]中所述进行解释。
One obvious question is why, since there exists a standard authentication mechanism, IPSEC [3,5], we would choose not to use it. This was discussed at length in the working group, and the use of IPSEC was rejected for the following reasons.
一个明显的问题是，既然存在一个标准的身份验证机制IPSEC[3,5]，为什么我们会选择不使用它。工作组对此进行了详细讨论，并基于以下原因拒绝使用IPSEC。
The security associations in IPSEC are based on destination address. It is not clear that RSVP messages are well defined for either source or destination based security associations, as a router must forward PATH and PATH TEAR messages using the same source address as the sender listed in the SENDER TEMPLATE. RSVP traffic may otherwise not follow exactly the same path as data traffic. Using either source or destination based associations would require opening a new security association among the routers for which a reservation traverses.
IPSEC中的安全关联基于目标地址。由于路由器必须使用与发件人模板中列出的发件人相同的源地址转发路径和路径撕裂消息，因此不清楚RSVP消息是否针对源或目标安全关联进行了良好定义。否则，RSVP通信可能不会遵循与数据通信完全相同的路径。使用基于源或目标的关联需要在保留所经过的路由器之间打开一个新的安全关联。
In addition, it was noted that neighbor relationships between RSVP systems are not limited to those that face one another across a communication channel. RSVP relationships across non-RSVP clouds, such as those described in Section 2.9 of [1], are not necessarily visible to the sending system. These arguments suggest the use of a key management strategy based on RSVP router to RSVP router associations instead of IPSEC.
此外，注意到RSVP系统之间的邻居关系不限于在通信信道上彼此面对的那些。跨非RSVP云的RSVP关系（如[1]第2.9节所述）不一定对发送系统可见。这些论点建议使用基于RSVP路由器到RSVP路由器关联的密钥管理策略，而不是IPSEC。
An RSVP message consists of a sequence of "objects," which are type-length-value encoded fields having specific purposes. The information required for hop-by-hop integrity checking is carried in an INTEGRITY object. The same INTEGRITY object type is used for both IPv4 and IPv6.
RSVP消息由一系列“对象”组成，这些对象是具有特定用途的类型长度值编码字段。逐跳完整性检查所需的信息包含在完整性对象中。IPv4和IPv6都使用相同的完整性对象类型。
The INTEGRITY object has the following format:
完整性对象具有以下格式：
Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1
Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1
+-------------+-------------+-------------+-------------+
| Flags | 0 (Reserved)| |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| Flags | 0 (Reserved)| |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
o Flags: An 8-bit field with the following format:
o 标志：具有以下格式的8位字段：
Flags
旗帜
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| H | |
| F | 0 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| H | |
| F | 0 |
+---+---+---+---+---+---+---+---+
Currently only one flag (HF) is defined. The remaining flags are reserved for future use and MUST be set to 0.
目前只定义了一个标志（HF）。其余标志保留供将来使用，必须设置为0。
o Bit 0: Handshake Flag (HF) concerns the integrity handshake mechanism (Section 4.3). Message senders willing to respond to integrity handshake messages SHOULD set this flag to 1 whereas those that will reject integrity handshake messages SHOULD set this to 0.
o 第0位：握手标志（HF）涉及完整性握手机制（第4.3节）。愿意响应完整性握手消息的消息发送者应将此标志设置为1，而拒绝完整性握手消息的消息发送者应将其设置为0。
o Key Identifier: An unsigned 48-bit number that MUST be unique for a given sender. Locally unique Key Identifiers can be generated using some combination of the address (IP or MAC or LIH) of the sending interface and the key number. The combination of the Key Identifier and the sending system's IP address uniquely identifies the security association (Section 2.2).
o 密钥标识符：一个无符号的48位数字，对于给定的发送方必须是唯一的。可以使用发送接口的地址（IP或MAC或LIH）和密钥号的某种组合来生成本地唯一密钥标识符。密钥标识符和发送系统IP地址的组合唯一地标识了安全关联（第2.2节）。
o Sequence Number: An unsigned 64-bit monotonically increasing, unique sequence number.
o 序列号：无符号64位单调递增的唯一序列号。
Sequence Number values may be any monotonically increasing sequence that provides the INTEGRITY object [of each RSVP message] with a tag that is unique for the associated key's lifetime. Details on sequence number generation are presented in Section 3.
序列号值可以是任何单调递增的序列，该序列为[每个RSVP消息的]完整性对象提供在相关密钥的生命周期内唯一的标记。有关序列号生成的详细信息，请参见第3节。
o Keyed Message Digest: The digest MUST be a multiple of 4 octets long. For HMAC-MD5, it will be 16 bytes long.
o 键控消息摘要：摘要长度必须是4个八位字节的倍数。对于HMAC-MD5，它将有16个字节长。
The sending and receiving systems maintain a security association for each authentication key that they share. This security association includes the following parameters:
发送和接收系统为它们共享的每个身份验证密钥维护安全关联。此安全关联包括以下参数：
o Authentication algorithm and algorithm mode being used.
o 正在使用的身份验证算法和算法模式。
o Key used with the authentication algorithm.
o 与身份验证算法一起使用的密钥。
o Lifetime of the key.
o 钥匙的使用寿命。
o Associated sending interface and other security association selection criteria [REQUIRED at Sending System].
o 关联的发送接口和其他安全关联选择标准[发送系统需要]。
o Source Address of the sending system [REQUIRED at Receiving System].
o 发送系统的源地址[接收系统需要]。
o Latest sending sequence number used with this key identifier [REQUIRED at Sending System].
o 与此密钥标识符一起使用的最新发送序列号[发送系统需要]。
o List of last N sequence numbers received with this key identifier [REQUIRED at Receiving System].
o 使用此密钥标识符接收的最后N个序列号列表[接收系统需要]。
In this section we describe methods that could be chosen to generate the sequence numbers used in the INTEGRITY object of an RSVP message. As previous stated, there are two important properties that MUST be satisfied by the generation procedure. The first property is that the sequence numbers are unique, or one-time, for the lifetime of the integrity key that is in current use. A receiver can use this property to unambiguously distinguish between a new or a replayed message. The second property is that the sequence numbers are generated in monotonically increasing order, modulo 2^64. This is required to greatly reduce the amount of saved state, since a receiver only needs to save the value of the highest sequence number seen to avoid a replay attack. Since the starting sequence number might be arbitrarily large, the modulo operation is required to accommodate sequence number roll-over within some key's lifetime. This solution draws from TCP's approach [9].
在本节中，我们将介绍可以选择哪些方法来生成RSVP消息的完整性对象中使用的序列号。如前所述，生成过程必须满足两个重要属性。第一个属性是序列号在当前使用的完整性密钥的生存期内是唯一的或一次性的。接收者可以使用此属性明确区分新消息或重播消息。第二个特性是序列号是以模2^64的单调递增顺序生成的。这需要极大地减少保存状态的数量，因为接收器只需要保存所看到的最高序列号的值，以避免重播攻击。由于起始序列号可能任意大，因此需要模运算以适应某些密钥的生命周期内的序列号翻转。此解决方案借鉴了TCP的方法[9]。
The sequence number field is chosen to be a 64-bit unsigned quantity. This is large enough to avoid exhaustion over the key lifetime. For example, if a key lifetime was conservatively defined as one year, there would be enough sequence number values to send RSVP messages at an average rate of about 585 gigaMessages per second. A 32-bit sequence number would limit this average rate to about 136 messages per second.
序列号字段被选择为64位无符号量。这足够大，以避免在密钥生命周期内耗尽。例如，如果密钥生存期被保守地定义为一年，那么将有足够的序列号值以大约每秒585 gigaMessages的平均速率发送RSVP消息。32位序列号将把平均速率限制为每秒136条消息。
The ability to generate unique monotonically increasing sequence numbers across a failure and restart implies some form of stable storage, either local to the device or remotely over the network. Three sequence number generation procedures are described below.
在故障和重启期间生成唯一单调递增序列号的能力意味着某种形式的稳定存储，无论是设备本地存储还是网络远程存储。下面描述三个序列号生成过程。
The most straightforward approach is to generate a unique sequence number using a message counter. Each time a message is transmitted for a given key, the sequence number counter is incremented. The current value of this counter is continually or periodically saved to stable storage. After a restart, the counter is recovered using this stable storage. If the counter was saved periodically to stable storage, the count should be recovered by increasing the saved value to be larger than any possible value of the counter at the time of the failure. This can be computed, knowing the interval at which the counter was saved to stable storage and incrementing the stored value by that amount.
最直接的方法是使用消息计数器生成唯一的序列号。每次为给定密钥发送消息时，序列号计数器都会递增。此计数器的当前值将持续或定期保存到稳定存储器中。重新启动后，使用此稳定存储器恢复计数器。如果计数器定期保存到稳定存储器，则应通过将保存的值增加到大于故障时计数器的任何可能值来恢复计数。这是可以计算出来的，知道计数器保存到稳定存储器的时间间隔，并将存储值增加该值。
Most devices will probably not have the capability to save sequence number counters to stable storage for each key. A more universal solution is to base sequence numbers on the stable storage of a real time clock. Many computing devices have a real time clock module that includes stable storage of the clock. These modules generally include some form of nonvolatile memory to retain clock information in the event of a power failure.
大多数设备可能没有能力将序列号计数器保存到每个密钥的稳定存储中。一个更普遍的解决方案是将序列号建立在实时时钟的稳定存储上。许多计算设备都有一个实时时钟模块，其中包括时钟的稳定存储。这些模块通常包括某种形式的非易失性存储器，以在发生电源故障时保留时钟信息。
In this approach, we could use an NTP based timestamp value as the sequence number. The roll-over period of an NTP timestamp is about 136 years, much longer than any reasonable lifetime of a key. In addition, the granularity of the NTP timestamp is fine enough to allow the generation of an RSVP message every 200 picoseconds for a given key. Many real time clock modules do not have the resolution of an NTP timestamp. In these cases, the least significant bits of the timestamp can be generated using a message counter, which is reset every clock tick. For example, when the real time clock provides a resolution of 1 second, the 32 least significant bits of the sequence number can be generated using a message counter. The remaining 32 bits are filled with the 32 least significant bits of the timestamp. Assuming that the recovery time after failure takes longer than one tick of the real time clock, the message counter for the low order bits can be safely reset to zero after a restart.
在这种方法中，我们可以使用基于NTP的时间戳值作为序列号。NTP时间戳的滚动周期约为136年，远长于密钥的任何合理使用寿命。此外，NTP时间戳的粒度足够精细，以允许针对给定密钥每隔200皮秒生成RSVP消息。许多实时时钟模块没有NTP时间戳的分辨率。在这些情况下，可以使用消息计数器生成时间戳的最低有效位，该计数器在每个时钟周期内重置。例如，当实时时钟提供1秒的分辨率时，可以使用消息计数器生成序列号的32个最低有效位。剩余的32位用时间戳的32个最低有效位填充。假设故障后的恢复时间超过实时时钟的一个刻度，则低阶位的消息计数器可在重新启动后安全重置为零。
If the device does not contain any stable storage of sequence number counters or of a real time clock, it could recover the real time clock from the network using NTP. Once the clock has been recovered following a restart, the sequence number generation procedure would be identical to the procedure described above.
如果设备不包含任何序列号计数器或实时时钟的稳定存储，则可以使用NTP从网络恢复实时时钟。一旦重启后时钟恢复，序列号生成程序将与上述程序相同。
Implementations SHOULD allow specification of interfaces that are to be secured, for either sending messages, or receiving them, or both. The sender must ensure that all RSVP messages sent on secured sending interfaces include an INTEGRITY object, generated using the appropriate Key. Receivers verify whether RSVP messages, except of the type "Integrity Challenge" (Section 4.3), arriving on a secured receiving interface contain the INTEGRITY object. If the INTEGRITY object is absent, the receiver discards the message.
实现应该允许指定要保护的接口，用于发送消息或接收消息，或两者兼而有之。发送方必须确保在安全发送接口上发送的所有RSVP消息都包含使用适当密钥生成的完整性对象。接收方验证到达安全接收接口的RSVP消息（类型“完整性质询”（第4.3节）除外）是否包含完整性对象。如果缺少完整性对象，则接收方将丢弃该消息。
Security associations are simplex - the keys that a sending system uses to sign its messages may be different from the keys that its receivers use to sign theirs. Hence, each association is associated with a unique sending system and (possibly) multiple receiving systems.
安全关联是单一的-发送系统用于对其消息进行签名的密钥可能不同于接收方用于对其消息进行签名的密钥。因此，每个关联与唯一的发送系统和（可能）多个接收系统相关联。
Each sender SHOULD have distinct security associations (and keys) per secured sending interface (or LIH). While administrators may configure all the routers and hosts on a subnet (or for that matter, in their network) using a single security association, implementations MUST assume that each sender may send using a distinct security association on each secured interface. At the sender, security association selection is based on the interface through which the message is sent. This selection MAY include additional criteria, such as the destination address (when sending the message unicast, over a broadcast LAN with a large number of hosts) or user identities at the sender or receivers [2]. Finally, all intended message recipients should participate in this security association. Route flaps in a non RSVP cloud might cause messages for the same receiver to be sent on different interfaces at different times. In such cases, the receivers should participate in all possible security associations that may be selected for the interfaces through which the message might be sent.
每个发送方应在每个安全发送接口（或LIH）上具有不同的安全关联（和密钥）。虽然管理员可以使用单个安全关联配置子网上（或在其网络中）的所有路由器和主机，但实现必须假定每个发送方可以在每个安全接口上使用不同的安全关联进行发送。在发送方，安全关联选择基于发送消息的接口。该选择可包括附加标准，例如目的地地址（当通过具有大量主机的广播LAN发送消息单播时）或发送方或接收方的用户身份[2]。最后，所有预期的邮件收件人都应参与此安全关联。非RSVP云中的路由活门可能会导致同一接收器的消息在不同的时间在不同的接口上发送。在这种情况下，接收方应参与所有可能的安全关联，这些关联可被选择用于发送消息的接口。
Receivers select keys based on the Key Identifier and the sending system's IP address. The Key Identifier is included in the INTEGRITY object. The sending system's address can be obtained either from the RSVP_HOP object, or if that's not present (as is the case with PathErr and ResvConf messages) from the IP source address. Since the Key Identifier is unique for a sender, this method uniquely identifies the key.
接收方根据密钥标识符和发送系统的IP地址选择密钥。密钥标识符包含在完整性对象中。发送系统的地址可以从RSVP_-HOP对象获取，或者如果不存在RSVP_-HOP对象（如PathErr和ResvConf消息），则可以从IP源地址获取。由于密钥标识符对于发送方是唯一的，因此此方法唯一地标识密钥。
The integrity mechanism slightly modifies the processing rules for RSVP messages, both when including the INTEGRITY object in a message sent over a secured sending interface and when accepting a message received on a secured receiving interface. These modifications are detailed below.
完整性机制在通过安全发送接口发送的消息中包含完整性对象时，以及在接受通过安全接收接口接收的消息时，都会略微修改RSVP消息的处理规则。下面详细介绍这些修改。
For an RSVP message sent over a secured sending interface, the message is created as described in [1], with these exceptions:
对于通过安全发送接口发送的RSVP消息，按照[1]中所述创建该消息，但以下例外情况除外：
(1) The RSVP checksum field is set to zero. If required, an RSVP checksum can be calculated when the processing of the INTEGRITY object is complete.
(1) RSVP校验和字段设置为零。如果需要，可以在完整性对象处理完成时计算RSVP校验和。
(2) The INTEGRITY object is inserted in the appropriate place, and its location in the message is remembered for later use.
(2) INTEGRITY对象将插入到适当的位置，并将记住其在消息中的位置，以供以后使用。
(3) The sending interface and other appropriate criteria (as mentioned above) are used to determine the Authentication Key and the hash algorithm to be used.
(3) 发送接口和其他适当标准（如上所述）用于确定要使用的认证密钥和散列算法。
(4) The unused flags and the reserved field in the INTEGRITY object MUST be set to 0. The Handshake Flag (HF) should be set according to rules specified in Section 2.1.
(4) 完整性对象中未使用的标志和保留字段必须设置为0。应根据第2.1节规定的规则设置握手标志（HF）。
(5) The sending sequence number MUST be updated to ensure a unique, monotonically increasing number. It is then placed in the Sequence Number field of the INTEGRITY object.
(5) 必须更新发送序列号，以确保序列号唯一且单调递增。然后将其放置在INTEGRITY对象的序列号字段中。
(6) The Keyed Message Digest field is set to zero.
(6) 键控消息摘要字段设置为零。
(7) The Key Identifier is placed into the INTEGRITY object.
(7) 密钥标识符放置在完整性对象中。
(8) An authenticating digest of the message is computed using the Authentication Key in conjunction with the keyed-hash algorithm. When the HMAC-MD5 algorithm is used, the hash calculation is described in [7].
(8) 消息的认证摘要是使用认证密钥和密钥哈希算法计算的。使用HMAC-MD5算法时，散列计算如[7]所述。
(9) The digest is written into the Cryptographic Digest field of the INTEGRITY object.
(9) 摘要将写入完整性对象的加密摘要字段。
When the message is received on a secured receiving interface, and is not of the type "Integrity Challenge", it is processed in the following manner:
当在安全接收接口上接收到消息且该消息不是“完整性质询”类型时，将按以下方式处理该消息：
(1) The RSVP checksum field is saved and the field is subsequently set to zero.
(1) 保存RSVP校验和字段，随后将该字段设置为零。
(2) The Cryptographic Digest field of the INTEGRITY object is saved and the field is subsequently set to zero.
(2) 完整性对象的Cryptographic Digest字段被保存，随后该字段被设置为零。
(3) The Key Identifier field and the sending system address are used to uniquely determine the Authentication Key and the hash algorithm to be used. Processing of this packet might be delayed when the Key Management System (Appendix 1) is queried for this information.
(3) 密钥标识符字段和发送系统地址用于唯一确定要使用的认证密钥和哈希算法。当向密钥管理系统（附录1）查询此信息时，此数据包的处理可能会延迟。
(4) A new keyed-digest is calculated using the indicated algorithm and the Authentication Key.
(4) 使用指定的算法和认证密钥计算新的密钥摘要。
(5) If the calculated digest does not match the received digest, the message is discarded without further processing.
(5) 如果计算的摘要与接收到的摘要不匹配，则消息将被丢弃，无需进一步处理。
(6) If the message is of type "Integrity Response", verify that the CHALLENGE object identically matches the originated challenge. If it matches, save the sequence number in the INTEGRITY object as the largest sequence number received to date.
(6) 如果消息类型为“完整性响应”，请验证质询对象是否与原始质询完全匹配。如果匹配，则将INTEGRITY对象中的序列号保存为迄今为止收到的最大序列号。
Otherwise, for all other RSVP Messages, the sequence number is validated to prevent replay attacks, and messages with invalid sequence numbers are ignored by the receiver.
否则，对于所有其他RSVP消息，将验证序列号以防止重播攻击，并且具有无效序列号的消息将被接收器忽略。
When a message is accepted, the sequence number of that message could update a stored value corresponding to the largest sequence number received to date. Each subsequent message must then have a larger (modulo 2^64) sequence number to be accepted. This simple processing rule prevents message replay attacks, but it must be modified to tolerate limited out-of-order message delivery. For example, if several messages were sent in a burst (in a periodic refresh generated by a router, or as a result of a tear down function), they might get reordered and then the sequence numbers would not be received in an increasing order.
当消息被接受时，该消息的序列号可以更新与迄今为止接收到的最大序列号相对应的存储值。随后的每条消息必须有一个更大的（模2^64）序列号才能被接受。此简单的处理规则可防止消息重播攻击，但必须对其进行修改，以允许有限的无序消息传递。例如，如果在一次突发中发送多条消息（在路由器生成的定期刷新中，或作为拆除功能的结果），它们可能会被重新排序，然后序列号将不会以递增的顺序接收。
An implementation SHOULD allow administrative configuration that sets the receiver's tolerance to out-of-order message delivery. A simple approach would allow administrators to specify a message window corresponding to the worst case reordering behavior. For example, one might specify that packets reordered within a 32 message window would be accepted. If no reordering can occur, the window is set to one.
一个实现应该允许管理配置来设置接收方对无序消息传递的容忍度。一种简单的方法将允许管理员指定与最坏情况下的重新排序行为相对应的消息窗口。例如，可以指定接受在32消息窗口内重新排序的数据包。如果无法进行重新排序，则窗口将设置为1。
The receiver must store a list of all sequence numbers seen within the reordering window. A received sequence number is valid if (a) it is greater than the maximum sequence number received or (b) it is a past sequence number lying within the reordering window and not recorded in the list. Acceptance of
接收方必须存储在重新排序窗口中看到的所有序列号的列表。如果（A）接收到的序列号大于接收到的最大序列号或（b）它是位于重新排序窗口内且未记录在列表中的过去序列号，则接收到的序列号有效。接受
a sequence number implies adding it to the list and removing a number from the lower end of the list. Messages received with sequence numbers lying below the lower end of the list or marked seen in the list are discarded.
序列号意味着将其添加到列表中，并从列表的下端删除一个数字。接收到的序列号位于列表下端下方或在列表中标记为seen的消息将被丢弃。
When an "Integrity Challenge" message is received on a secured sending interface it is processed in the following manner:
当在安全发送接口上接收到“完整性质询”消息时，将按照以下方式处理该消息：
(1) An "Integrity Response" message is formed using the Challenge object received in the challenge message.
(1) 使用质询消息中接收的质询对象形成“完整性响应”消息。
(2) The message is sent back to the receiver, based on the source IP address of the challenge message, using the "Message Generation" steps outlined above. The selection of the Authentication Key and the hash algorithm to be used is determined by the key identifier supplied in the challenge message.
(2) 根据质询消息的源IP地址，使用上述“消息生成”步骤将消息发送回接收器。要使用的认证密钥和散列算法的选择由质询消息中提供的密钥标识符确定。
To obtain the starting sequence number for a live Authentication Key, the receiver MAY initiate an integrity handshake with the sender. This handshake consists of a receiver's Challenge and the sender's Response, and may be either initiated during restart or postponed until a message signed with that key arrives.
为了获得实时认证密钥的起始序列号，接收方可以发起与发送方的完整性握手。此握手由接收方的质询和发送方的响应组成，可以在重启期间启动，也可以推迟，直到用该密钥签名的消息到达。
Once the receiver has decided to initiate an integrity handshake for a particular Authentication Key, it identifies the sender using the sending system's address configured in the corresponding security association. The receiver then sends an RSVP Integrity Challenge message to the sender. This message contains the Key Identifier to identify the sender's key and MUST have a unique challenge cookie that is based on a local secret to prevent guessing. see Section 2.5.3 of [4]). It is suggested that the cookie be an MD5 hash of a local secret and a timestamp to provide uniqueness (see Section 9).
一旦接收方决定启动特定身份验证密钥的完整性握手，它将使用相应安全关联中配置的发送系统地址来识别发送方。然后，接收方向发送方发送RSVP完整性质询消息。此消息包含用于标识发件人密钥的密钥标识符，并且必须具有基于本地机密的唯一质询cookie，以防止猜测。见[4]第2.5.3节。建议cookie是本地秘密的MD5散列和时间戳，以提供唯一性（参见第9节）。
An RSVP Integrity Challenge message will carry a message type of 11. The message format is as follows:
RSVP完整性质询消息的消息类型为11。电文格式如下：
<Integrity Challenge message> ::= <Common Header> <CHALLENGE>
<Integrity Challenge message> ::= <Common Header> <CHALLENGE>
he CHALLENGE object has the following format:
质询对象具有以下格式：
CHALLENGE Object: Class = 64, C-Type = 1
CHALLENGE Object: Class = 64, C-Type = 1
+-------------+-------------+-------------+-------------+
| 0 (Reserved) | |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Challenge Cookie |
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| 0 (Reserved) | |
+-------------+-------------+ +
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Challenge Cookie |
| |
+-------------+-------------+-------------+-------------+
The sender accepts the "Integrity Challenge" without doing an integrity check. It returns an RSVP "Integrity Response" message that contains the original CHALLENGE object. It also includes an INTEGRITY object, signed with the key specified by the Key Identifier included in the "Integrity Challenge".
发送方接受“完整性质询”，而不进行完整性检查。它返回包含原始质询对象的RSVP“Integrity Response”消息。它还包括一个完整性对象，使用“完整性质询”中包含的密钥标识符指定的密钥进行签名。
An RSVP Integrity Response message will carry a message type of 12. The message format is as follows:
RSVP完整性响应消息的消息类型为12。电文格式如下：
<Integrity Response message> ::= <Common Header> <INTEGRITY>
<CHALLENGE>
<Integrity Response message> ::= <Common Header> <INTEGRITY>
<CHALLENGE>
The "Integrity Response" message is accepted by the receiver (challenger) only if the returned CHALLENGE object matches the one sent in the "Integrity Challenge" message. This prevents replay of old "Integrity Response" messages. If the match is successful, the receiver saves the Sequence Number from the INTEGRITY object as the latest sequence number received with the key identifier included in the CHALLENGE.
只有当返回的质询对象与“完整性质询”消息中发送的对象匹配时，接收方（质询者）才会接受“完整性响应”消息。这将防止重播旧的“完整性响应”消息。如果匹配成功，则接收方将来自INTEGRITY对象的序列号保存为使用质询中包含的密钥标识符接收的最新序列号。
If a response is not received within a given period of time, the challenge is repeated. When the integrity handshake successfully completes, the receiver begins accepting normal RSVP signaling messages from that sender and ignores any other "Integrity Response" messages.
如果在给定时间段内未收到响应，则重复质询。当完整性握手成功完成时，接收方开始接受来自该发送方的正常RSVP信令消息，并忽略任何其他“完整性响应”消息。
The Handshake Flag (HF) is used to allow implementations the flexibility of not including the integrity handshake mechanism. By setting this flag to 1, message senders that implement the integrity handshake distinguish themselves from those that do not. Receivers SHOULD NOT attempt to handshake with senders whose INTEGRITY object has HF = 0.
握手标志（HF）用于允许实现不包括完整性握手机制的灵活性。通过将此标志设置为1，实现完整性握手的消息发送者将自己与未实现完整性握手的消息发送者区分开来。接收方不应尝试与完整性对象HF=0的发送方握手。
An integrity handshake may not be necessary in all environments. A common use of RSVP integrity will be between peering domain routers, which are likely to be processing a steady stream of RSVP messages due to aggregation effects. When a router restarts after a crash, valid RSVP messages from peering senders will probably arrive within a short time. Assuming that replay messages are injected into the stream of valid RSVP messages, there may be only a small window of opportunity for a replay attack before a valid message is processed. This valid message will set the largest sequence number seen to a value greater than any number that had been stored prior to the crash, preventing any further replays.
完整性握手可能并非在所有环境中都是必需的。RSVP完整性的常见用途是在对等域路由器之间使用，由于聚合效应，这些路由器可能正在处理稳定的RSVP消息流。当路由器在崩溃后重新启动时，来自对等发送方的有效RSVP消息可能会在短时间内到达。假设将重播消息注入到有效RSVP消息流中，则在处理有效消息之前，可能只有很小的重播攻击机会。此有效消息将看到的最大序列号设置为大于崩溃前存储的任何数字的值，从而防止任何进一步的重播。
On the other hand, not using an integrity handshake could allow exposure to replay attacks if there is a long period of silence from a given sender following a restart of a receiver. Hence, it SHOULD be an administrative decision whether or not the receiver performs an integrity handshake with senders that are willing to respond to "Integrity Challenge" messages, and whether it accepts any messages from senders that refuse to do so. These decisions will be based on assumptions related to a particular network environment.
另一方面，如果在接收器重新启动后，给定发送方长时间保持沉默，则不使用完整性握手可能会导致重播攻击。因此，接收方是否与愿意响应“完整性质询”消息的发送方进行完整性握手，以及是否接受来自拒绝这样做的发送方的任何消息，应该是一项管理决策。这些决策将基于与特定网络环境相关的假设。
It is likely that the IETF will define a standard key management protocol. It is strongly desirable to use that key management protocol to distribute RSVP Authentication Keys among communicating RSVP implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key Identifier can be used as a hook between RSVP and such a future protocol. 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 RSVP implementations should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification.
IETF可能会定义一个标准的密钥管理协议。强烈希望使用该密钥管理协议在通信的RSVP实现之间分发RSVP认证密钥。这样一个协议将提供可伸缩性，并显著减少人力管理负担。密钥标识符可以用作RSVP和这样的未来协议之间的挂钩。密钥管理协议有着很长的历史，在协议首次公开后很长一段时间，人们就发现了这些微妙的缺陷。为了避免在发现此类缺陷时必须更改所有RSVP实现，本规范中故意省略了集成密钥管理协议技术。
Each key has a lifetime associated with it that is recorded in all systems (sender and receivers) configured with that key. The concept of a "key lifetime" merely requires that the earliest (KeyStartValid) and latest (KeyEndValid) times that the key is valid be programmable in a way the system understands. Certain key generation mechanisms, such as Kerberos or some public key schemes, may directly produce ephemeral keys. In this case, the lifetime of the key is implicitly defined as part of the key.
每个密钥都有一个与其相关联的生存期，该生存期记录在使用该密钥配置的所有系统（发送方和接收方）中。“密钥生命周期”的概念仅要求密钥有效的最早（KeyStartValid）和最晚（KeyEndValid）时间可以按照系统理解的方式进行编程。某些密钥生成机制（如Kerberos或某些公钥方案）可能直接生成临时密钥。在这种情况下，密钥的生存期被隐式定义为密钥的一部分。
In general, no key is ever used outside its lifetime (but see Section 5.3). Possible mechanisms for managing key lifetime include the Network Time Protocol and hardware time-of-day clocks.
一般来说，在其使用寿命之外，不会使用任何密钥（但请参见第5.3节）。管理密钥生存期的可能机制包括网络时间协议和硬件时钟。
To maintain security, it is advisable to change the RSVP Authentication Key on a regular basis. It should be possible to switch the RSVP Authentication Key without loss of RSVP state or denial of reservation service, and without requiring people to change all the keys at once. This requires an RSVP implementation to support the storage and use of more than one active RSVP Authentication Key at the same time. Hence both the sender and receivers might have multiple active keys for a given security association.
为了维护安全性，建议定期更改RSVP身份验证密钥。应该能够在不丢失RSVP状态或拒绝保留服务的情况下切换RSVP身份验证密钥，并且不要求人们立即更改所有密钥。这需要RSVP实现来支持同时存储和使用多个活动RSVP身份验证密钥。因此，对于给定的安全关联，发送方和接收方可能都有多个活动密钥。
Since keys are shared between a sender and (possibly) multiple receivers, there is a region of uncertainty around the time of key switch-over during which some systems may still be using the old key and others might have switched to the new key. The size of this uncertainty region is related to clock synchrony of the systems. Administrators should configure the overlap between the expiration time of the old key (KeyEndValid) and the validity of the new key (KeyStartValid) to be at least twice the size of this uncertainty interval. This will allow the sender to make the key switch-over at the midpoint of this interval and be confident that all receivers are now accepting the new key. For the duration of the overlap in key lifetimes, a receiver must be prepared to authenticate messages using either key.
由于密钥在发送方和（可能）多个接收方之间共享，因此在密钥切换期间存在一个不确定区域，在此期间，一些系统可能仍在使用旧密钥，而其他系统可能已切换到新密钥。这个不确定区域的大小与系统的时钟同步性有关。管理员应将旧密钥（KeyEndValid）的过期时间与新密钥（KeyStartValid）的有效时间之间的重叠配置为至少两倍于此不确定性间隔的大小。这将允许发送方在此间隔的中点进行钥匙切换，并确保所有接收方现在都接受新钥匙。在密钥生命周期的重叠期间，接收方必须准备好使用任一密钥对消息进行身份验证。
During a key switch-over, it will be necessary for each receiver to handshake with the sender using the new key. As stated before, a receiver has the choice of initiating a handshake during the switchover or postponing the handshake until the receipt of a message using that key.
在钥匙切换过程中，每个接收者都必须使用新钥匙与发送者握手。如前所述，接收方可以选择在切换期间发起握手，或者推迟握手，直到使用该键接收到消息为止。
Requirements on an implementation are as follows:
实施要求如下：
o 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 stored using protocols or algorithms that have known flaws.
o 强烈希望一个互联网协议中假设的安全漏洞不会自动危及其他互联网协议。本规范的认证密钥不应使用具有已知缺陷的协议或算法存储。
o An implementation MUST support the storage and use of more than one key at the same time, for both sending and receiving systems.
o 对于发送和接收系统，实现必须支持同时存储和使用多个密钥。
o An implementation MUST associate a specific lifetime (i.e., KeyStartValid and KeyEndValid) with each key and the corresponding Key Identifier.
o 实现必须将特定的生存期（即KeyStartValid和KeyEndValid）与每个密钥和相应的密钥标识符相关联。
o An implementation MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the console). The lifetime may be infinite.
o 实现必须支持手动密钥分发（例如，特权用户在控制台上手动键入密钥、密钥生存期和密钥标识符）。生命可能是无限的。
o If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered.
o 如果支持多个算法，则实现必须要求在输入其他密钥信息时为每个密钥指定算法。
o Keys that are out of date MAY be automatically deleted by the implementation.
o 过期的密钥可能会被实现自动删除。
o Manual deletion of active keys MUST also be supported.
o 还必须支持手动删除活动密钥。
o Key storage SHOULD persist across a system restart, warm or cold, to ease operational usage.
o 密钥存储应在系统重新启动期间（无论是热重启还是冷重启）保持不变，以便于操作使用。
It is possible that the last key for a given security association has expired. When this happens, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt current reservations. Therefore, the system 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.
给定安全关联的最后一个密钥可能已过期。当这种情况发生时，恢复到未经验证的状态是不可接受的，并且不建议中断当前的保留。因此，系统应向网络管理器发送“上次身份验证密钥到期”通知，并将密钥视为具有无限生存期，直到延长生存期、通过网络管理删除密钥或配置新密钥为止。
To conform to this specification, an implementation MUST support all of its aspects. The HMAC-MD5 authentication algorithm defined in [7] MUST be implemented by all conforming implementations. A conforming implementation MAY also support other authentication algorithms such as NIST's Secure Hash Algorithm (SHA). Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key roll over described under "Key Management Procedures."
要符合此规范，实现必须支持其所有方面。[7]中定义的HMAC-MD5认证算法必须由所有符合要求的实现实现。一致性实现还可以支持其他认证算法，如NIST的安全哈希算法（SHA）。如上所述的手动密钥分发必须得到所有一致性实施的支持。所有实施必须支持“密钥管理程序”中所述的平滑密钥移交
Implementations SHOULD support a standard key management protocol for secure distribution of RSVP Authentication Keys once such a key management protocol is standardized by the IETF.
一旦此类密钥管理协议被IETF标准化，实施应支持用于RSVP认证密钥安全分发的标准密钥管理协议。
Kerberos[10] MAY be used to generate the RSVP Authentication key used in generating a signature in the Integrity Object sent from a RSVP sender to a receiver. Kerberos key generation avoids the use of shared keys between RSVP senders and receivers such as hosts and routers. Kerberos allows for the use of trusted third party keying relationships between security principals (RSVP sender and receivers) where the Kerberos key distribution center(KDC) establishes an ephemeral session key that is subsequently shared between RSVP sender and receivers. In the multicast case all receivers of a multicast RSVP message MUST share a single key with the KDC (e.g. the receivers are in effect the same security principal with respect to Kerberos).
Kerberos[10]可用于生成RSVP身份验证密钥，该密钥用于在从RSVP发送方发送到接收方的完整性对象中生成签名。Kerberos密钥生成避免在RSVP发送方和接收方（如主机和路由器）之间使用共享密钥。Kerberos允许在安全主体（RSVP发送方和接收方）之间使用受信任的第三方密钥关系，其中Kerberos密钥分发中心（KDC）建立临时会话密钥，该密钥随后在RSVP发送方和接收方之间共享。在多播情况下，多播RSVP消息的所有接收者必须与KDC共享一个密钥（例如，接收者实际上与Kerberos具有相同的安全主体）。
The Key information determined by the sender MAY specify the use of Kerberos in place of configured shared keys as the mechanism for establishing a key between the sender and receiver. The Kerberos identity of the receiver is established as part of the sender's interface configuration or it can be established through other mechanisms. When generating the first RSVP message for a specific key identifier the sender requests a Kerberos service ticket and gets back an ephemeral session key and a Kerberos ticket from the KDC. The sender encapsulates the ticket and the identity of the sender in an Identity Policy Object[2]. The sender includes the Policy Object in the RSVP message. The session key is then used by the sender as the RSVP Authentication key in section 4.1 step (3) and is stored as Key information associated with the key identifier.
发送方确定的密钥信息可以指定使用Kerberos代替配置的共享密钥，作为在发送方和接收方之间建立密钥的机制。接收方的Kerberos标识作为发送方接口配置的一部分建立，也可以通过其他机制建立。当为特定密钥标识符生成第一条RSVP消息时，发送方请求Kerberos服务票证，并从KDC返回临时会话密钥和Kerberos票证。发件人将票据和发件人的身份封装在身份策略对象[2]中。发件人在RSVP消息中包含策略对象。然后，发送方将会话密钥用作第4.1节步骤（3）中的RSVP身份验证密钥，并将其存储为与密钥标识符相关联的密钥信息。
Upon RSVP Message reception, the receiver retrieves the Kerberos Ticket from the Identity Policy Object, decrypts the ticket and retrieves the session key from the ticket. The session key is the same key as used by the sender and is used as the key in section 4.2 step (3). The receiver stores the key for use in processing subsequent RSVP messages.
接收到RSVP消息后，接收方从标识策略对象检索Kerberos票证，解密票证并从票证检索会话密钥。会话密钥与发送方使用的密钥相同，并用作第4.2节步骤（3）中的密钥。接收方存储密钥以用于处理后续RSVP消息。
Kerberos tickets have lifetimes and the sender MUST NOT use tickets that have expired. A new ticket MUST be requested and used by the sender for the receiver prior to the ticket expiring.
Kerberos票证具有生存期，发件人不得使用已过期的票证。在票据到期之前，发送方必须为接收方申请并使用新票据。
Kerberos tickets are relatively long (> 500 bytes) and it is not necessary to send a ticket in every RSVP message. The ephemeral session key can be cached by the sender and receiver and can be used for the lifetime of the Kerberos ticket. In this case, the sender only needs to include the Kerberos ticket in the first Message generated. Subsequent RSVP messages use the key identifier to
Kerberos票证相对较长（>500字节），不需要在每个RSVP消息中发送票证。临时会话密钥可由发送方和接收方缓存，并可在Kerberos票证的生存期内使用。在这种情况下，发送方只需要在生成的第一条消息中包含Kerberos票证。后续RSVP消息使用密钥标识符
retrieve the cached key (and optionally other identity information) instead of passing tickets from sender to receiver in each RSVP message.
检索缓存的密钥（以及可选的其他身份信息），而不是在每个RSVP消息中从发送方向接收方传递票据。
A receiver may not have cached key state with an associated Key Identifier due to reboot or route changes. If the receiver's policy indicates the use of Kerberos keys for integrity checking, the receiver can send an integrity Challenge message back to the sender. Upon receiving an integrity Challenge message a sender MUST send an Identity object that includes the Kerberos ticket in the integrity Response message, thereby allowing the receiver to retrieve and store the session key from the Kerberos ticket for subsequent Integrity checking.
由于重新启动或路由更改，接收器可能没有具有关联密钥标识符的缓存密钥状态。如果接收方的策略指示使用Kerberos密钥进行完整性检查，则接收方可以将完整性质询消息发送回发送方。在收到完整性质询消息后，发送方必须发送一个身份对象，该对象在完整性响应消息中包含Kerberos票证，从而允许接收方从Kerberos票证中检索和存储会话密钥，以进行后续的完整性检查。
This document is derived directly from similar work done for OSPF and RIP Version II, jointly by Ran Atkinson and Fred Baker. Significant editing was done by Bob Braden, resulting in increased clarity. Significant comments were submitted by Steve Bellovin, who actually understands this stuff. Matt Crawford and Dan Harkins helped revise the document.
本文件直接源自Ran Atkinson和Fred Baker为OSPF和RIP版本II所做的类似工作。Bob Braden进行了重要的编辑，提高了清晰度。史蒂夫·贝洛文（Steve Bellovin）提交了重要的评论，他实际上理解这些东西。马特·克劳福德和丹·哈金斯帮助修改了文件。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[2] Yadav, S., et al., "Identity Representation for RSVP", RFC 2752, January 2000.
[2] Yadav，S.等人，“RSVP的身份表示”，RFC 2752，2000年1月。
[3] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[4] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[4] Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[7] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1996.
[7] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1996年3月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9] 《传输控制协议》，标准7，RFC 793，1981年9月。
[10] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[10] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
This entire memo describes and specifies an authentication mechanism for RSVP that is believed to be secure against active and passive attacks.
整个备忘录描述并指定了RSVP的身份验证机制，该机制被认为是针对主动和被动攻击的安全机制。
The quality of the security provided by this mechanism depends 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 RSVP implementations. This mechanism also depends on the RSVP Authentication Keys being kept confidential by all parties. If any of these assumptions are incorrect or procedures are insufficiently secure, then no real security will be provided to the users of this mechanism.
该机制提供的安全性质量取决于所实现的身份验证算法的强度、所使用密钥的强度以及所有通信RSVP实现中安全机制的正确实现。该机制还取决于各方对RSVP身份验证密钥保密。如果这些假设中的任何一个是不正确的，或者程序不够安全，那么就不会为该机制的用户提供真正的安全性。
While the handshake "Integrity Response" message is integrity-checked, the handshake "Integrity Challenge" message is not. This was done intentionally to avoid the case when both peering routers do not have a starting sequence number for each other's key. Consequently, they will each keep sending handshake "Integrity Challenge" messages that will be dropped by the other end. Moreover, requiring only the response to be integrity-checked eliminates a dependency on an security association in the opposite direction.
虽然握手“完整性响应”消息已进行完整性检查，但握手“完整性挑战”消息未进行完整性检查。这样做是为了避免两个对等路由器彼此的密钥都没有起始序列号的情况。因此，它们将各自继续发送握手“完整性挑战”消息，该消息将被另一端丢弃。此外，只需要检查响应的完整性就可以消除对相反方向的安全关联的依赖。
This, however, lets an intruder generate fake handshaking challenges with a certain challenge cookie. It could then save the response and attempt to play it against a receiver that is in recovery. If it was lucky enough to have guessed the challenge cookie used by the receiver at recovery time it could use the saved response. This response would be accepted, since it is properly signed, and would have a smaller sequence number for the sender because it was an old message. This opens the receiver up to replays. Still, it seems very difficult to exploit. It requires not only guessing the challenge cookie (which is based on a locally known secret) in advance, but also being able to masquerade as the receiver to generate a handshake "Integrity Challenge" with the proper IP address and not being caught.
然而，这使得入侵者可以使用某个挑战cookie生成假握手挑战。然后，它可以保存响应并尝试对正在恢复的接收器播放。如果它足够幸运地猜到了接收者在恢复时使用的挑战cookie，那么它可以使用保存的响应。此响应将被接受，因为它已正确签名，并且发件人的序列号将更小，因为它是一封旧邮件。这将打开接收器进行重播。尽管如此，它似乎很难利用。它不仅需要预先猜测质询cookie（基于本地已知的秘密），还需要能够伪装成接收方，以生成具有正确IP地址的握手“完整性质询”，并且不会被捕获。
Confidentiality is not provided by this mechanism. If confidentiality is required, IPSEC ESP [6] may be the best approach, although it is subject to the same criticisms as IPSEC Authentication, and therefore would be applicable only in specific environments. Protection against traffic analysis is also not provided. Mechanisms such as bulk link encryption might be used when protection against traffic analysis is required.
此机制不提供机密性。如果需要保密，IPSEC ESP[6]可能是最好的方法，尽管它受到与IPSEC身份验证相同的批评，因此仅适用于特定环境。还未提供针对流量分析的保护。当需要针对流量分析进行保护时，可以使用诸如批量链接加密之类的机制。
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
弗雷德·贝克思科系统公司，加利福尼亚州圣巴巴拉市拉多大道519号，邮编：93111
Phone: (408) 526-4257 EMail: fred@cisco.com
电话：（408）526-4257电子邮件：fred@cisco.com
Bob Lindell USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Bob Lindell USC信息科学研究所4676金钟路Marina del Rey，加利福尼亚州90292
Phone: (310) 822-1511 EMail: lindell@ISI.EDU
电话：（310）822-1511电子邮件：lindell@ISI.EDU
Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052
Mohit Talwar微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
This appendix describes a generic interface to Key Management. This description is at an abstract level realizing that implementations may need to introduce small variations to the actual interface.
本附录描述了密钥管理的通用接口。这个描述是在抽象的层次上实现的，实现可能需要对实际接口引入一些小的变化。
At the start of execution, RSVP would use this interface to obtain the current set of relevant keys for sending and receiving messages. During execution, RSVP can query for specific keys given a Key Identifier and Source Address, discover newly created keys, and be informed of those keys that have been deleted. The interface provides both a polling and asynchronous upcall style for wider applicability.
在执行开始时，RSVP将使用此接口获取用于发送和接收消息的当前相关密钥集。在执行过程中，RSVP可以查询给定密钥标识符和源地址的特定密钥，发现新创建的密钥，并通知已删除的密钥。该接口提供轮询和异步向上调用样式，以实现更广泛的适用性。
Information about keys is returned using the following KeyInfo data structure:
使用以下KeyInfo数据结构返回有关密钥的信息：
KeyInfo {
Key Type (Send or Receive)
KeyIdentifier
Key
Authentication Algorithm Type and Mode
KeyStartValid
KeyEndValid
Status (Active or Deleted)
Outgoing Interface (for Send only)
Other Outgoing Security Association Selection Criteria
(for Send only, optional)
Sending System Address (for Receive Only)
}
KeyInfo {
Key Type (Send or Receive)
KeyIdentifier
Key
Authentication Algorithm Type and Mode
KeyStartValid
KeyEndValid
Status (Active or Deleted)
Outgoing Interface (for Send only)
Other Outgoing Security Association Selection Criteria
(for Send only, optional)
Sending System Address (for Receive Only)
}
This function returns a list of KeyInfo data structures corresponding to all of the keys that are configured for sending and receiving RSVP messages and have an Active Status. This function is usually called at the start of execution but there is no limit on the number of times that it may be called.
此函数返回与配置用于发送和接收RSVP消息且处于活动状态的所有密钥相对应的KeyInfo数据结构列表。此函数通常在执行开始时调用，但调用次数没有限制。
KM_DefaultKeyTable() -> KeyInfoList
KM_DefaultKeyTable() -> KeyInfoList
When a message arrives with an unknown Key Identifier and Sending System Address pair, RSVP can use this function to query the Key Management System for the appropriate key. The status of the element returned, if any, must be Active.
当消息到达时带有未知的密钥标识符和发送系统地址对，RSVP可以使用此功能向密钥管理系统查询适当的密钥。返回的元素的状态（如果有）必须为活动状态。
KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo
KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo
This function returns a list of KeyInfo data structures corresponding to any incremental changes that have been made to the default key table or requested keys since the last call to either KM_KeyTablePoll, KM_DefaultKeyTable, or KM_GetRecvKey. The status of some elements in the returned list may be set to Deleted.
This function returns a list of KeyInfo data structures corresponding to any incremental changes that have been made to the default key table or requested keys since the last call to either KM_KeyTablePoll, KM_DefaultKeyTable, or KM_GetRecvKey. The status of some elements in the returned list may be set to Deleted.translate error, please retry
KM_KeyTablePoll() -> KeyInfoList
KM_KeyTablePoll() -> KeyInfoList
Rather than repeatedly calling the KM_KeyTablePoll(), an implementation may choose to use an asynchronous event model. This function registers interest to key changes for a given Key Identifier or for all keys if no Key Identifier is specified. The upcall function is called each time a change is made to a key.
实现可以选择使用异步事件模型，而不是重复调用KM_KeyTablePoll（）。此函数用于注册对给定密钥标识符或所有密钥（如果未指定密钥标识符）的密钥更改的兴趣。每次更改密钥时都会调用upcall函数。
KM_KeyUpdate ( Function [, KeyIdentifier ] )
KM_密钥更新（函数[，密钥标识符]）
where the upcall function is parameterized as follows:
其中，upcall函数参数化如下：
Function ( KeyInfo )
功能（KeyInfo）
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。