Network Working Group H. Tschofenig
Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
Network Working Group H. Tschofenig
Request for Comments: 4230 Siemens
Category: Informational R. Graveman
RFG Security
December 2005
RSVP Security Properties
RSVP安全属性
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.
本文档总结了RSVP的安全属性。本分析的目的是从之前对RSVP所做的工作中获益，并获取关于过去活动的知识。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . 41
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
C. Literature on RSVP Security . . . . . . . . . . . . . . . . 46
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Architectural Assumptions . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The RSVP INTEGRITY Object . . . . . . . . . . . . . . 5
3.2. Security Associations . . . . . . . . . . . . . . . . 8
3.3. RSVP Key Management Assumptions . . . . . . . . . . . 8
3.4. Identity Representation . . . . . . . . . . . . . . . 9
3.5. RSVP Integrity Handshake . . . . . . . . . . . . . . 13
4. Detailed Security Property Discussion . . . . . . . . . . . 15
4.1. Network Topology . . . . . . . . . . . . . . . . . . 15
4.2. Host/Router . . . . . . . . . . . . . . . . . . . . . 15
4.3. User to PEP/PDP . . . . . . . . . . . . . . . . . . . 19
4.4. Communication between RSVP-Aware Routers . . . . . . . 28
5. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 29
5.1. First-Hop Issue . . . . . . . . . . . . . . . . . . . 30
5.2. Next-Hop Problem . . . . . . . . . . . . . . . . . . . 30
5.3. Last-Hop Issue . . . . . . . . . . . . . . . . . . . 33
5.4. RSVP- and IPsec-protected data traffic . . . . . . . . 34
5.5. End-to-End Security Issues and RSVP . . . . . . . . . 36
5.6. IPsec protection of RSVP signaling messages . . . . . 36
5.7. Authorization . . . . . . . . . . . . . . . . . . . . 37
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . 41
A. Dictionary Attacks and Kerberos . . . . . . . . . . . . . . 45
B. Example of User-to-PDP Authentication . . . . . . . . . . . 45
C. Literature on RSVP Security . . . . . . . . . . . . . . . . 46
As the work of the NSIS working group began, concerns about security and its implications for the design of a signaling protocol were raised. In order to understand the security properties and available options of RSVP, a number of documents have to be read. This document summarizes the security properties of RSVP and is part of the overall process of analyzing other signaling protocols and learning from their design considerations. This document should also provide a starting point for further discussions.
随着NSIS工作组的工作开始，人们开始关注安全性及其对信令协议设计的影响。为了了解RSVP的安全属性和可用选项，必须阅读大量文档。本文档总结了RSVP的安全特性，是分析其他信令协议并从其设计考虑中学习的整个过程的一部分。本文件还应为进一步讨论提供一个起点。
The content of this document is organized as follows. Section 2 introduces the terminology used throughout the document. Section 3 provides an overview of the security mechanisms provided by RSVP including the INTEGRITY object, a description of the identity representation within the POLICY_DATA object (i.e., user authentication), and the RSVP Integrity Handshake mechanism. Section 4 provides a more detailed discussion of the mechanisms used and tries to describe in detail the mechanisms provided. Several miscellaneous issues are covered in Section 5.
本文件的内容组织如下。第2节介绍了本文件中使用的术语。第3节概述了RSVP提供的安全机制，包括完整性对象、POLICY_数据对象中身份表示的描述（即用户身份验证）以及RSVP完整性握手机制。第4节对所使用的机制进行了更详细的讨论，并试图详细描述所提供的机制。第5节涵盖了几个杂项问题。
RSVP also supports multicast, but this document does not address security aspects for supporting multicast QoS signaling. Multicast is currently outside the scope of the NSIS working group.
RSVP也支持多播，但本文档不涉及支持多播QoS信令的安全方面。多播目前不属于NSIS工作组的范围。
Although a variation of RSVP, namely RSVP-TE, is used in the context of MPLS to distribute labels for a label switched path, its usage is different from the usage scenarios envisioned for NSIS. Hence, this document does not address RSVP-TE or its security properties.
尽管在MPLS的上下文中使用RSVP的变体，即RSVP-TE来为标签交换路径分发标签，但其使用与NSIS设想的使用场景不同。因此，本文档不涉及RSVP-TE或其安全属性。
This section describes some important terms and explains some architectural assumptions.
本节介绍一些重要术语，并解释一些架构假设。
o Chain-of-Trust:
o 信任链：
The security mechanisms supported by RSVP [1] heavily rely on optional hop-by-hop protection, using the built-in INTEGRITY object. Hop-by-hop security with the INTEGRITY object inside the RSVP message thereby refers to the protection between RSVP-supporting network elements. Additionally, there is the notion of policy-aware nodes that understand the POLICY_DATA element within the RSVP message. Because this element also includes an INTEGRITY object, there is an additional hop-by-hop security mechanism that provides security between policy-aware nodes. Policy-ignorant nodes are not affected by the inclusion of this object in the POLICY_DATA element, because they do not try to interpret it.
RSVP[1]支持的安全机制严重依赖于使用内置完整性对象的可选逐跳保护。因此，RSVP消息中包含完整性对象的逐跳安全性是指支持RSVP的网络元素之间的保护。此外，还有策略感知节点的概念，可以理解RSVP消息中的策略_数据元素。由于此元素还包括一个INTEGRITY对象，因此还有一个额外的逐跳安全机制，可在策略感知节点之间提供安全性。策略无关节点不受策略_数据元素中包含此对象的影响，因为它们不会尝试对其进行解释。
To protect signaling messages that are possibly modified by each RSVP router along the path, it must be assumed that each incoming request is authenticated, integrity protected, and replay protected. This provides protection against bogus messages injected by unauthorized nodes. Furthermore, each RSVP-aware router is assumed to behave in the expected manner. Outgoing messages transmitted to the next-hop network element receive new protection according to RSVP security processing.
为了保护可能被路径上的每个RSVP路由器修改的信令消息，必须假设每个传入请求都经过身份验证、完整性保护和重播保护。这可以防止未经授权的节点注入虚假消息。此外，假设每个RSVP感知路由器以预期的方式运行。发送到下一跳网元的传出消息根据RSVP安全处理接收新的保护。
Using the mechanisms described above, a chain-of-trust is created whereby a signaling message that is transmitted by router A via router B and received by router C is supposed to be secure if routers A and B and routers B and C share security associations and all routers behave as expected. Hence, router C trusts router A although router C does not have a direct security association with router A. We can therefore conclude that the protection achieved with this hop-by-hop security for the chain-of-trust is no better than the weakest link in the chain.
使用上述机制，创建信任链，由此，如果路由器a和B以及路由器B和C共享安全关联并且所有路由器按照预期行为，则由路由器a经由路由器B发送并由路由器C接收的信令消息被认为是安全的。因此，路由器C信任路由器A，尽管路由器C与路由器A没有直接的安全关联。因此，我们可以得出结论，通过这种逐跳安全性为信任链提供的保护并不比链中最薄弱的环节更好。
If one router is malicious (for example, because an adversary has control over this router), then it can arbitrarily modify messages, cause unexpected behavior, and mount a number of attacks that are not limited to QoS signaling. Additionally, it must be mentioned that some protocols demand more protection than others (which depends, in part, on which nodes are executing these protocols). For example, edge devices, where end-users are attached, may be more likely to be attacked in comparison with the more secure core network of a service provider. In some cases, a network service provider may choose not to use the RSVP-provided security mechanisms inside the core network because a different security protection is deployed.
如果一个路由器是恶意的（例如，因为对手控制了该路由器），那么它可以任意修改消息，导致意外行为，并发起大量不限于QoS信令的攻击。此外，必须提到的是，某些协议需要比其他协议更多的保护（这部分取决于哪些节点正在执行这些协议）。例如，与服务提供商的更安全的核心网络相比，连接最终用户的边缘设备可能更容易受到攻击。在某些情况下，网络服务提供商可能会选择不在核心网络内使用RSVP提供的安全机制，因为部署了不同的安全保护。
Section 6 of [2] mentions the term chain-of-trust in the context of RSVP integrity protection. In Section 6 of [14] the same term is used in the context of user authentication with the INTEGRITY object inside the POLICY_DATA element. Unfortunately, the term is not explained in detail and the assumptions behind it are not clearly specified.
[2]第6节提到了RSVP完整性保护上下文中的信任链这一术语。在[14]的第6节中，在用户身份验证的上下文中使用了相同的术语，其中完整性对象位于POLICY_数据元素中。不幸的是，该术语没有详细解释，其背后的假设也没有明确规定。
o Host and User Authentication:
o 主机和用户身份验证：
The presence of RSVP protection and a separate user identity representation leads to the fact that both user-identity and host-identity are used for RSVP protection. Therefore, user-based security and host-based security are covered separately, because of the different authentication mechanisms provided. To avoid confusion about the different concepts, Section 3.4 describes the concept of user authentication in more detail.
RSVP保护和单独的用户标识表示的存在导致用户标识和主机标识都用于RSVP保护。因此，由于所提供的身份验证机制不同，基于用户的安全性和基于主机的安全性是分开讨论的。为了避免混淆不同的概念，第3.4节更详细地描述了用户身份验证的概念。
o Key Management:
o 密钥管理：
It is assumed that most of the security associations required for the protection of RSVP signaling messages are already available, and hence key management was done in advance. There is, however, an exception with respect to support for Kerberos. Using Kerberos, an entity is able to distribute a session key used for RSVP signaling protection.
假定保护RSVP信令消息所需的大多数安全关联都已可用，因此提前进行了密钥管理。但是，在支持Kerberos方面有一个例外。使用Kerberos，实体能够分发用于RSVP信令保护的会话密钥。
o RSVP INTEGRITY and POLICY_DATA INTEGRITY Objects:
o RSVP完整性和策略_数据完整性对象：
RSVP uses an INTEGRITY object in two places in a message. The first is in the RSVP message itself and covers the entire RSVP message as defined in [1]. The second is included in the POLICY_DATA object and defined in [2]. To differentiate the two objects by their scope of protection, the two terms RSVP INTEGRITY and POLICY_DATA INTEGRITY object are used, respectively. The data structure of the two objects, however, is the same.
RSVP在消息中的两个位置使用完整性对象。第一个是RSVP消息本身，涵盖了[1]中定义的整个RSVP消息。第二个包含在POLICY_数据对象中，并在[2]中定义。为了根据保护范围区分这两个对象，分别使用了两个术语RSVP INTEGRITY和POLICY_DATA INTEGRITY object。但是，这两个对象的数据结构是相同的。
o Hop versus Peer:
o 跳跃与对等：
In the past, the terminology for nodes addressed by RSVP has been discussed considerably. In particular, two favorite terms have been used: hop and peer. This document uses the term hop, which is different from an IP hop. Two neighboring RSVP nodes communicating with each other are not necessarily neighboring IP nodes (i.e., they may be more than one IP hop away).
在过去，RSVP处理的节点术语已经被大量讨论。特别是，有两个最受欢迎的术语被使用：hop和peer。本文档使用术语hop，它不同于IP跃点。相互通信的两个相邻RSVP节点不一定是相邻的IP节点（即，它们可能距离多个IP跃点）。
This section describes the security mechanisms provided by RSVP. Although use of IPsec is mentioned in Section 10 of [1], the other security mechanisms primarily envisioned for RSVP are described.
本节介绍RSVP提供的安全机制。尽管[1]的第10节中提到了IPsec的使用，但也描述了主要为RSVP设想的其他安全机制。
The RSVP INTEGRITY object is the major component of RSVP security protection. This object is used to provide integrity and replay protection for the content of the signaling message between two RSVP participating routers or between an RSVP router and host. Furthermore, the RSVP INTEGRITY object provides data origin authentication. The attributes of the object are briefly described:
RSVP完整性对象是RSVP安全保护的主要组件。此对象用于为两个RSVP参与路由器之间或RSVP路由器与主机之间的信令消息内容提供完整性和重播保护。此外，RSVP INTEGRITY对象提供数据源身份验证。简要描述了对象的属性：
o Flags field:
o 标志字段：
The Handshake Flag is the only defined flag. It is used to synchronize sequence numbers if the communication gets out of sync (e.g., it allows a restarting host to recover the most
握手标志是唯一定义的标志。它用于在通信不同步时同步序列号（例如，它允许重新启动的主机恢复最短的时间）
recent sequence number). Setting this flag to one indicates that the sender is willing to respond to an Integrity Challenge message. This flag can therefore be seen as a negotiation capability transmitted within each INTEGRITY object.
最近的序列号）。将此标志设置为1表示发件人愿意响应完整性质询消息。因此，可以将该标志视为在每个完整性对象内传输的协商能力。
o Key Identifier:
o 密钥标识符：
The Key Identifier selects the key used for verification of the Keyed Message Digest field and, hence, must be unique for the sender. It has a fixed 48-bit length. The generation of this Key Identifier field is mostly a decision of the local host. [1] describes this field as a combination of an address, sending interface, and key number. We assume that the Key Identifier is simply a (keyed) hash value computed over a number of fields, with the requirement to be unique if more than one security association is used in parallel between two hosts (e.g., as is the case with security associations having overlapping lifetimes). A receiving system uniquely identifies a security association based on the Key Identifier and the sender's IP address. The sender's IP address may be obtained from the RSVP_HOP object or from the source IP address of the packet if the RSVP_HOP object is not present. The sender uses the outgoing interface to determine which security association to use. The term "outgoing interface" may be confusing. The sender selects the security association based on the receiver's IP address (i.e., the address of the next RSVP-capable router). The process of determining which node is the next RSVP-capable router is not further specified and is likely to be statically configured.
密钥标识符选择用于验证密钥消息摘要字段的密钥，因此对于发送方来说必须是唯一的。它具有固定的48位长度。该密钥标识符字段的生成主要由本地主机决定。[1] 将此字段描述为地址、发送接口和密钥号的组合。我们假设密钥标识符只是在多个字段上计算的（键控的）散列值，如果两台主机之间并行使用多个安全关联，则要求是唯一的（例如，具有重叠生存期的安全关联的情况）。接收系统根据密钥标识符和发送方的IP地址唯一地标识安全关联。发送方的IP地址可以从RSVP_-HOP对象获得，如果RSVP_-HOP对象不存在，则可以从数据包的源IP地址获得。发送方使用传出接口确定要使用的安全关联。术语“输出接口”可能令人困惑。发送方根据接收方的IP地址（即下一个支持RSVP的路由器的地址）选择安全关联。确定哪个节点是下一个支持RSVP的路由器的过程没有进一步指定，可能是静态配置的。
o Sequence Number:
o 序列号：
The sequence number used by the INTEGRITY object is 64 bits in length, and the starting value can be selected arbitrarily. The length of the sequence number field was chosen to avoid exhaustion during the lifetime of a security association as stated in Section 3 of [1]. In order for the receiver to distinguish between a new and a replayed message, the sequence number must be monotonically incremented (modulo 2^64) for each message. We assume that the first sequence number seen (i.e., the starting sequence number) is stored somewhere. The modulo-operation is required because the starting sequence number may be an arbitrary number. The receiver therefore only accepts packets with a sequence number larger (modulo 2^64) than the previous packet. As explained in [1] this process is started by handshaking and agreeing on an initial sequence number. If no such handshaking is available then the initial sequence number must be part of the establishment of the security association.
INTEGRITY对象使用的序列号长度为64位，起始值可以任意选择。如[1]第3节所述，选择序列号字段的长度是为了避免在安全关联的生命周期内耗尽。为了让接收者区分新消息和重播消息，每个消息的序列号必须单调递增（模2^64）。我们假设看到的第一个序列号（即起始序列号）存储在某处。由于起始序列号可能是任意数字，因此需要进行模运算。因此，接收器仅接受序列号大于前一个数据包（模2^64）的数据包。如[1]中所述，该过程通过握手和商定初始序列号开始。如果没有此类握手，则初始序列号必须是建立安全关联的一部分。
The generation and storage of sequence numbers is an important step in preventing replay attacks and is largely determined by the capabilities of the system in the presence of system crashes, failures, and restarts. Section 3 of [1] explains some of the most important considerations. However, the description of how the receiver distinguishes proper from improper sequence numbers is incomplete: it implicitly assumes that gaps large enough to cause the sequence number to wrap around cannot occur.
序列号的生成和存储是防止重播攻击的重要步骤，在很大程度上取决于系统崩溃、故障和重新启动时的系统能力。[1]第3节解释了一些最重要的注意事项。然而，关于接收者如何区分正确序列号和不正确序列号的描述是不完整的：它隐含地假设间隙大到足以导致序列号环绕的情况不会发生。
If delivery in order were guaranteed, the following procedure would work: the receiver keeps track of the first sequence number received, INIT-SEQ, and the most recent sequence number received, LAST-SEQ, for each key identifier in a security association. When the first message is received, set INIT-SEQ = LAST-SEQ = value received and accept. When a subsequent message is received, if its sequence number is strictly between LAST-SEQ and INIT-SEQ, (modulo 2^64), accept and update LAST-SEQ with the value just received. If it is between INIT-SEQ and LAST-SEQ, inclusive, (modulo 2^64), reject and leave the value of LAST-SEQ unchanged. Because delivery in order is not guaranteed, the above rules need to be combined with a method of allowing a fixed sized window in the neighborhood of LAST-SEQ for out-of-order delivery, for example, as described in Appendix C of [3].
如果保证按顺序交付，则以下过程将起作用：接收方跟踪安全关联中每个密钥标识符的第一个接收序列号INIT-SEQ和最近接收序列号LAST-SEQ。收到第一条消息时，设置INIT-SEQ=LAST-SEQ=value received并接受。当接收到后续消息时，如果其序列号严格介于LAST-SEQ和INIT-SEQ之间（模2^64），则接受LAST-SEQ并用刚接收到的值更新它。如果介于INIT-SEQ和LAST-SEQ（含）之间（模2^64），则拒绝并保持LAST-SEQ的值不变。由于无法保证按订单交付，因此需要将上述规则与允许在LAST-SEQ附近设置固定大小窗口的方法相结合，以便按订单交付，例如，如[3]附录C所述。
o Keyed Message Digest:
o 键入的消息摘要：
The Keyed Message Digest is a security mechanism built into RSVP that used to provide integrity protection of a signaling message (including its sequence number). Prior to computing the value for the Keyed Message Digest field, the Keyed Message Digest field itself must be set to zero and a keyed hash computed over the entire RSVP packet. The Keyed Message Digest field is variable in length but must be a multiple of four octets. If HMAC-MD5 is used, then the output value is 16 bytes long. The keyed hash function HMAC-MD5 [4] is required for an RSVP implementation, as noted in Section 1 of [1]. Hash algorithms other than MD5 [5], like SHA-1 [15], may also be supported.
密钥消息摘要是RSVP中内置的安全机制，用于提供信令消息（包括其序列号）的完整性保护。在计算键控消息摘要字段的值之前，键控消息摘要字段本身必须设置为零，并在整个RSVP数据包上计算键控哈希。键控消息摘要字段长度可变，但必须是四个八位字节的倍数。如果使用HMAC-MD5，则输出值为16字节长。如[1]第1节所述，RSVP实现需要键控哈希函数HMAC-MD5[4]。也可以支持MD5[5]以外的散列算法，如SHA-1[15]。
The key used for computing this Keyed Message Digest may be obtained from the pre-shared secret, which is either manually distributed or the result of a key management protocol. No key management protocol, however, is specified to create the desired security associations. Also, no guidelines for key length are given. It should be recommended that HMAC-MD5 keys be 128 bits and SHA-1 keys 160 bits, as in IPsec AH [16] and ESP [17].
用于计算该密钥化消息摘要的密钥可以从预先共享的秘密中获得，该秘密可以是手动分发的，也可以是密钥管理协议的结果。但是，没有指定密钥管理协议来创建所需的安全关联。此外，没有给出键长度的准则。建议HMAC-MD5密钥为128位，SHA-1密钥为160位，如IPsec AH[16]和ESP[17]中所述。
Different attributes are stored for security associations of sending and receiving systems (i.e., unidirectional security associations). The sending system needs to maintain the following attributes in such a security association [1]:
为发送和接收系统的安全关联存储不同的属性（即单向安全关联）。发送系统需要在此类安全关联中维护以下属性[1]：
o Authentication algorithm and algorithm mode
o 认证算法和算法模式
o Key
o 钥匙
o Key Lifetime
o 密钥寿命
o Sending Interface
o 发送接口
o Latest sequence number (received with this key identifier)
o 最新序列号（使用此密钥标识符接收）
The receiving system has to store the following fields:
接收系统必须存储以下字段：
o Authentication algorithm and algorithm mode
o 认证算法和算法模式
o Key
o 钥匙
o Key Lifetime
o 密钥寿命
o Source address of the sending system
o 发送系统的源地址
o List of last n sequence numbers (received with this key identifier)
o 最后n个序列号列表（使用此密钥标识符接收）
Note that the security associations need to have additional fields to indicate their state. It is necessary to have overlapping lifetimes of security associations to avoid interrupting an ongoing communication because of expired security associations. During such a period of overlapping lifetime it is necessary to authenticate with either one or both active keys. As mentioned in [1], a sender and a receiver may have multiple active keys simultaneously. If more than one algorithm is supported, then the algorithm used must be specified for a security association.
请注意，安全关联需要有其他字段来指示其状态。安全关联的生命周期必须重叠，以避免由于过期的安全关联而中断正在进行的通信。在这种重叠的生命周期内，必须使用一个或两个活动密钥进行身份验证。如[1]中所述，发送方和接收方可以同时具有多个活动密钥。如果支持多个算法，则必须为安全关联指定使用的算法。
RFC 2205 [6] assumes that security associations are already available. An implementation must support manual key distribution as noted in Section 5.2 of [1]. Manual key distribution, however, has different requirements for key storage; a simple plaintext ASCII file may be sufficient in some cases. If multiple security associations with different lifetimes need to be supported at the same time, then
RFC 2205[6]假设安全关联已经可用。如[1]第5.2节所述，实现必须支持手动密钥分发。然而，手动密钥分配对密钥存储有不同的要求；在某些情况下，一个简单的明文ASCII文件就足够了。如果需要同时支持具有不同生存期的多个安全关联，则
a key engine would be more appropriate. Further security requirements listed in Section 5.2 of [1] are the following:
关键引擎更合适。[1]第5.2节中列出的其他安全要求如下：
o The manual deletion of security associations must be supported.
o 必须支持手动删除安全关联。
o The key storage should persist during a system restart.
o 在系统重新启动期间，密钥存储应保持不变。
o Each key must be assigned a specific lifetime and a specific Key Identifier.
o 必须为每个密钥分配特定的生存期和特定的密钥标识符。
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [2]. Section 2 of [7] states that "Providing policy based admission control mechanism based on user identities or application is one of the prime requirements." To identify the user or the application, a policy element called AUTH_DATA, which is contained in the POLICY_DATA object, is created by the RSVP daemon at the user's host and transmitted inside the RSVP message. The structure of the POLICY_DATA element is described in [2]. Network nodes acting as policy decision points (PDPs) then use the information contained in the AUTH_DATA element to authenticate the user and to allow policy-based admission control to be executed. As mentioned in [7], the policy element is processed and the PDP replaces the old element with a new one for forwarding to the next hop router.
除了使用RSVP消息中的INTEGRITY对象进行基于主机的身份验证外，还可以使用[2]中介绍的基于用户的身份验证。[7]第2节指出，“基于用户身份或应用程序提供基于策略的准入控制机制是主要要求之一。”为了识别用户或应用程序，一个名为AUTH_DATA的策略元素包含在policy_数据对象中，由用户主机上的RSVP守护进程创建，并在RSVP消息中传输。POLICY_数据元素的结构如[2]所述。然后，充当策略决策点（PDP）的网络节点使用AUTH_数据元素中包含的信息对用户进行身份验证，并允许执行基于策略的准入控制。如[7]所述，处理策略元素，PDP用新元素替换旧元素，以转发到下一跳路由器。
A detailed description of the POLICY_DATA element can be found in [2]. The attributes contained in the authentication data policy element AUTH_DATA, which is defined in [7], are briefly explained in this Section. Figure 1 shows the abstract structure of the RSVP message with its security-relevant objects and the scope of protection. The RSVP INTEGRITY object (outer object) covers the entire RSVP message, whereas the POLICY_DATA INTEGRITY object only covers objects within the POLICY_DATA element.
有关POLICY_数据元素的详细说明，请参见[2]。本节简要说明了[7]中定义的身份验证数据策略元素AUTH_data中包含的属性。图1显示了RSVP消息的抽象结构及其安全相关对象和保护范围。RSVP完整性对象（外部对象）覆盖整个RSVP消息，而POLICY_数据完整性对象仅覆盖POLICY_数据元素内的对象。
+--------------------------------------------------------+
| RSVP Message |
+--------------------------------------------------------+
| Object |POLICY_DATA Object ||
| +-------------------------------------------+|
| | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object |||
| | +------------------------------+||
| | | Various Authentication |||
| | | Attributes |||
| | +------------------------------+||
| +-------------------------------------------+|
+--------------------------------------------------------+
+--------------------------------------------------------+
| RSVP Message |
+--------------------------------------------------------+
| Object |POLICY_DATA Object ||
| +-------------------------------------------+|
| | INTEGRITY +------------------------------+||
| | Object | AUTH_DATA Object |||
| | +------------------------------+||
| | | Various Authentication |||
| | | Attributes |||
| | +------------------------------+||
| +-------------------------------------------+|
+--------------------------------------------------------+
Figure 1: Security Relevant Objects and Elements within the RSVP Message.
图1:RSVP消息中与安全相关的对象和元素。
The AUTH_DATA object contains information for identifying users and applications together with credentials for those identities. The main purpose of these identities seems to be usage for policy-based admission control and not authentication and key management. As noted in Section 6.1 of [7], an RSVP message may contain more than one POLICY_DATA object and each of them may contain more than one AUTH_DATA object. As indicated in Figure 1 and in [7], one AUTH_DATA object may contain more than one authentication attribute. A typical configuration for Kerberos-based user authentication includes at least the Policy Locator and an attribute containing the Kerberos session ticket.
AUTH_数据对象包含用于标识用户和应用程序的信息以及这些身份的凭据。这些身份的主要目的似乎是用于基于策略的准入控制，而不是身份验证和密钥管理。如[7]第6.1节所述，RSVP消息可能包含多个策略数据对象，并且每个策略数据对象可能包含多个身份验证数据对象。如图1和[7]所示，一个AUTH_数据对象可能包含多个身份验证属性。基于Kerberos的用户身份验证的典型配置至少包括策略定位器和包含Kerberos会话票证的属性。
Successful user authentication is the basis for executing policy-based admission control. Additionally, other information such as time-of-day, application type, location information, group membership, etc. may be relevant to the implementation of an access control policy.
成功的用户身份验证是执行基于策略的准入控制的基础。此外，诸如时间、应用程序类型、位置信息、组成员资格等的其他信息可能与访问控制策略的实现相关。
The following attributes are defined for use in the AUTH_DATA object:
定义了以下属性以在AUTH_数据对象中使用：
o Policy Locator
o 策略定位器
* ASCII_DN
* ASCII_DN
* UNICODE_DN
* UNICODE\u DN
* ASCII_DN_ENCRYPT
* ASCII\u DN\u加密
* UNICODE_DN_ENCRYPT
* UNICODE\u DN\u加密
The policy locator string is an X.500 distinguished name (DN) used to locate user or application-specific policy information. The four types of X.500 DNs are listed above. The first two types are the ASCII and the Unicode representation of the user or application DN identity. The two "encrypted" distinguished name types are either encrypted with the Kerberos session key or with the private key of the user's digital certificate (i.e., digitally signed). The term "encrypted together with a digital signature" is easy to misconceive. If user identity confidentiality is provided, then the policy locator has to be encrypted with the public key of the recipient. How to obtain this public key is not described in the document. This detail may be specified in a concrete architecture in which RSVP is used.
策略定位器字符串是一个X.500可分辨名称（DN），用于定位特定于用户或应用程序的策略信息。上面列出了四种类型的X.500 DNs。前两种类型是用户或应用程序DN标识的ASCII和Unicode表示形式。这两种“加密”可分辨名称类型要么使用Kerberos会话密钥进行加密，要么使用用户数字证书的私钥（即数字签名）进行加密。“与数字签名一起加密”这一术语很容易产生误解。如果提供了用户身份保密性，则必须使用收件人的公钥对策略定位器进行加密。文档中未描述如何获取此公钥。该细节可在使用RSVP的具体架构中指定。
o Credentials
o 资格证书
Two cryptographic credentials are currently defined for a user: authentication with Kerberos V5 [8], and authentication with the help of digital signatures based on X.509 [18] and PGP [19]. The following list contains all defined credential types currently available and defined in [7]:
目前为用户定义了两个加密凭据：使用Kerberos V5[8]进行身份验证，以及使用基于X.509[18]和PGP[19]的数字签名进行身份验证。以下列表包含当前可用且在[7]中定义的所有已定义凭据类型：
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
+--------------+--------------------------------+
| Credential | Description |
| Type | |
+===============================================|
| ASCII_ID | User or application identity |
| | encoded as an ASCII string |
+--------------+--------------------------------+
| UNICODE_ID | User or application identity |
| | encoded as a Unicode string |
+--------------+--------------------------------+
| KERBEROS_TKT | Kerberos V5 session ticket |
+--------------+--------------------------------+
| X509_V3_CERT | X.509 V3 certificate |
+--------------+--------------------------------+
| PGP_CERT | PGP certificate |
+--------------+--------------------------------+
Figure 2: Credentials Supported in RSVP.
图2:RSVP中支持的凭据。
The first two credentials contain only a plaintext string, and therefore they do not provide cryptographic user authentication. These plaintext strings may be used to identify applications, that are included for policy-based admission control. Note that these plain-text identifiers may, however, be protected if either the RSVP INTEGRITY or the
前两个凭据仅包含纯文本字符串，因此它们不提供加密用户身份验证。这些纯文本字符串可用于识别应用程序，这些应用程序包括在基于策略的许可控制中。注意，如果RSVP完整性或
INTEGRITY object of the POLICY_DATA element is present. Note that the two INTEGRITY objects can terminate at different entities depending on the network structure. The digital signature may also provide protection of application identifiers. A protected application identity (and the entire content of the POLICY_DATA element) cannot be modified as long as no policy-ignorant nodes are encountered in between.
存在POLICY_数据元素的完整性对象。请注意，根据网络结构，这两个INTEGRITY对象可以在不同的实体处终止。数字签名还可以提供应用标识符的保护。受保护的应用程序标识（以及策略_数据元素的整个内容）不能修改，只要其间没有遇到策略无关节点。
A Kerberos session ticket, as previously mentioned, is the ticket of a Kerberos AP_REQ message [8] without the Authenticator. Normally, the AP_REQ message is used by a client to authenticate to a server. The INTEGRITY object (e.g., of the POLICY_DATA element) provides the functionality of the Kerberos Authenticator, namely protecting against replay and showing that the user was able to retrieve the session key following the Kerberos protocol. This is, however, only the case if the Kerberos session was used for the keyed message digest field of the INTEGRITY object. Section 7 of [1] discusses some issues for establishment of keys for the INTEGRITY object. The establishment of the security association for the RSVP INTEGRITY object with the inclusion of the Kerberos Ticket within the AUTH_DATA element may be complicated by the fact that the ticket can be decrypted by node B, whereas the RSVP INTEGRITY object terminates at a different host C.
如前所述，Kerberos会话票证是Kerberos AP_REQ消息[8]的票证，没有身份验证器。通常，客户端使用AP_REQ消息向服务器进行身份验证。完整性对象（例如，POLICY_数据元素）提供Kerberos身份验证程序的功能，即防止重播并显示用户能够按照Kerberos协议检索会话密钥。但是，只有当Kerberos会话用于INTEGRITY对象的密钥消息摘要字段时，才会出现这种情况。[1]的第7节讨论了为INTEGRITY对象建立密钥的一些问题。通过在AUTH_数据元素中包含Kerberos票证，为RSVP完整性对象建立安全关联可能会变得复杂，因为票证可以由节点B解密，而RSVP完整性对象终止于不同的主机C。
The Kerberos session ticket contains, among many other fields, the session key. The Policy Locator may also be encrypted with the same session key. The protocol steps that need to be executed to obtain such a Kerberos service ticket are not described in [7] and may involve several roundtrips, depending on many Kerberos-related factors. As an optimization, the Kerberos ticket does not need to be included in every RSVP message, as described in Section 7.1 of [1]. Thus, the receiver must store the received service ticket. If the lifetime of the ticket has expired, then a new service ticket must be sent. If the receiver lost its state information (because of a crash or restart) then it may transmit an Integrity Challenge message to force the sender to re-transmit a new service ticket.
Kerberos会话票证包含许多其他字段，其中包括会话密钥。策略定位器也可以用相同的会话密钥加密。[7]中未描述为获得此类Kerberos服务票证而需要执行的协议步骤，这些步骤可能涉及多个往返，具体取决于许多与Kerberos相关的因素。作为优化，Kerberos票证不需要包含在每个RSVP消息中，如[1]第7.1节所述。因此，接收方必须存储接收到的服务票据。如果票据的有效期已过，则必须发送新的服务票据。如果接收方丢失了其状态信息（由于崩溃或重启），则可能会发送完整性质询消息，以迫使发送方重新发送新的服务票证。
If either the X.509 V3 or the PGP certificate is included in the policy element, then a digital signature must be added. The digital signature computed over the entire AUTH_DATA object provides authentication and integrity protection. The SubType of the digital signature authentication attribute is set to zero before computing the digital signature. Whether or not a guarantee of freshness with replay protection (either
如果策略元素中包含X.509 V3或PGP证书，则必须添加数字签名。在整个AUTH_数据对象上计算的数字签名提供身份验证和完整性保护。在计算数字签名之前，数字签名身份验证属性的子类型设置为零。是否保证重播保护的新鲜度（或
timestamps or sequence numbers) is provided by the digital signature is an open issue as discussed in Section 4.3.
如第4.3节所述，数字签名提供的时间戳（或序列号）是一个公开问题。
o Digital Signature
o 数字签名
The digital signature computed over the contents of the AUTH_DATA object must be the last attribute. The algorithm used to compute the digital signature depends on the authentication mode listed in the credential. This is only partially true, because, for example, PGP again allows different algorithms to be used for computing a digital signature. The algorithm identifier used for computing the digital signature is not included in the certificate itself. The algorithm identifier included in the certificate only serves the purpose of allowing the verification of the signature computed by the certificate authority (except for the case of self-signed certificates).
对AUTH_数据对象的内容计算的数字签名必须是最后一个属性。用于计算数字签名的算法取决于凭证中列出的身份验证模式。这只是部分正确，因为，例如，PGP再次允许使用不同的算法来计算数字签名。用于计算数字签名的算法标识符不包括在证书本身中。证书中包含的算法标识符仅用于允许验证证书颁发机构计算的签名（自签名证书除外）。
o Policy Error Object
o 策略错误对象
The Policy Error Object is used in the case of a failure of policy-based admission control or other credential verification. Currently available error messages allow notification if the credentials are expired (EXPIRED_CREDENTIALS), if the authorization process disallowed the resource request (INSUFFICIENT_PRIVILEGES), or if the given set of credentials is not supported (UNSUPPORTED_CREDENTIAL_TYPE). The last error message returned by the network allows the user's host to discover the type of credentials supported. Particularly for mobile environments this might be quite inefficient. Furthermore, it is unlikely that a user supports different types of credentials. The purpose of the error message IDENTITY_CHANGED is unclear. Also, the protection of the error message is not discussed in [7].
策略错误对象用于基于策略的准入控制或其他凭证验证失败的情况。当前可用的错误消息允许在凭据过期（过期的\u凭据）、授权过程不允许资源请求（权限不足）或给定的凭据集不受支持（不支持的\u凭据类型）时发出通知。网络返回的最后一条错误消息允许用户的主机发现支持的凭据类型。特别是对于移动环境，这可能会非常低效。此外，用户不太可能支持不同类型的凭据。更改错误消息标识的目的不清楚。此外，在[7]中未讨论错误消息的保护。
The Integrity Handshake protocol was designed to allow a crashed or restarted host to obtain the latest valid challenge value stored at the receiving host. Due to the absence of key management, it must be guaranteed that two messages do not use the same sequence number with the same key. A host stores the latest sequence number of a cryptographically verified message. An adversary can replay eavesdropped packets if the crashed host has lost its sequence numbers. A signaling message from the real sender with a new sequence number would therefore allow the crashed host to update the sequence number field and prevent further replays. Hence, if there
完整性握手协议旨在允许崩溃或重新启动的主机获取存储在接收主机上的最新有效质询值。由于缺少密钥管理，必须保证两条消息不会使用具有相同密钥的相同序列号。主机存储加密验证消息的最新序列号。如果崩溃的主机丢失了序列号，对手可以重播被窃听的数据包。因此，来自真实发送方的具有新序列号的信令消息将允许崩溃主机更新序列号字段并防止进一步重播。因此，如果有
is a steady flow of RSVP-protected messages between the two hosts, an attacker may find it difficult to inject old messages, because new, authenticated messages with higher sequence numbers arrive and get stored immediately.
如果两台主机之间有稳定的RSVP保护消息流，攻击者可能会发现很难注入旧消息，因为具有更高序列号的新的、经过身份验证的消息会立即到达并存储。
The following description explains the details of an RSVP Integrity Handshake that is started by Node A after recovering from a synchronization failure:
以下说明说明了节点A在从同步失败中恢复后启动的RSVP完整性握手的详细信息：
Integrity Challenge
诚信挑战
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)
(1) Message (including
+----------+ a Cookie) +----------+
| |-------------------------->| |
| Node A | | Node B |
| |<--------------------------| |
+----------+ Integrity Response +----------+
(2) Message (including
the Cookie and the
INTEGRITY object)
Figure 3: RSVP Integrity Handshake.
图3:RSVP完整性握手。
The details of the messages are as follows:
详情如下:
CHALLENGE:=(Key Identifier, Challenge Cookie)
质询：=（密钥标识符，质询Cookie）
Integrity Challenge Message:=(Common Header, CHALLENGE)
完整性质询消息：=（公共标题，质询）
Integrity Response Message:=(Common Header, INTEGRITY, CHALLENGE)
完整性响应消息：=（公共标头、完整性、质询）
The "Challenge Cookie" is suggested to be a MD5 hash of a local secret and a timestamp [1].
建议“质询Cookie”是本地秘密和时间戳的MD5散列[1]。
The Integrity Challenge message is not protected with an INTEGRITY object as shown in the protocol flow above. As explained in Section 10 of [1] this was done to avoid problems in situations where both communicating parties do not have a valid starting sequence number.
完整性质询消息不受上面协议流中所示的完整性对象的保护。如[1]第10节所述，这样做是为了避免在通信双方都没有有效的起始序列号的情况下出现问题。
Using the RSVP Integrity Handshake protocol is recommended although it is not mandatory (because it may not be needed in all network environments).
建议使用RSVP完整性握手协议，尽管它不是强制性的（因为在所有网络环境中可能不需要）。
This section describes the protection of the RSVP-provided mechanisms for authentication, authorization, integrity and replay protection individually, user identity confidentiality, and confidentiality of the signaling messages,
本节描述了RSVP提供的认证、授权、完整性和重播保护机制的保护，以及用户身份保密性和信令消息保密性，
This paragraph shows the basic interfaces in a simple RSVP network architecture. The architecture below assumes that there is only a single domain and that the two routers are RSVP- and policy-aware. These assumptions are relaxed in the individual paragraphs, as necessary. Layer 2 devices between the clients and their corresponding first-hop routers are not shown. Other network elements like a Kerberos Key Distribution Center and, for example, an LDAP server from which the PDP retrieves its policies are also omitted. The security of various interfaces to the individual servers (KDC, PDP, etc.) depends very much on the security policy of a specific network service provider.
本段显示了简单RSVP网络体系结构中的基本接口。下面的体系结构假设只有一个域，并且两个路由器具有RSVP和策略意识。必要时，可在单独段落中放宽这些假设。未显示客户端与其对应的第一跳路由器之间的第2层设备。其他网络元素，例如Kerberos密钥分发中心，以及PDP从中检索其策略的LDAP服务器，也被省略。各个服务器（KDC、PDP等）的各种接口的安全性在很大程度上取决于特定网络服务提供商的安全策略。
+--------+
| Policy |
+----|Decision|
| | Point +---+
| +--------+ |
| |
| |
+------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+
+--------+
| Policy |
+----|Decision|
| | Point +---+
| +--------+ |
| |
| |
+------+ +-+----+ +---+--+ +------+
|Client| |Router| |Router| |Client|
| A +-------+ 1 +--------+ 2 +----------+ B |
+------+ +------+ +------+ +------+
Figure 4: Simple RSVP Architecture.
图4：简单的RSVP架构。
When considering authentication in RSVP, it is important to make a distinction between user and host authentication of the signaling messages. The host is authenticated using the RSVP INTEGRITY object, whereas credentials inside the AUTH_DATA object can be used to authenticate the user. In this section, the focus is on host authentication, whereas the next section covers user authentication.
在RSVP中考虑身份验证时，区分信令消息的用户和主机身份验证是很重要的。主机使用RSVP INTEGRITY对象进行身份验证，而AUTH_数据对象内的凭据可用于对用户进行身份验证。在本节中，重点是主机身份验证，而下一节将介绍用户身份验证。
(1) Authentication
(1) 认证
The term "host authentication" is used above, because the selection of the security association is bound to the host's IP
上面使用了术语“主机身份验证”，因为安全关联的选择绑定到主机的IP
address, as mentioned in Section 3.1 and Section 3.2. Depending on the key management protocol used to create this security association and the identity used, it is also possible to bind a user identity to this security association. Because the key management protocol is not specified, it is difficult to evaluate this part, and hence we speak about data-origin authentication based on the host's identity for RSVP INTEGRITY objects. The fact that the host identity is used for selecting the security association has already been described in Section 3.1.
地址，如第3.1节和第3.2节所述。根据用于创建此安全关联的密钥管理协议和使用的标识，还可以将用户标识绑定到此安全关联。由于未指定密钥管理协议，因此很难评估这一部分，因此我们将讨论基于RSVP完整性对象的主机身份的数据源身份验证。主机标识用于选择安全关联的事实已在第3.1节中描述。
Data-origin authentication is provided with a keyed hash value computed over the entire RSVP message, excluding the keyed message digest field itself. The security association used between the user's host and the first-hop router is, as previously mentioned, not established by RSVP, and it must therefore be available before signaling is started.
数据源身份验证通过在整个RSVP消息上计算的密钥散列值提供，不包括密钥消息摘要字段本身。如前所述，用户主机和第一跳路由器之间使用的安全关联不是由RSVP建立的，因此它必须在信令启动之前可用。
* Kerberos for the RSVP INTEGRITY object
* RSVP完整性对象的Kerberos
As described in Section 7 of [1], Kerberos may be used to create the key for the RSVP INTEGRITY object. How to learn the principal name (and realm information) of the other node is outside the scope of [1]. [20] describes a way to distribute principal and realm information via DNS, which can be used for this purpose (assuming that the FQDN or the IP address of the other node for which this information is desired is known). All that is required is to encapsulate the Kerberos ticket inside the policy element. It is furthermore mentioned that Kerberos tickets with expired lifetime must not be used, and the initiator is responsible for requesting and exchanging a new service ticket before expiration.
如[1]第7节所述，Kerberos可用于为RSVP完整性对象创建密钥。如何了解另一个节点的主体名称（和领域信息）超出了[1]的范围。[20] 描述通过DNS分发主体和领域信息的方法，此方法可用于此目的（假设需要此信息的其他节点的FQDN或IP地址已知）。所需的只是将Kerberos票证封装在policy元素中。此外还提到，不能使用生命周期已过期的Kerberos票证，并且启动器负责在到期之前请求和交换新的服务票证。
RSVP multicast processing in combination with Kerberos involves additional considerations. Section 7 of [1] states that in the multicast case all receivers must share a single key with the Kerberos Authentication Server (i.e., a single principal used for all receivers). From a personal discussion with Rodney Hess, it seems that there is currently no other solution available in the context of Kerberos. Multicast handling therefore leaves some open questions in this context.
RSVP多播处理与Kerberos的结合还需要考虑其他因素。[1]的第7节指出，在多播情况下，所有接收方必须与Kerberos身份验证服务器共享一个密钥（即，所有接收方都使用一个主体）。从与Rodney Hess的个人讨论来看，在Kerberos上下文中似乎没有其他可用的解决方案。因此，在这种情况下，多播处理留下了一些悬而未决的问题。
In the case where one entity crashed, the established security association is lost and therefore the other node must retransmit the service ticket. The crashed entity can use an Integrity Challenge message to request a new Kerberos ticket to be retransmitted by the other node. If a node receives such a request, then a reply message must be returned.
在一个实体崩溃的情况下，建立的安全关联将丢失，因此另一个节点必须重新传输服务票证。崩溃的实体可以使用完整性质询消息请求另一节点重新传输新的Kerberos票证。如果节点收到这样的请求，则必须返回回复消息。
(2) Integrity protection
(2) 完整性保护
Integrity protection between the user's host and the first-hop router is based on the RSVP INTEGRITY object. HMAC-MD5 is preferred, although other keyed hash functions may also be used within the RSVP INTEGRITY object. In any case, both communicating entities must have a security association that indicates the algorithm to use. This may, however, be difficult, because no negotiation protocol is defined to agree on a specific algorithm. Hence, if RSVP is used in a mobile environment, it is likely that HMAC-MD5 is the only usable algorithm for the RSVP INTEGRITY object. Only in local environments may it be useful to switch to a different keyed hash algorithm. The other possible alternative is that every implementation support the most important keyed hash algorithms. e.g., MD5, SHA-1, RIPEMD-160, etc. HMAC-MD5 was chosen mainly because of its performance characteristics. The weaknesses of MD5 [21] are known and were initially described in [22]. Other algorithms like SHA-1 [15] and RIPEMD-160 [21] have stronger security properties.
用户主机和第一跳路由器之间的完整性保护基于RSVP完整性对象。HMAC-MD5是首选，尽管在RSVP完整性对象中也可以使用其他键控哈希函数。在任何情况下，两个通信实体都必须具有指示要使用的算法的安全关联。然而，这可能很困难，因为没有定义协商协议来商定特定的算法。因此，如果在移动环境中使用RSVP，则HMAC-MD5可能是RSVP完整性对象的唯一可用算法。只有在本地环境中，切换到不同的键控哈希算法才有用。另一种可能的选择是，每个实现都支持最重要的键控哈希算法。e、 选择HMAC-MD5主要是因为其性能特点。MD5[21]的弱点是众所周知的，最初在[22]中进行了描述。其他算法，如SHA-1[15]和RIPEMD-160[21]具有更强的安全性。
(3) Replay Protection
(3) 重播保护
The main mechanism used for replay protection in RSVP is based on sequence numbers, whereby the sequence number is included in the RSVP INTEGRITY object. The properties of this sequence number mechanism are described in Section 3.1 of [1]. The fact that the receiver stores a list of sequence numbers is an indicator for a window mechanism. This somehow conflicts with the requirement that the receiver only has to store the highest number given in Section 3 of [1]. We assume that this is an oversight. Section 4.2 of [1] gives a few comments about the out-of-order delivery and the ability of an implementation to specify the replay window. Appendix C of [3] describes a window mechanism for handling out-of-sequence delivery.
RSVP中用于重播保护的主要机制基于序列号，因此序列号包含在RSVP完整性对象中。[1]的第3.1节描述了该序列号机制的特性。接收器存储序列号列表的事实是窗口机制的指示器。这在某种程度上与接收方只需存储[1]第3节中给出的最高数字的要求相冲突。我们认为这是一种疏忽。[1]的第4.2节给出了一些关于无序交付和实现指定重播窗口的能力的评论。[3]的附录C描述了处理无序交付的窗口机制。
(4) Integrity Handshake
(4) 完整性握手
The mechanism of the Integrity Handshake is explained in Section 3.5. The Cookie value is suggested to be a hash of a local secret and a timestamp. The Cookie value is not verified by the receiver. The mechanism used by the Integrity Handshake is a simple Challenge/Response message, which assumes that the key shared between the two hosts survives the crash. If, however, the security association is dynamically created, then this assumption may not be true.
第3.5节解释了完整性握手的机制。Cookie值建议是本地机密和时间戳的散列。接收方未验证Cookie值。完整性握手所使用的机制是一条简单的质询/响应消息，该消息假定两台主机之间共享的密钥在崩溃中幸存。但是，如果安全关联是动态创建的，则此假设可能不成立。
In Section 10 of [1], the authors note that an adversary can create a faked Integrity Handshake message that includes challenge cookies. Subsequently, it could store the received response and later try to replay these responses while a responder recovers from a crash or restart. If this replayed Integrity Response value is valid and has a lower sequence number than actually used, then this value is stored at the recovering host. In order for this attack to be successful, the adversary must either have collected a large number of challenge/response value pairs or have "discovered" the cookie generation mechanism (for example by knowing the local secret). The collection of Challenge/Response pairs is even more difficult, because they depend on the Cookie value, the sequence number included in the response message, and the shared key used by the INTEGRITY object.
在[1]的第10节中，作者指出，对手可以创建包含质询cookie的伪造完整性握手消息。随后，它可以存储接收到的响应，然后在响应程序从崩溃或重新启动中恢复时尝试重播这些响应。如果此重放的完整性响应值有效，且序列号低于实际使用的序列号，则此值将存储在恢复主机上。为了使此攻击成功，对手必须收集了大量质询/响应值对，或者“发现”了cookie生成机制（例如，通过了解本地秘密）。质询/响应对的收集更加困难，因为它们取决于Cookie值、响应消息中包含的序列号以及INTEGRITY对象使用的共享密钥。
(5) Confidentiality
(5) 保密性
Confidentiality is not considered to be a security requirement for RSVP. Hence, it is not supported by RSVP, except as described in paragraph d) of Section 4.3. This assumption may not hold, however, for enterprises or carriers who want to protect billing data, network usage patterns, or network configurations, in addition to users' identities, from eavesdropping and traffic analysis. Confidentiality may also help make certain other attacks more difficult. For example, the PathErr attack described in Section 5.2 is harder to carry out if the attacker cannot observe the Path message to which the PathErr corresponds.
保密性不被视为RSVP的安全要求。因此，RSVP不支持，除非第4.3节第d）段中描述。然而，对于希望保护计费数据、网络使用模式或网络配置以及用户身份免受窃听和流量分析的企业或运营商来说，这一假设可能不成立。保密性也可能有助于增加某些其他攻击的难度。例如，如果攻击者无法观察Paterr对应的路径消息，则第5.2节中描述的Paterr攻击更难执行。
(6) Authorization
(6) 批准
The task of authorization consists of two subcategories: network access authorization and RSVP request authorization. Access authorization is provided when a node is authenticated to the network, e.g., using EAP [23] in combination with AAA protocols (for example, RADIUS [24] or DIAMETER [9]). Issues related to network access authentication and authorization are outside the scope of RSVP.
授权任务包括两个子类：网络访问授权和RSVP请求授权。当节点通过网络身份验证时，提供访问授权，例如，结合使用EAP[23]和AAA协议（例如，RADIUS[24]或DIAMETER[9]）。与网络访问身份验证和授权相关的问题不属于RSVP的范围。
The second authorization refers to RSVP itself. Depending on the network configuration:
第二个授权是指RSVP本身。根据网络配置：
* the router either forwards the received RSVP request to the policy decision point (e.g., using COPS [10] and [11]) to request that an admission control procedure be executed, or
* 路由器或者将接收到的RSVP请求转发到策略决策点（例如，使用COPS[10]和[11]），以请求执行接纳控制过程，或者
* the router supports the functionality of a PDP and, therefore, there is no need to forward the request, or
* 路由器支持PDP的功能，因此无需转发请求，或
* the router may already be configured with the appropriate policy information to decide locally whether to grant this request.
* 路由器可能已经配置了适当的策略信息，以在本地决定是否批准该请求。
Based on the result of the admission control, the request may be granted or rejected. Information about the resource-requesting entity must be available to provide policy-based admission control.
基于接纳控制的结果，可以批准或拒绝请求。有关资源请求实体的信息必须可用，以提供基于策略的准入控制。
(7) Performance
(7) 表演
The computation of the keyed message digest for an RSVP INTEGRITY object does not represent a performance problem. The protection of signaling messages is usually not a problem, because these messages are transmitted at a low rate. Even a high volume of messages does not cause performance problems for an RSVP router due to the efficiency of the keyed message digest routine.
RSVP完整性对象的键控消息摘要的计算并不代表性能问题。信令消息的保护通常不是问题，因为这些消息是以低速率传输的。由于键控消息摘要例程的效率，即使大量消息也不会导致RSVP路由器的性能问题。
Dynamic key management, which is computationally more demanding, is more important for scalability. Because RSVP does not specify a particular key exchange protocol, it is difficult to estimate the effort needed to create the required security associations. Furthermore, the number of key exchanges to be triggered depends on security policy issues like lifetime of a security association, required security properties of the key exchange protocol, authentication mode used by the key exchange protocol, etc. In a stationary environment with a single administrative domain, manual security association establishment may be acceptable and may provide the best performance characteristics. In a mobile environment, asymmetric authentication methods are likely to be used with a key exchange protocol, and some sort of public key or certificate verification needs to be supported.
动态密钥管理在计算上要求更高，对于可伸缩性更为重要。由于RSVP没有指定特定的密钥交换协议，因此很难估计创建所需安全关联所需的工作量。此外，要触发的密钥交换的数量取决于安全策略问题，如安全关联的生存期、密钥交换协议所需的安全属性、密钥交换协议使用的身份验证模式等。在具有单个管理域的固定环境中，可接受手动安全关联建立，并可提供最佳性能特征。在移动环境中，非对称身份验证方法可能与密钥交换协议一起使用，并且需要支持某种公钥或证书验证。
As noted in the previous section, RSVP supports both user-based and host-based authentication. Using RSVP, a user may authenticate to the first hop router or to the PDP as specified in [1], depending on the infrastructure provided by the network domain or the architecture used (e.g., the integration of RSVP and Kerberos V5 into the Windows 2000 Operating System [25]). Another architecture in which RSVP is tightly integrated is the one specified by the PacketCable organization. The interested reader is referred to [26] for a discussion of their security architecture.
如前一节所述，RSVP支持基于用户和基于主机的身份验证。根据网络域提供的基础设施或使用的体系结构（例如，将RSVP和Kerberos V5集成到Windows 2000操作系统[25]），使用RSVP，用户可以向第一跳路由器或[1]中指定的PDP进行身份验证。RSVP紧密集成的另一个体系结构是PacketCable组织指定的体系结构。感兴趣的读者可参考[26]了解其安全体系结构的讨论。
(1) Authentication
(1) 认证
When a user sends an RSVP PATH or RESV message, this message may include some information to authenticate the user. [7] describes how user and application information is embedded into the RSVP message (AUTH_DATA object) and how to protect it. A router receiving such a message can use this information to authenticate the client and forward the user or application information to the policy decision point (PDP). Optionally, the PDP itself can authenticate the user, which is described in the next section. To be able to authenticate the user, to verify the integrity, and to check for replays, the entire POLICY_DATA element has to be forwarded from the router to the PDP (e.g., by including the element into a COPS message). It is assumed, although not clearly specified in [7], that the INTEGRITY object within the POLICY_DATA element is sent to the PDP along with all other attributes.
当用户发送RSVP路径或RESV消息时，此消息可能包含一些用于验证用户身份的信息。[7] 描述如何将用户和应用程序信息嵌入RSVP消息（AUTH_数据对象）以及如何保护它。接收此类消息的路由器可以使用该信息来认证客户端，并将用户或应用程序信息转发给策略决策点（PDP）。可选地，PDP本身可以对用户进行身份验证，这将在下一节中描述。为了能够对用户进行身份验证、验证完整性和检查重播，必须将整个策略_数据元素从路由器转发到PDP（例如，通过将该元素包含到COPS消息中）。尽管[7]中没有明确规定，但假定策略_数据元素中的完整性对象与所有其他属性一起发送给PDP。
* Certificate Verification
* 证书验证
Using the policy element as described in [7], it is not possible to provide a certificate revocation list or other information to prove the validity of the certificate inside the policy element. A specific mechanism for certificate verification is not discussed in [7] and hence a number of them can be used for this purpose. For certificate verification, the network element (a router or the policy decision point) that has to authenticate the user could frequently download certificate revocation lists or use a protocol like the Online Certificate Status Protocol (OCSP) [27] and the Simple Certificate Validation Protocol (SCVP) [28] to determine the current status of a digital certificate.
使用[7]中所述的策略元素，不可能提供证书吊销列表或其他信息来证明策略元素中证书的有效性。[7]中未讨论证书验证的特定机制，因此可以使用其中的许多机制来实现此目的。对于证书验证，必须验证用户身份的网元（路由器或策略决策点）可以经常下载证书撤销列表，或使用类似在线证书状态协议（OCSP）[27]和简单证书验证协议（SCVP）[28]的协议确定数字证书的当前状态。
* User Authentication to the PDP
* PDP的用户身份验证
This alternative authentication procedure uses the PDP to authenticate the user instead of the first-hop router. In Section 4.2.1 of [7], the choice is given for the user to obtain a session ticket either for the next hop router or for the PDP. As noted in the same section, the identity of the PDP or the next hop router is statically configured or dynamically retrieved. Subsequently, user authentication to the PDP is considered.
此替代身份验证过程使用PDP而不是第一跳路由器对用户进行身份验证。在[7]的第4.2.1节中，用户可以选择获取下一跳路由器或PDP的会话票证。如同一节所述，PDP或下一跳路由器的标识是静态配置或动态检索的。随后，考虑对PDP的用户认证。
* Kerberos-based Authentication to the PDP
* 基于Kerberos的PDP身份验证
If Kerberos is used to authenticate the user, then a session ticket for the PDP must be requested first. A user who roams
如果使用Kerberos对用户进行身份验证，则必须首先请求PDP的会话票证。漫游的用户
between different routers in the same administrative domain does not need to request a new service ticket, because the same PDP is likely to be used by most or all first-hop routers within the same administrative domain. This is different from the case in which a session ticket for a router has to be obtained and authentication to a router is required. The router therefore plays a passive role of simply forwarding the request to the PDP and executing the policy decision returned by the PDP. Appendix B describes one example of user-to-PDP authentication.
同一管理域中的不同路由器之间不需要请求新的服务票证，因为同一个PDP可能被同一管理域中的大多数或所有第一跳路由器使用。这与必须获得路由器的会话票证并且需要对路由器进行身份验证的情况不同。因此，路由器起着被动的作用，只是将请求转发给PDP并执行PDP返回的策略决策。附录B描述了用户到PDP身份验证的一个示例。
User authentication with the policy element provides only unilateral authentication, whereby the client authenticates to the router or to the PDP. If an RSVP message is sent to the user's host and public-key-based authentication is not used, then the message does not contain a certificate and digital signature. Hence, no mutual authentication can be assumed. In case of Kerberos, mutual authentication may be accomplished if the PDP or the router transmits a policy element with an INTEGRITY object computed with the session key retrieved from the Kerberos ticket, or if the Kerberos ticket included in the policy element is also used for the RSVP INTEGRITY object as described in Section 4.2. This procedure only works if a previous message was transmitted from the end host to the network and such key is already established. Reference [7] does not discuss this issue, and therefore there is no particular requirement for transmitting network-specific credentials back to the end-user's host.
使用policy元素的用户身份验证仅提供单向身份验证，从而客户端向路由器或PDP进行身份验证。如果向用户的主机发送RSVP消息，并且未使用基于公钥的身份验证，则该消息不包含证书和数字签名。因此，不能假定相互认证。在Kerberos的情况下，如果PDP或路由器使用从Kerberos票证检索的会话密钥计算的完整性对象传输策略元素，或者如果策略元素中包含的Kerberos票证也用于RSVP完整性对象（如第4.2节所述），则可完成相互认证。仅当先前的消息从终端主机传输到网络且该密钥已建立时，此过程才起作用。参考文献[7]未讨论此问题，因此，对于将特定于网络的凭证传输回最终用户的主机没有特殊要求。
(2) Integrity Protection
(2) 完整性保护
Integrity protection is applied separately to the RSVP message and the POLICY_DATA element, as shown in Figure 1. In case of a policy-ignorant node along the path, the RSVP INTEGRITY object and the INTEGRITY object inside the policy element terminate at different nodes. Basically, the same is true for the user credentials if they are verified at the policy decision point instead of the first hop router.
完整性保护分别应用于RSVP消息和POLICY_数据元素，如图1所示。如果路径上有策略无关的节点，则RSVP INTEGRITY对象和policy元素中的INTEGRITY对象终止于不同的节点。基本上，如果用户凭据是在策略决策点而不是在第一跳路由器上验证的，则用户凭据也是如此。
* Kerberos
* Kerberos
If Kerberos is used to authenticate the user to the first hop router, then the session key included in the Kerberos ticket may be used to compute the INTEGRITY object of the policy element. It is the keyed message digest that provides the authentication. The existence of the Kerberos service ticket inside the AUTH_DATA object does not provide authentication or a guarantee of freshness for the receiving host.
如果Kerberos用于向第一跳路由器验证用户，则Kerberos票证中包含的会话密钥可用于计算策略元素的完整性对象。提供身份验证的是密钥消息摘要。AUTH_数据对象中存在Kerberos服务票证不会为接收主机提供身份验证或新鲜性保证。
Authentication and guarantee of freshness are provided by the keyed hash value of the INTEGRITY object inside the POLICY_DATA element. This shows that the user actively participated in the Kerberos protocol and was able to obtain the session key to compute the keyed message digest. The Authenticator used in the Kerberos V5 protocol provides similar functionality, but replay protection is based on timestamps (or on a sequence number if the optional seq-number field inside the Authenticator is used for KRB_PRIV/KRB_SAFE messages as described in Section 5.3.2 of [8]).
身份验证和新鲜度保证是由POLICY_数据元素内的INTEGRITY对象的密钥散列值提供的。这表明用户积极参与了Kerberos协议，并且能够获得会话密钥来计算密钥消息摘要。Kerberos V5协议中使用的身份验证程序提供了类似的功能，但重播保护基于时间戳（或者如果身份验证程序中的可选序号字段用于[8]第5.3.2节所述的KRB_PRIV/KRB_SAFE消息，则基于序列号）。
* Digital Signature
* 数字签名
If public-key-based authentication is provided, then user authentication is accomplished with a digital signature. As explained in Section 3.3.3 of [7], the DIGITAL_SIGNATURE attribute must be the last attribute in the AUTH_DATA object, and the digital signature covers the entire AUTH_DATA object. In the case of PGP, which hash algorithm and public key algorithm are used for the digital signature computation is described in [19]. In the case of X.509 credentials, the situation is more complex because different mechanisms like CMS [29] or PKCS#7 [30] may be used for digitally signing the message element. X.509 only provides the standard for the certificate layout, which seems to provide insufficient information for this purpose. Therefore, X.509 certificates are supported, for example, by CMS or PKCS#7. [7], however, does not make any statements about the usage of CMS or PKCS#7. Currently, there is no support for CMS or for PKCS#7 [7], which provides more than just public-key-based authentication (e.g., CRL distribution, key transport, key agreement, etc.). Furthermore, the use of PGP in RSVP is vaguely defined, because there are different versions of PGP (including OpenPGP [19]), and no indication is given as to which should be used.
如果提供了基于公钥的身份验证，则用户身份验证通过数字签名完成。如[7]第3.3.3节所述，数字签名属性必须是AUTH_数据对象中的最后一个属性，并且数字签名覆盖整个AUTH_数据对象。对于PGP，数字签名计算使用哪种哈希算法和公钥算法在[19]中进行了描述。在X.509凭证的情况下，情况更加复杂，因为可以使用不同的机制，如CMS[29]或PKCS#7[30]对消息元素进行数字签名。X.509只提供了证书布局的标准，这似乎没有提供足够的信息。因此，X.509证书是由CMS或PKCS#7支持的。[7] 但是，并未就CMS或PKCS#7的使用做出任何声明。目前，不支持CMS或PKCS#7[7]，它提供的不仅仅是基于公钥的身份验证（例如，CRL分发、密钥传输、密钥协议等）。此外，由于PGP有不同的版本（包括OpenPGP[19]），因此RSVP中PGP的使用定义不明确，并且没有说明应使用哪种版本。
Supporting public-key-based mechanisms in RSVP might increase the risks of denial-of-service attacks. The large processing, memory, and bandwidth requirements should also be considered. Fragmentation might also be an issue here.
在RSVP中支持基于公钥的机制可能会增加拒绝服务攻击的风险。还应考虑大的处理、内存和带宽要求。碎片化在这里也可能是一个问题。
If the INTEGRITY object is not included in the POLICY_DATA element or not sent to the PDP, then we have to make the following observations:
如果完整性对象未包含在POLICY_数据元素中或未发送给PDP，则我们必须进行以下观察：
For the digital signature case, only the replay protection provided by the digital signature algorithm can be used. It is not clear, however, whether this usage was anticipated or not. Hence, we might assume that replay
对于数字签名情况，只能使用数字签名算法提供的重放保护。然而，目前尚不清楚这种用法是否是预期的。因此，我们可以假设
protection is based on the availability of the RSVP INTEGRITY object used with a security association that is established by other means.
保护基于RSVP完整性对象的可用性，该对象与通过其他方式建立的安全关联一起使用。
Including only the Kerberos session ticket is insufficient, because freshness is not provided (because the Kerberos Authenticator is missing). Obviously there is no guarantee that the user actually followed the Kerberos protocol and was able to decrypt the received TGS_REP (or, in rare cases, the AS_REP if a session ticket is requested with the initial AS_REQ).
仅包含Kerberos会话票证是不够的，因为没有提供新鲜度（因为缺少Kerberos身份验证程序）。显然，不能保证用户确实遵循Kerberos协议，并且能够解密接收到的TGS_REP（或者，在极少数情况下，如果使用初始AS_REQ请求会话票证，则解密AS_REP）。
(3) Replay Protection
(3) 重播保护
Figure 5 shows the interfaces relevant for replay protection of signaling messages in a more complicated architecture. In this case, the client uses the policy data element with PEP2, because PEP1 is not policy-aware. The interfaces between the client and PEP1 and between PEP1 and PEP2 are protected with the RSVP INTEGRITY object. The link between the PEP2 and the PDP is protected, for example, by using the COPS built-in INTEGRITY object. The dotted line between the Client and the PDP indicates the protection provided by the AUTH_DATA element, which has no RSVP INTEGRITY object included.
图5显示了在更复杂的体系结构中与信令消息的重播保护相关的接口。在这种情况下，客户机将策略数据元素与PEP2一起使用，因为PEP1不知道策略。客户端和PEP1之间以及PEP1和PEP2之间的接口受RSVP INTEGRITY对象的保护。例如，通过使用COPS内置的完整性对象来保护PEP2和PDP之间的链路。客户机和PDP之间的虚线表示AUTH_数据元素提供的保护，其中不包括RSVP完整性对象。
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
AUTH_DATA +----+
+---------------------------------------------------+PDP +-+
| +----+ |
| |
| |
| COPS |
| INTEGRITY|
| |
| |
| |
+--+---+ RSVP INTEGRITY +----+ RSVP INTEGRITY +----+ |
|Client+-------------------+PEP1+----------------------+PEP2+-+
+--+---+ +----+ +-+--+
| |
+-----------------------------------------------------+
POLICY_DATA INTEGRITY
Figure 5: Replay Protection.
图5：重播保护。
Host authentication with the RSVP INTEGRITY object and user authentication with the INTEGRITY object inside the POLICY_DATA element both use the same anti-replay mechanism. The length of
使用RSVP INTEGRITY对象的主机身份验证和使用POLICY_数据元素内的INTEGRITY对象的用户身份验证都使用相同的防重播机制。长度
the Sequence Number field, sequence number rollover, and the Integrity Handshake have already been explained in Section 3.1.
序列号字段、序列号翻转和完整性握手已在第3.1节中解释。
Section 9 of [7] states: "RSVP INTEGRITY object is used to protect the policy object containing user identity information from security (replay) attacks." When using public-key-based authentication, RSVP-based replay protection is not supported, because the digital signature does not cover the POLICY_DATA INTEGRITY object with its Sequence Number field. The digital signature covers only the entire AUTH_DATA object.
[7]第9节规定：“RSVP完整性对象用于保护包含用户身份信息的策略对象免受安全（重播）攻击。”使用基于公钥的身份验证时，不支持基于RSVP的重播保护，因为数字签名不包括带有序列号字段的POLICY_数据完整性对象。数字签名仅覆盖整个AUTH_数据对象。
The use of public key cryptography within the AUTH_DATA object complicates replay protection. Digital signature computation with PGP is described in [31] and in [19]. The data structure preceding the signed message digest includes information about the message digest algorithm used and a 32-bit timestamp of when the signature was created ("Signature creation time"). The timestamp is included in the computation of the message digest. The IETF standardized version of OpenPGP [19] contains more information and describes the different hash algorithms (MD2, MD5, SHA-1, RIPEMD-160) supported. [7] does not make any statements as to whether the "Signature creation time" field is used for replay protection. Using timestamps for replay protection requires different synchronization mechanisms in the case of clock-skew. Traditionally, these cases assume "loosely synchronized" clocks but also require specifying a replay window.
在AUTH_数据对象中使用公钥加密会使重播保护复杂化。[31]和[19]中描述了使用PGP进行数字签名计算。签名消息摘要之前的数据结构包括关于所使用的消息摘要算法的信息以及签名创建时间的32位时间戳（“签名创建时间”）。时间戳包括在消息摘要的计算中。IETF标准版OpenPGP[19]包含更多信息，并描述了支持的不同哈希算法（MD2、MD5、SHA-1、RIPEMD-160）。[7] 未声明“签名创建时间”字段是否用于重播保护。在时钟偏移的情况下，使用时间戳进行重播保护需要不同的同步机制。传统上，这些情况假设“松散同步”时钟，但也需要指定重播窗口。
If the "Signature creation time" is not used for replay protection, then a malicious, policy-ignorant node can use this weakness to replace the AUTH_DATA object without destroying the digital signature. If this was not simply an oversight, it is therefore assumed that replay protection of the user credentials was not considered an important security requirement, because the hop-by-hop processing of the RSVP message protects the message against modification by an adversary between two communicating nodes.
如果“签名创建时间”不用于重播保护，则恶意、策略无关的节点可以利用此弱点替换AUTH_数据对象，而不会破坏数字签名。如果这不仅仅是一个疏忽，那么就假定对用户凭证的重播保护不被视为一个重要的安全要求，因为RSVP消息的逐跳处理保护消息不被两个通信节点之间的对手修改。
The lifetime of the Kerberos ticket is based on the fields starttime and endtime of the EncTicketPart structure in the ticket, as described in Section 5.3.1 of [8]. Because the ticket is created by the KDC located at the network of the verifying entity, it is not difficult to have the clocks roughly synchronized for the purpose of lifetime verification. Additional information about clock-synchronization and Kerberos can be found in [32].
Kerberos票证的生存期基于票证中EncTicketPart结构的starttime和endtime字段，如[8]第5.3.1节所述。由于票证是由位于验证实体网络上的KDC创建的，因此为了生存期验证的目的使时钟大致同步并不困难。有关时钟同步和Kerberos的其他信息，请参见[32]。
If the lifetime of the Kerberos ticket expires, then a new ticket must be requested and used. Rekeying is implemented with this procedure.
如果Kerberos票证的生存期到期，则必须请求并使用新票证。通过此过程执行密钥更新。
(4) (User Identity) Confidentiality
(4) （用户身份）保密性
This section discusses privacy protection of identity information transmitted inside the policy element. User identity confidentiality is of particular interest because there is no built-in RSVP mechanism for encrypting the POLICY_DATA object or the AUTH_DATA elements. Encryption of one of the attributes inside the AUTH_DATA element, the POLICY_LOCATOR attribute, is discussed.
本节讨论在策略元素内传输的身份信息的隐私保护。用户身份保密性特别重要，因为没有内置的RSVP机制来加密POLICY_数据对象或AUTH_数据元素。讨论了AUTH_数据元素中的一个属性POLICY_LOCATOR属性的加密。
To protect the user's privacy, it is important not to reveal the user's identity to an adversary located between the user's host and the first-hop router (e.g., on a wireless link). Furthermore, user identities should not be transmitted outside the domain of the visited network provider. That is, the user identity information inside the policy data element should be removed or modified by the PDP to prevent revealing its contents to other (unauthorized) entities along the signaling path. It is not possible (with the offered mechanisms) to hide the user's identity in such a way that it is not visible to the first policy-aware RSVP node (or to the attached network in general).
为了保护用户的隐私，重要的是不要向位于用户主机和第一跳路由器（例如，在无线链路上）之间的对手透露用户的身份。此外，用户身份不应在访问的网络提供商的域之外传输。也就是说，PDP应删除或修改策略数据元素内的用户身份信息，以防止其内容沿信令路径泄露给其他（未经授权的）实体。（使用提供的机制）不可能以第一个策略感知RSVP节点（或通常连接的网络）看不到的方式隐藏用户身份。
The ASCII or Unicode distinguished name of the user or application inside the POLICY_LOCATOR attribute of the AUTH_DATA element may be encrypted as specified in Section 3.3.1 of [7]. The user (or application) identity is then encrypted with either the Kerberos session key or with the private key in case of public-key-based authentication. When the private key is used, we usually speak of a digital signature that can be verified by everyone possessing the public key. Because the certificate with the public key is included in the message itself, decryption is no obstacle. Furthermore, the included certificate together with the additional (unencrypted) information in the RSVP message provides enough identity information for an eavesdropper. Hence, the possibility of encrypting the policy locator in case of public-key-based authentication is problematic. To encrypt the identities using asymmetric cryptography, the user's host must be able somehow to retrieve the public key of the entity verifying the policy element (i.e., the first policy-aware router or the PDP). Then, this public key could be used to encrypt a symmetric key, which in turn encrypts the user's identity and certificate, as is done, e.g., by PGP. Currently, no such mechanism is defined in [7].
AUTH_数据元素的POLICY_LOCATOR属性内的用户或应用程序的ASCII或Unicode可分辨名称可以按照[7]第3.3.1节的规定进行加密。然后，在基于公钥的身份验证的情况下，使用Kerberos会话密钥或私钥对用户（或应用程序）身份进行加密。当使用私钥时，我们通常说的是一种数字签名，它可以由拥有公钥的每个人验证。因为带有公钥的证书包含在消息本身中，所以解密不是障碍。此外，包含的证书以及RSVP消息中的附加（未加密）信息为窃听者提供了足够的身份信息。因此，在基于公钥的认证的情况下加密策略定位器的可能性是有问题的。要使用非对称加密技术加密身份，用户的主机必须能够以某种方式检索验证策略元素的实体（即，第一个策略感知路由器或PDP）的公钥。然后，该公钥可用于加密对称密钥，对称密钥反过来加密用户的身份和证书，例如通过PGP。目前，在[7]中未定义此类机制。
The algorithm used to encrypt the POLICY_LOCATOR with the Kerberos session key is assumed to be the same as the one used for encrypting the service ticket. The information about the algorithm used is available in the etype field of the EncryptedData ASN.1 encoded message part. Section 6.3 of [8] lists the supported algorithms. [33] defines newer encryption algorithms (Rijndael, Serpent, and Twofish).
假定用于使用Kerberos会话密钥加密策略定位器的算法与用于加密服务票证的算法相同。EncryptedData ASN.1编码消息部分的etype字段中提供了有关所用算法的信息。[8]第6.3节列出了支持的算法。[33]定义了更新的加密算法（Rijndael、Serpent和Twofish）。
Evaluating user identity confidentiality also requires looking at protocols executed outside of RSVP (for example, the Kerberos protocol). The ticket included in the CREDENTIAL attribute may provide user identity protection by not including the optional cname attribute inside the unencrypted part of the Ticket. Because the Authenticator is not transmitted with the RSVP message, the cname and the crealm of the unencrypted part of the Authenticator are not revealed. In order for the user to request the Kerberos session ticket for inclusion in the CREDENTIAL attribute, the Kerberos protocol exchange must be executed. Then the Authenticator sent with the TGS_REQ reveals the identity of the user. The AS_REQ must also include the user's identity to allow the Kerberos Authentication Server to respond with an AS_REP message that is encrypted with the user's secret key. Using Kerberos, it is therefore only possible to hide the content of the encrypted policy locator, which is only useful if this value differs from the Kerberos principal name. Hence, using Kerberos it is not "entirely" possible to provide user identity confidentiality.
评估用户身份机密性还需要查看在RSVP之外执行的协议（例如，Kerberos协议）。凭证属性中包含的票证可以通过不在票证未加密部分中包含可选的cname属性来提供用户身份保护。由于认证器未随RSVP消息一起传输，因此不会显示认证器未加密部分的cname和crealm。为了让用户请求Kerberos会话票证以包含在凭证属性中，必须执行Kerberos协议交换。然后，随TGS_REQ一起发送的验证器将显示用户的身份。AS_REQ还必须包括用户的标识，以允许Kerberos身份验证服务器响应使用用户密钥加密的AS_REP消息。因此，使用Kerberos时，只能隐藏加密策略定位器的内容，这仅在该值与Kerberos主体名称不同时才有用。因此，使用Kerberos并不能“完全”提供用户身份保密性。
It is important to note that information stored in the policy element may be changed by a policy-aware router or by the policy decision point. Which parts are changed depends upon whether multicast or unicast is used, how the policy server reacts, where the user is authenticated, whether the user needs to be re-authenticated in other network nodes, etc. Hence, user-specific and application-specific information can leak after the messages leave the first hop within the network where the user's host is attached. As mentioned at the beginning of this section, this information leakage is assumed to be intentional.
需要注意的是，存储在策略元素中的信息可能会被策略感知路由器或策略决策点更改。更改哪些部分取决于是否使用多播或单播、策略服务器如何反应、用户在何处进行身份验证、用户是否需要在其他网络节点中重新进行身份验证等。因此，在消息离开连接用户主机的网络内的第一个跃点后，用户特定和应用程序特定的信息可能会泄漏。如本节开头所述，这种信息泄漏被认为是故意的。
(5) Authorization
(5) 批准
In addition to the description of the authorization steps of the Host-to-Router interface, user-based authorization is performed with the policy element providing user credentials. The inclusion of user and application specific information enables policy-based admission control with special user policies that are likely to be stored at a dedicated server. Hence, a Policy Decision Point can query, for example, an LDAP server for a
除了描述主机到路由器接口的授权步骤外，还使用提供用户凭据的策略元素执行基于用户的授权。包含特定于用户和应用程序的信息可以使用可能存储在专用服务器上的特殊用户策略实现基于策略的准入控制。因此，策略决策点可以查询（例如）LDAP服务器中的
service level agreement that states the amount of resources a certain user is allowed to request. In addition to the user identity information, group membership and other non-security-related information may contribute to the evaluation of the final policy decision. If the user is not registered to the currently attached domain, then there is the question of how much information the home domain of the user is willing to exchange. This also impacts the user's privacy policy.
服务级别协议，说明允许某个用户请求的资源量。除了用户身份信息外，组成员资格和其他与安全无关的信息也可能有助于评估最终的策略决策。如果用户未注册到当前附加的域，那么就存在用户的主域愿意交换多少信息的问题。这也会影响用户的隐私政策。
In general, the user may not want to distribute much of this policy information. Furthermore, the lack of a standardized authorization data format may create interoperability problems when exchanging policy information. Hence, we can assume that the policy decision point may use information from an initial authentication and key agreement protocol (which may have already required cross-realm communication with the user's home domain, if only to show that the home domain knows the user and that the user is entitled to roam), to forward accounting messages to this domain. This represents the traditional subscriber-based accounting scenario. Non-traditional or alternative means of access might be deployed in the near future that do not require any type of inter-domain communication.
一般来说，用户可能不想分发大部分策略信息。此外，缺乏标准化的授权数据格式可能会在交换策略信息时产生互操作性问题。因此，我们可以假设策略决策点可以使用来自初始身份验证和密钥协商协议的信息（该协议可能已经要求与用户的主域进行跨域通信，只要表明主域知道用户并且用户有权漫游），将记帐消息转发到此域。这代表了传统的基于订户的记帐场景。在不久的将来，可能会部署不需要任何域间通信的非传统或替代访问方式。
Additional discussions are required to determine the expected authorization procedures. [34] and [35] discuss authorization issues for QoS signaling protocols. Furthermore, a number of mobility implications for policy handling in RSVP are described in [36].
需要进行更多讨论，以确定预期的授权程序。[34]和[35]讨论QoS信令协议的授权问题。此外，RSVP中策略处理的许多移动性影响在[36]中进行了描述。
(6) Performance
(6) 表演
If Kerberos is used for user authentication, then a Kerberos ticket must be included in the CREDENTIAL Section of the AUTH_DATA element. The Kerberos ticket has a size larger than 500 bytes, but it only needs to be sent once because a performance optimization allows the session key to be cached as noted in Section 7.1 of [1]. It is assumed that subsequent RSVP messages only include the POLICY_DATA INTEGRITY object with a keyed message digest that uses the Kerberos session key. However, this assumes that the security association required for the POLICY_DATA INTEGRITY object is created (or modified) to allow the selection of the correct key. Otherwise, it difficult to say which identifier is used to index the security association.
如果Kerberos用于用户身份验证，则必须在AUTH_数据元素的CREDENTIAL部分中包含Kerberos票据。Kerberos票证的大小大于500字节，但只需发送一次，因为性能优化允许缓存会话密钥，如[1]第7.1节所述。假定后续RSVP消息仅包括策略_数据完整性对象，该对象具有使用Kerberos会话密钥的密钥消息摘要。但是，这假定已创建（或修改）策略_数据完整性对象所需的安全关联，以允许选择正确的密钥。否则，很难说哪个标识符用于索引安全关联。
If Kerberos is used as an authentication system then, from a performance perspective, the message exchange to obtain the session key needs to be considered, although the exchange only
如果将Kerberos用作身份验证系统，则从性能角度来看，需要考虑获取会话密钥的消息交换，尽管交换仅限于
needs to be done once in the lifetime of the session ticket. This is particularly true in a mobile environment with a fast roaming user's host.
需要在会话票证的生命周期中执行一次。在具有快速漫游用户主机的移动环境中尤其如此。
Public-key-based authentication usually provides the best scalability characteristics for key distribution, but the protocols are performance demanding. A major disadvantage of the public-key-based user authentication in RSVP is the lack of a method to derive a session key. Hence, every RSVP PATH or RESV message includes the certificate and a digital signature, which is a huge performance and bandwidth penalty. For a mobile environment with low power devices, high latency, channel noise, and low-bandwidth links, this seems to be less encouraging. Note that a public key infrastructure is required to allow the PDP (or the first-hop router) to verify the digital signature and the certificate. To check for revoked certificates, certificate revocation lists or protocols like the Online Certificate Status Protocol [27] and the Simple Certificate Validation Protocol [28] are needed. Then the integrity of the AUTH_DATA object can be verified via the digital signature.
基于公钥的认证通常为密钥分发提供最佳的可伸缩性特征，但协议的性能要求很高。RSVP中基于公钥的用户身份验证的一个主要缺点是缺少派生会话密钥的方法。因此，每个RSVP路径或RESV消息都包含证书和数字签名，这将对性能和带宽造成巨大损失。对于具有低功耗设备、高延迟、信道噪声和低带宽链路的移动环境，这似乎不太令人鼓舞。请注意，需要公钥基础设施来允许PDP（或第一跳路由器）验证数字签名和证书。要检查吊销的证书，需要证书吊销列表或协议，如在线证书状态协议[27]和简单证书验证协议[28]。然后，可以通过数字签名验证AUTH_数据对象的完整性。
(1) Authentication
(1) 认证
RSVP signaling messages have data origin authentication and are protected against modification and replay with the RSVP INTEGRITY object. The RSVP message flow between routers is protected based on the chain of trust, and hence each router needs only a security association with its neighboring routers. This assumption was made because of performance advantages and because of special security characteristics of the core network to which no user hosts are directly attached. In the core network the network structure does not change frequently and the manual distribution of shared secrets for the RSVP INTEGRITY object may be acceptable. The shared secrets may be either manually configured or distributed by using appropriately secured network management protocols like SNMPv3.
RSVP信令消息具有数据源身份验证，并通过RSVP INTEGRITY对象防止修改和重播。路由器之间的RSVP消息流基于信任链进行保护，因此每个路由器只需要与其相邻路由器建立安全关联。之所以做出这种假设，是因为性能优势以及核心网络的特殊安全特性（没有直接连接用户主机）。在核心网络中，网络结构不会频繁更改，可以接受为RSVP完整性对象手动分发共享机密。共享机密可以手动配置，也可以通过使用适当安全的网络管理协议（如SNMPv3）分发。
Independent of the key distribution mechanism, host authentication with built-in RSVP mechanisms is accomplished using the keyed message digest in the RSVP INTEGRITY object, computed using the previously exchanged symmetric key.
独立于密钥分发机制，内置RSVP机制的主机身份验证是使用RSVP完整性对象中的密钥消息摘要完成的，该消息摘要是使用先前交换的对称密钥计算的。
(2) Integrity Protection
(2) 完整性保护
Integrity protection is accomplished with the RSVP INTEGRITY object with the variable length Keyed Message Digest field.
完整性保护是通过具有可变长度键控消息摘要字段的RSVP Integrity对象实现的。
(3) Replay Protection
(3) 重播保护
Replay protection with the RSVP INTEGRITY object is extensively described in previous sections. To enable crashed hosts to learn the latest sequence number used, the Integrity Handshake mechanism is provided in RSVP.
使用RSVP INTEGRITY对象的重播保护在前面的章节中有详细介绍。为了使崩溃的主机能够了解使用的最新序列号，RSVP中提供了完整性握手机制。
(4) Confidentiality
(4) 保密性
Confidentiality is not provided by RSVP.
RSVP不提供保密信息。
(5) Authorization
(5) 批准
Depending on the RSVP network, QoS resource authorization at different routers may need to contact the PDP again. Because the PDP is allowed to modify the policy element, a token may be added to the policy element to increase the efficiency of the re-authorization procedure. This token is used to refer to an already computed policy decision. The communications interface from the PEP to the PDP must be properly secured.
根据RSVP网络，不同路由器上的QoS资源授权可能需要再次联系PDP。由于允许PDP修改策略元素，因此可以向策略元素添加令牌以提高重新授权过程的效率。此令牌用于引用已计算的策略决策。从PEP到PDP的通信接口必须妥善保护。
(6) Performance
(6) 表演
The performance characteristics for the protection of the RSVP signaling messages is largely determined by the key exchange protocol, because the RSVP INTEGRITY object is only used to compute a keyed message digest of the transmitted signaling messages.
保护RSVP信令消息的性能特征在很大程度上取决于密钥交换协议，因为RSVP完整性对象仅用于计算所传输信令消息的密钥消息摘要。
The security associations within the core network, that is, between individual routers (in comparison with the security association between the user's host and the first-hop router or with the attached network in general), can be established more easily because of the normally strong trust assumptions. Furthermore, it is possible to use security associations with an increased lifetime to avoid frequent rekeying. Hence, there is less impact on the performance compared with the user-to-network interface. The security association storage requirements are also less problematic.
由于通常的强信任假设，可以更容易地建立核心网络内的安全关联，即单个路由器之间的安全关联（与用户的主机和第一跳路由器之间的安全关联或与连接的网络之间的安全关联相比）。此外，可以使用寿命延长的安全关联来避免频繁的密钥更新。因此，与用户到网络接口相比，对性能的影响较小。安全关联存储需求的问题也较少。
This section describes a number of issues that illustrate some of the shortcomings of RSVP with respect to security.
本节描述了一些问题，这些问题说明了RSVP在安全性方面的一些缺点。
In case of end-to-end signaling, an end host starts signaling to its attached network. The first-hop communication is often more difficult to secure because of the different requirements and a missing trust relationship. An end host must therefore obtain some information to start RSVP signaling:
在端到端信令的情况下，端主机开始向其连接的网络发送信令。由于不同的需求和缺少信任关系，第一跳通信通常更难保护。因此，终端主机必须获得一些信息才能启动RSVP信令：
o Does this network support RSVP signaling?
o 该网络是否支持RSVP信令？
o Which node supports RSVP signaling?
o 哪个节点支持RSVP信令？
o To which node is authentication required?
o 需要对哪个节点进行身份验证？
o Which security mechanisms are used for authentication?
o 哪些安全机制用于身份验证？
o Which algorithms are required?
o 需要哪些算法？
o Where should the keys and security associations come from?
o 密钥和安全关联应该来自哪里？
o Should a security association be established?
o 是否应该成立安全协会？
RSVP, as specified today, is used as a building block. Hence, these questions have to be answered as part of overall architectural considerations. Without answers to these questions, ad hoc RSVP communication by an end host roaming to an unknown network is not possible. A negotiation of security mechanisms and algorithms is not supported for RSVP.
今天指定的RSVP用作构建块。因此，这些问题必须作为总体架构考虑的一部分来回答。如果没有对这些问题的回答，终端主机漫游到未知网络的即席RSVP通信是不可能的。RSVP不支持安全机制和算法的协商。
Throughout the document it was assumed that the next RSVP node along the path is always known. Knowing the next hop is important to be able to select the correct key for the RSVP Integrity object and to apply the proper protection. In the case in which an RSVP node assumes it knows which node is the next hop, the following protocol exchange can occur:
在整个文档中，假设路径上的下一个RSVP节点始终是已知的。了解下一个跃点对于能够为RSVP Integrity对象选择正确的密钥并应用适当的保护非常重要。在RSVP节点假定知道下一跳是哪个节点的情况下，可能会发生以下协议交换：
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Integrity
(A<->C) +------+
(3) | RSVP |
+------------->+ Node |
| | B |
Integrity | +--+---+
(A<->C) | |
+------+ (2) +--+----+ |
(1) | RSVP +----------->+Router | | Error
----->| Node | | or +<-----------+ (I am B)
| A +<-----------+Network| (4)
+------+ (5) +--+----+
Error .
(I am B) . +------+
. | RSVP |
...............+ Node |
| C |
+------+
Figure 6: Next-Hop Issue.
图6：下一跳问题。
When RSVP node A in Figure 6 receives an incoming RSVP Path message, standard RSVP message processing takes place. Node A then has to decide which key to select to protect the signaling message. We assume that some unspecified mechanism is used to make this decision. In this example, node A assumes that the message will travel to RSVP node C. However, for some reasons (e.g., a route change, inability to learn the next RSVP hop along the path, etc.) the message travels to node B via a non-RSVP supporting router that cannot verify the integrity of the message (or cannot decrypt the Kerberos service ticket). The processing failure causes a PathErr message to be returned to the originating sender of the Path message. This error message also contains information about the node that recognized the error. In many cases, a security association might not be available. Node A receiving the PathErr message might use the information returned with the PathErr message to select a different security association (or to establish one).
当图6中的RSVP节点A接收到传入的RSVP Path消息时，就会进行标准的RSVP消息处理。然后，节点A必须决定选择哪个密钥来保护信令消息。我们假设使用了一些未指定的机制来做出此决定。在此示例中，节点A假定消息将传输到RSVP节点C。但是，由于某些原因（例如，路由更改、无法了解路径上的下一个RSVP跃点等），消息通过不支持RSVP的路由器传输到节点B，该路由器无法验证消息的完整性（或无法解密Kerberos服务票证）。处理失败导致PathErr消息返回给Path消息的原始发件人。此错误消息还包含有关识别错误的节点的信息。在许多情况下，安全关联可能不可用。接收PathErr消息的节点A可能会使用PathErr消息返回的信息来选择不同的安全关联（或建立一个）。
Figure 6 describes a behavior that might help node A learn that an error occurred. However, the description in Section 4.2 of [1] states in step (5) that a signaling message is silently discarded if the receiving host cannot properly verify the message: "If the calculated digest does not match the received digest, the message is discarded without further processing." For RSVP Path and similar messages, this functionality is not really helpful.
图6描述了一种可能有助于节点a了解发生错误的行为。然而，[1]第4.2节中的描述在步骤（5）中指出，如果接收主机无法正确验证消息，则信令消息将被静默丢弃：“如果计算的摘要与接收的摘要不匹配，则消息将被丢弃，而无需进一步处理。”对于RSVP Path和类似消息，这个功能并没有真正的帮助。
The RSVP Path message therefore provides a number of functions: path discovery, detecting route changes, discovery of QoS capabilities along the path using the Adspec object (with some interpretation), next-hop discovery, and possibly security association establishment (for example, in the case of Kerberos).
因此，RSVP Path消息提供了许多功能：路径发现、检测路由更改、使用Adspec对象沿路径发现QoS功能（有一些解释）、下一跳发现，以及可能的安全关联建立（例如，在Kerberos的情况下）。
From a security point of view, there are conflicts between:
从安全角度来看，以下各项之间存在冲突：
o Idempotent message delivery and efficiency
o 幂等消息传递与效率
The RSVP Path message especially performs a number of functions. Supporting idempotent message delivery somehow contradicts with security association establishment, efficient message delivery, and message size. For example, a "real" idempotent signaling message would contain enough information to perform security processing without depending on a previously executed message exchange. Adding a Kerberos ticket with every signaling message is, however, inefficient. Using public-key-based mechanisms is even more inefficient when included in every signaling message. With public-key-based protection for idempotent messages, there is the additional risk of introducing denial-of-service attacks.
RSVP Path消息特别执行许多功能。支持幂等消息传递在某种程度上与安全关联建立、高效消息传递和消息大小相矛盾。例如，“实”幂等信令消息将包含足够的信息来执行安全处理，而不依赖于先前执行的消息交换。然而，在每个信令消息中添加Kerberos票证是低效的。当包含在每个信令消息中时，使用基于公钥的机制效率更低。使用基于公钥的幂等消息保护，还存在引入拒绝服务攻击的额外风险。
o RSVP Path message functionality and next-hop discovery
o RSVP路径消息功能和下一跳发现
To protect an RSVP signaling message (and an RSVP Path message in particular) it is necessary to know the identity of the next RSVP-aware node (and some other parameters). Without a mechanism for next-hop discovery, an RSVP Path message is also responsible for this task. Without knowing the identity of the next hop, the Kerberos principal name is also unknown. The so-called Kerberos user-to-user authentication mechanism, which would allow the receiver to trigger the process of establishing Kerberos authentication, is not supported. This issue will again be discussed in relationship with the last-hop problem.
为了保护RSVP信令消息（特别是RSVP路径消息），需要知道下一个RSVP感知节点的标识（以及一些其他参数）。在没有下一跳发现机制的情况下，RSVP路径消息也负责此任务。在不知道下一跳的标识的情况下，Kerberos主体名称也是未知的。不支持所谓的Kerberos用户到用户身份验证机制，该机制允许接收方触发建立Kerberos身份验证的过程。这个问题将再次与最后一跳问题一起讨论。
It is fair to assume that an RSVP-supporting node might not have security associations with all immediately neighboring RSVP nodes. Especially for inter-domain signaling, IntServ over DiffServ, or some new applications such as firewall signaling, the next RSVP-aware node might not be known in advance. The number of next RSVP nodes might be considerably large if they are separated by a large number of non-RSVP aware nodes. Hence, a node transmitting an RSVP Path message might experience difficulties in properly protecting the message if it serves as a mechanism to detect both the next RSVP node (i.e., Router Alert Option added to the signaling message and addressed to the destination address) and to detect route changes. It is fair to note that, in the intra-
可以公平地假设，支持RSVP的节点可能没有与所有直接相邻的RSVP节点的安全关联。特别是对于域间信令、区分服务上的IntServ或一些新的应用程序（如防火墙信令），下一个RSVP感知节点可能事先不知道。如果下一个RSVP节点由大量非RSVP感知节点分隔，则它们的数量可能相当大。因此，如果发送RSVP路径消息的节点用作检测下一个RSVP节点（即，添加到信令消息并寻址到目的地地址的路由器警报选项）和检测路由改变的机制，则该节点在正确保护该消息时可能会遇到困难。公平地说，在-
domain case with a dense distribution of RSVP nodes, protection might be possible with manual configuration.
域如果RSVP节点密集分布，则可以通过手动配置进行保护。
Nothing prevents an adversary from continuously flooding an RSVP node with bogus PathErr messages, although it might be possible to protect the PathErr message with an existing, available security association. A legitimate RSVP node would believe that a change in the path took place. Hence, this node might try to select a different security association or try to create one with the indicated node. If an adversary is located somewhere along the path, and either authentication or authorization is not performed with the necessary strength and accuracy, then it might also be possible to act as a man-in-the-middle. One method of reducing susceptibility to this attack is as follows: when a PathErr message is received from a node with which no security association exists, attempt to establish a security association and then repeat the action that led to the PathErr message.
尽管可以使用现有的可用安全关联来保护PathErr消息，但没有任何东西可以阻止对手不断向RSVP节点发送伪造的PathErr消息。合法的RSVP节点会认为路径发生了变化。因此，此节点可能会尝试选择不同的安全关联，或尝试使用指定的节点创建一个安全关联。如果对手位于路径的某个位置，并且认证或授权没有以必要的强度和准确性执行，那么也有可能充当中间人。降低此攻击易感性的一种方法如下：当从不存在安全关联的节点接收到PathErr消息时，尝试建立安全关联，然后重复导致PathErr消息的操作。
This section tries to address practical difficulties when authentication and key establishment are accomplished with a two-party protocol that shows some asymmetry in message processing. Kerberos is such a protocol and also the only supported protocol that provides dynamic session key establishment for RSVP. For first-hop communication, authentication is typically done between a user and some router (for example the access router). Especially in a mobile environment, it is not feasible to authenticate end hosts based on their IP or MAC address. To illustrate this problem, the typical processing steps for Kerberos are shown for first-hop communication:
本节试图解决当身份验证和密钥建立使用在消息处理中表现出某种不对称性的双方协议来完成时的实际困难。Kerberos就是这样一种协议，也是唯一支持的为RSVP提供动态会话密钥建立的协议。对于第一跳通信，身份验证通常在用户和某个路由器（例如接入路由器）之间完成。特别是在移动环境中，基于终端主机的IP或MAC地址对其进行身份验证是不可行的。为了说明此问题，为第一跳通信显示了Kerberos的典型处理步骤：
(1) The end host A learns the identity (i.e., Kerberos principal name) of some entity B. This entity B is either the next RSVP node, a PDP, or the next policy-aware RSVP node.
(1) 终端主机A学习某些实体B的标识（即Kerberos主体名称）。该实体B是下一个RSVP节点、PDP或下一个策略感知RSVP节点。
(2) Entity A then requests a ticket granting ticket for the network domain. This assumes that the identity of the network domain is known.
(2) 然后，实体A请求网络域的票证授予票证。这假定网络域的标识是已知的。
(3) Entity A then requests a service ticket for entity B, whose name was learned in step (1).
(3) 然后，实体A请求实体B的服务票证，实体B的名称在步骤（1）中获知。
(4) Entity A includes the service ticket with the RSVP signaling message (inside the policy object). The Kerberos session key is used to protect the integrity of the entire RSVP signaling message.
(4) 实体A包括带有RSVP信令消息的服务票证（在策略对象内部）。Kerberos会话密钥用于保护整个RSVP信令消息的完整性。
For last-hop communication, this processing theoretically has to be reversed: entity A is then a node in the network (for example, the access router) and entity B is the other end host (under the assumption that RSVP signaling is accomplished between two end hosts and not between an end host and an application server). However, the access router in step (1) might not be able to learn the user's principal name because this information might not be available. Entity A could reverse the process by triggering an IAKERB exchange. This would cause entity B to request a service ticket for A as described above. However, IAKERB is not supported in RSVP.
对于最后一跳通信，理论上必须反转此处理：实体A是网络中的节点（例如，接入路由器），实体B是另一个终端主机（假设RSVP信令在两个终端主机之间完成，而不是在终端主机和应用服务器之间完成）。但是，步骤（1）中的访问路由器可能无法了解用户的主体名称，因为该信息可能不可用。实体A可以通过触发IAKERB交换来逆转这一过程。这将导致实体B如上所述请求a的服务票证。但是，RSVP中不支持IAKERB。
QoS signaling requires flow information to be established at routers along a path. This flow identifier installed at each device tells the router which data packets should receive QoS treatment. RSVP typically establishes a flow identifier based on the 5-tuple (source IP address, destination IP address, transport protocol type, source port, and destination port). If this 5-tuple information is not available, then other identifiers have to be used. ESP-encrypted data traffic is such an example where the transport protocol and the port numbers are not accessible. Hence, the IPsec SPI is used as a substitute for them. [12] considers these IPsec implications for RSVP and is based on three assumptions:
QoS信令要求在路由器上沿路径建立流信息。安装在每个设备上的流标识符告诉路由器哪些数据包应该接受QoS处理。RSVP通常基于5元组（源IP地址、目标IP地址、传输协议类型、源端口和目标端口）建立流标识符。如果此5元组信息不可用，则必须使用其他标识符。ESP加密数据通信就是这样一个例子，其中传输协议和端口号不可访问。因此，IPsec SPI被用作它们的替代品。[12] 考虑这些IPsec对RSVP的影响，并基于三个假设：
(1) An end host that initiates the RSVP signaling message exchange has to be able to retrieve the SPI for a given flow. This requires some interaction with the IPsec security association database (SAD) and security policy database (SPD) [3]. An application usually does not know the SPI of the protected flow and cannot provide the desired values. It can provide the signaling protocol daemon with flow identifiers. The signaling daemon would then need to query the SAD by providing the flow identifiers as input parameters and receiving the SPI as an output parameter.
(1) 发起RSVP信令消息交换的终端主机必须能够检索给定流的SPI。这需要与IPsec安全关联数据库（SAD）和安全策略数据库（SPD）进行一些交互[3]。应用程序通常不知道受保护流的SPI，并且无法提供所需的值。它可以为信令协议守护进程提供流标识符。然后，信令守护进程需要通过提供流标识符作为输入参数并接收SPI作为输出参数来查询SAD。
(2) [12] assumes end-to-end IPsec protection of the data traffic. If IPsec is applied in a nested fashion, then parts of the path do not experience QoS treatment. This can be treated as a problem of tunneling that is initiated by the end host. The following figure better illustrates the problem in the case of enforcing secure network access:
(2) [12] 假定对数据流量进行端到端IPsec保护。如果以嵌套方式应用IPsec，则部分路径不会经历QoS处理。这可以看作是由终端主机发起的隧道问题。下图更好地说明了在强制实施安全网络访问的情况下的问题：
+------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic---> |
| | | |
+------+ +---------------+ +--------+ +-----+
| Host | | Security | | Router | | Host|
| A | | Gateway (SGW) | | Rx | | B |
+--+---+ +-------+-------+ +----+---+ +--+--+
| | | |
|IPsec-Data( | | |
| OuterSrc=A, | | |
| OuterDst=SGW, | | |
| SPI=SPI1, | | |
| InnerSrc=A, | | |
| InnerDst=B, | | |
| Protocol=X, |IPsec-Data( | |
| SrcPort=Y, | SrcIP=A, | |
| DstPort=Z) | DstIP=B, | |
|=====================>| Protocol=X, |IPsec-Data( |
| | SrcPort=Y, | SrcIP=A, |
| --IPsec protected-> | DstPort=Z) | DstIP=B, |
| data traffic |------------------>| Protocol=X, |
| | | SrcPort=Y, |
| | | DstPort=Z) |
| | |---------------->|
| | | |
| | --Unprotected data traffic---> |
| | | |
Figure 7: RSVP and IPsec protected data traffic.
图7:RSVP和IPsec保护的数据流量。
Host A, transmitting data traffic, would either indicate a 3- tuple <A, SGW, SPI1> or a 5-tuple <A, B, X, Y, Z>. In any case, it is not possible to make a QoS reservation for the entire path. Two similar examples are remote access using a VPN and protection of data traffic between a home agent (or a security gateway in the home network) and a mobile node. The same problem occurs with a nested application of IPsec (for example, IPsec between A and SGW and between A and B).
传输数据流量的主机A将指示3元组<A，SGW，SPI1>或5元组<A，B，X，Y，Z>。在任何情况下，都不可能对整个路径进行QoS保留。两个类似的例子是使用VPN的远程访问和对归属代理（或归属网络中的安全网关）和移动节点之间的数据通信的保护。IPsec的嵌套应用程序也会出现同样的问题（例如，a和SGW之间以及a和B之间的IPsec）。
One possible solution to this problem is to change the flow identifier along the path to capture the new flow identifier after an IPsec endpoint.
此问题的一个可能解决方案是沿路径更改流标识符，以在IPsec端点之后捕获新的流标识符。
IPsec tunnels that neither start nor terminate at one of the signaling end points (for example between two networks) should be addressed differently by recursively applying an RSVP signaling exchange for the IPsec tunnel. RSVP signaling within tunnels is addressed in [13].
对于在其中一个信令端点（例如，两个网络之间）既不开始也不终止的IPsec隧道，应通过递归地为IPsec隧道应用RSVP信令交换来进行不同的寻址。隧道内的RSVP信令在[13]中有说明。
(3) It is assumed that SPIs do not change during the lifetime of the established QoS reservation. If a new IPsec SA is created, then
(3) 假设SPI在已建立的QoS保留的生存期内不会改变。如果创建了新的IPsec SA，则
a new SPI is allocated for the security association. To reflect this change, either a new reservation has to be established or the flow identifier of the existing reservation has to be updated. Because IPsec SAs usually have a longer lifetime, this does not seem to be a major issue. IPsec protection of SCTP data traffic might more often require an IPsec SA (and SPI) change to reflect added and removed IP addresses from an SCTP association.
为安全关联分配了一个新的SPI。为了反映这一变化，必须建立一个新的预订，或者必须更新现有预订的流标识符。由于IPsec SAs通常具有更长的生命周期，因此这似乎不是一个主要问题。SCTP数据流量的IPsec保护通常需要IPsec SA（和SPI）更改，以反映从SCTP关联中添加和删除的IP地址。
End-to-end security for RSVP has not been discussed throughout the document. In this context, end-to-end security refers to credentials transmitted between the two end hosts using RSVP. It is obvious that care must be taken to ensure that routers along the path are able to process and modify the signaling messages according to prescribed processing procedures. However, some objects or mechanisms could be used for end-to-end protection. The main question, however, is the benefit of such end-to-end security. First, there is the question of how to establish the required security association. Between two arbitrary hosts on the Internet, this might turn out to be quite difficult. Second, the usefulness of end-to-end security depends on the architecture in which RSVP is deployed. If RSVP is used only to signal QoS information into the network, and other protocols have to be executed beforehand to negotiate the parameters and to decide which entity is charged for the QoS reservation, then no end-to-end security is likely to be required. Introducing end-to-end security to RSVP would then cause problems with extensions like RSVP proxy [37], Localized RSVP [38], and others that terminate RSVP signaling somewhere along the path without reaching the destination end host. Such a behavior could then be interpreted as a man-in-the-middle attack.
本文档未讨论RSVP的端到端安全性。在此上下文中，端到端安全性是指使用RSVP在两个终端主机之间传输的凭据。显然，必须注意确保路径上的路由器能够根据规定的处理程序处理和修改信令消息。但是，某些对象或机制可用于端到端保护。然而，主要问题是这种端到端安全性的好处。首先，问题是如何建立必要的安全协会。在Internet上的两个任意主机之间，这可能会非常困难。其次，端到端安全性的有用性取决于部署RSVP的体系结构。如果RSVP仅用于向网络发送QoS信息信号，并且必须事先执行其他协议来协商参数并决定向哪个实体收取QoS保留费用，则可能不需要端到端安全性。向RSVP引入端到端安全性将导致诸如RSVP代理[37]、本地化RSVP[38]等扩展出现问题，以及其他在路径某处终止RSVP信令而不到达目标端主机的扩展出现问题。这样的行为可以解释为中间人攻击。
It is assumed throughout that RSVP signaling messages can also be protected by IPsec [3] in a hop-by-hop fashion between two adjacent RSVP nodes. RSVP, however, uses special processing of signaling messages, which complicates IPsec protection. As explained in this section, IPsec should only be used for protection of RSVP signaling messages in a point-to-point communication environment (i.e., an RSVP message can only reach one RSVP router and not possibly more than one). This restriction is caused by the combination of signaling message delivery and discovery into a single message. Furthermore, end-to-end addressing complicates IPsec handling considerably. This section describes at least some of these complications.
自始至终，假设RSVP信令消息也可以在两个相邻RSVP节点之间以逐跳方式由IPsec[3]保护。然而，RSVP使用对信令消息的特殊处理，这使IPsec保护复杂化。如本节所述，IPsec应仅用于保护点对点通信环境中的RSVP信令消息（即，一条RSVP消息只能到达一个RSVP路由器，并且不可能超过一个）。此限制是由信令消息传递和发现组合到单个消息中引起的。此外，端到端寻址使IPsec处理相当复杂。本节至少描述了其中的一些复杂情况。
RSVP messages are transmitted as raw IP packets with protocol number 46. It might be possible to encapsulate them in UDP as described in Appendix C of [6]. Some RSVP messages (Path, PathTear, and ResvConf) must have the Router Alert IP Option set in the IP header. These messages are addressed to the (unicast or multicast) destination address and not to the next RSVP node along the path. Hence, an IPsec traffic selector can only use these fields for IPsec SA selection. If there is only a single path (and possibly all traffic along it is protected) then there is no problem for IPsec protection of signaling messages. This type of protection is not common and might only be used to secure network access between an end host and its first-hop router. Because the described RSVP messages are addressed to the destination address instead of the next RSVP node, it is not possible to use IPsec ESP [17] or AH [16] in transport mode--only IPsec in tunnel mode is possible.
RSVP消息作为协议号为46的原始IP数据包传输。如[6]附录C所述，可以将它们封装在UDP中。某些RSVP消息（Path、PATHTRARE和ResvConf）必须在IP头中设置路由器警报IP选项。这些消息被发送到（单播或多播）目标地址，而不是路径上的下一个RSVP节点。因此，IPsec流量选择器只能将这些字段用于IPsec SA选择。如果只有一条路径（并且可能所有沿该路径的流量都受到保护），那么对信令消息的IPsec保护就没有问题。这种类型的保护并不常见，可能仅用于保护终端主机与其第一跳路由器之间的网络访问。因为所描述的RSVP消息被寻址到目标地址，而不是下一个RSVP节点，所以无法在传输模式下使用IPsec ESP[17]或AH[16]——只能在隧道模式下使用IPsec。
If an RSVP message can taket more than one possible path, then the IPsec engine will experience difficulties protecting the message. Even if the RSVP daemon installs a traffic selector with the destination IP address, still, no distinguishing element allows selection of the correct security association for one of the possible RSVP nodes along the path. Even if it possible to apply IPsec protection (in tunnel mode) for RSVP signaling messages by incorporating some additional information, there is still the possibility that the tunneled messages do not recognize a path change in a non-RSVP router. In this case the signaling messages would simply follow a different path than the data.
如果RSVP消息可以采用多个可能的路径，则IPsec引擎将难以保护该消息。即使RSVP守护进程安装了具有目标IP地址的流量选择器，仍然没有任何区别元素允许为路径上的一个可能的RSVP节点选择正确的安全关联。即使可以通过合并一些附加信息对RSVP信令消息应用IPsec保护（在隧道模式下），隧道消息仍有可能无法识别非RSVP路由器中的路径更改。在这种情况下，信令消息将遵循与数据不同的路径。
RSVP messages like RESV can be protected by IPsec, because they contain enough information to create IPsec traffic selectors that allow differentiation between various next RSVP nodes. The traffic selector would then contain the protocol number and the source and destination address pair of the two communicating RSVP nodes.
像RESV这样的RSVP消息可以受到IPsec的保护，因为它们包含足够的信息来创建IPsec流量选择器，从而允许区分不同的下一个RSVP节点。然后，流量选择器将包含协议编号以及两个通信RSVP节点的源和目标地址对。
One benefit of using IPsec is the availability of key management using either IKE [39], KINK [40] or IKEv2 [41].
使用IPsec的一个好处是可以使用IKE[39]、KINK[40]或IKEv2[41]进行密钥管理。
[34] describes two trust models (NJ Turnpike and NJ Parkway) and two authorization models (per-session and per-channel financial settlement). The NJ Turnpike model gives a justification for hop-by-hop security protection. RSVP focuses on the NJ Turnpike model, although the different trust models are not described in detail. RSVP supports the NJ Parkway model and per-channel financial settlement only to a certain extent. Authentication of the user (or end host) can be provided with the user identity representation
[34] 描述了两种信任模型（NJ收费公路和NJ公园路）和两种授权模型（每个会话和每个通道财务结算）。NJ收费公路模型为逐跳安全保护提供了理由。RSVP侧重于NJ收费公路模型，尽管没有详细描述不同的信任模型。RSVP仅在一定程度上支持NJ Parkway模式和每个渠道的财务结算。用户（或终端主机）的身份验证可以通过用户身份表示提供
mechanism, but authentication might, in many cases, be insufficient for authorization. The communication procedures defined for policy
机制，但在许多情况下，身份验证可能不足以进行授权。为策略定义的通信程序
objects [42] can be improved to support the more efficient per-channel financial settlement model by avoiding policy handling between inter-domain networks at a signaling message granularity. Additional information about expected behavior of policy handling in RSVP can also be obtained from [43].
通过在信令消息粒度上避免域间网络之间的策略处理，可以改进对象[42]，以支持更高效的单通道财务结算模型。关于RSVP中策略处理的预期行为的其他信息也可以从[43]中获得。
[35] and [36] provide additional information on authorization. No good and agreed mechanism for dealing with authorization of QoS reservations in roaming environments is provided. Price distribution mechanisms are only described in papers and never made their way through standardization. RSVP focuses on receiver-initiated reservations with authorization for the QoS reservation by the data receiver, which introduces a fair amount of complexity for mobility handling as described, for example, in [36].
[35] 和[36]提供有关授权的其他信息。没有为漫游环境中的QoS保留授权提供良好且一致同意的机制。价格分配机制仅在论文中描述，从未通过标准化实现。RSVP侧重于由数据接收方授权QoS保留的接收方发起的保留，这为移动性处理带来了相当大的复杂性，如[36]中所述。
RSVP was the first QoS signaling protocol that provided some security protection. Whether RSVP provides appropriate security protection heavily depends on the environment where it is deployed. RSVP as specified today should be viewed as a building block that has to be adapted to a given architecture.
RSVP是第一个提供安全保护的QoS信令协议。RSVP是否提供适当的安全保护在很大程度上取决于它部署的环境。今天指定的RSVP应被视为必须适应给定体系结构的构建块。
This document aims to provide more insight into the security of RSVP. It cannot be interpreted as a pass or fail evaluation of the security provided by RSVP.
本文档旨在对RSVP的安全性提供更深入的了解。不能将其解释为RSVP提供的安全性评估通过或失败。
Certainly this document is not a complete description of all security issues related to RSVP. Some issues that require further consideration are RSVP extensions (for example [12]), multicast issues, and other security properties like traffic analysis. Additionally, the interaction with mobility protocols (micro- and macro-mobility) demands further investigation from a security point of view.
当然，本文档并不是与RSVP相关的所有安全问题的完整描述。需要进一步考虑的一些问题包括RSVP扩展（例如[12]）、多播问题和其他安全属性，如流量分析。此外，与移动协议（微观和宏观移动）的交互需要从安全角度进行进一步的研究。
What can be learned from practical protocol experience and from the increased awareness regarding security is that some of the available credential types have received more acceptance than others. Kerberos is a system that is integrated into many IETF protocols today. Public-key-based authentication techniques are, however, still considered to be too heavy-weight (computationally and from a bandwidth perspective) to be used for per-flow signaling. The increased focus on denial of service attacks puts additional demands on the design of public-key-based authentication.
从实际协议经验和安全意识的提高中可以学到的是，一些可用的凭证类型比其他类型得到了更多的认可。Kerberos是目前集成到许多IETF协议中的系统。然而，基于公钥的认证技术仍然被认为太重（从计算和带宽的角度）而不能用于每流信令。对拒绝服务攻击的日益关注对基于公钥的身份验证的设计提出了额外的要求。
The following list briefly summarizes a few security or architectural issues that deserve improvement:
以下列表简要总结了一些值得改进的安全性或体系结构问题：
o Discovery and signaling message delivery should be separated.
o 发现和信令消息传递应该分开。
o For some applications and scenarios, it cannot be assumed that neighboring RSVP-aware nodes know each other. Hence, some in-path discovery mechanism should be provided.
o 对于某些应用程序和场景，不能假设相邻的感知RSVP的节点相互了解。因此，应该提供一些路径内发现机制。
o Addressing for signaling messages should be done in a hop-by-hop fashion.
o 信令消息的寻址应以逐跳方式进行。
o Standard security protocols (IPsec, TLS, or CMS) should be used whenever possible. Authentication and key exchange should be separated from signaling message protection. In general, it is necessary to provide key management to establish security associations dynamically for signaling message protection. Relying on manually configured keys between neighboring RSVP nodes is insufficient. A separate, less frequently executed key management and security association establishment protocol is a good place to perform entity authentication, security service negotiation and selection, and agreement on mechanisms, transforms, and options.
o 应尽可能使用标准安全协议（IPsec、TLS或CMS）。认证和密钥交换应与信令消息保护分开。一般来说，需要提供密钥管理来动态地建立安全关联以保护信令消息。在相邻RSVP节点之间依赖手动配置的密钥是不够的。单独的、执行频率较低的密钥管理和安全关联建立协议是执行实体身份验证、安全服务协商和选择以及机制、转换和选项协议的好地方。
o The use of public key cryptography in authorization tokens, identity representations, selective object protection, etc. is likely to cause fragmentation, the need to protect against denial of service attacks, and other problems.
o 在授权令牌、身份表示、选择性对象保护等方面使用公钥加密可能会导致碎片、需要防止拒绝服务攻击以及其他问题。
o Public key authentication and user identity confidentiality provided with RSVP require some improvement.
o RSVP提供的公钥认证和用户身份保密性需要一些改进。
o Public-key-based user authentication only provides entity authentication. An additional security association is required to protect signaling messages.
o 基于公钥的用户身份验证仅提供实体身份验证。需要额外的安全关联来保护信令消息。
o Data origin authentication should not be provided by non-RSVP nodes (such as the PDP). Such a procedure could be accomplished by entity authentication during the authentication and key exchange phase.
o 非RSVP节点（如PDP）不应提供数据源身份验证。这样的过程可以在身份验证和密钥交换阶段通过实体身份验证来完成。
o Authorization and charging should be better integrated into the base protocol.
o 授权和收费应该更好地集成到基本协议中。
o Selective message protection should be provided. A protected message should be recognizable from a flag in the header.
o 应提供选择性消息保护。受保护的消息应该可以从标头中的标志识别。
o Confidentiality protection is missing and should therefore be added to the protocol. The general principle is that protocol designers can seldom foresee all of the environments in which protocols will be run, so they should allow users to select from a full range of security services, as the needs of different user communities vary.
o 缺少保密保护，因此应将其添加到协议中。一般原则是，协议设计人员很少能预见到协议将在其中运行的所有环境，因此他们应该允许用户从各种安全服务中进行选择，因为不同用户社区的需求不同。
o Parameter and mechanism negotiation should be provided.
o 应提供参数和机制协商。
This document discusses security properties of RSVP and, as such, it is concerned entirely with security.
本文档讨论RSVP的安全属性，因此，它完全涉及安全性。
We would like to thank Jorge Cuellar, Robert Hancock, Xiaoming Fu, Guenther Schaefer, Marc De Vuyst, Bob Grillo, and Jukka Manner for their comments. Additionally, Hannes would like to thank Robert and Jorge for their time discussing various issues.
我们要感谢豪尔赫·奎利亚尔、罗伯特·汉考克、傅晓明、根瑟·谢弗、马克·德维斯特、鲍勃·格里洛和朱卡·韦德的评论。此外，汉内斯还要感谢罗伯特和乔治花时间讨论各种问题。
Finally, we would like to thank Allison Mankin and John Loughney for their guidance and input.
最后，我们要感谢Allison Mankin和John Loughney的指导和投入。
[1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[1] Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[2] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[2] Herzog，S.，“政策控制的RSVP扩展”，RFC 2750，2000年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[4] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[5] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[6] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[6] Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[7] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[7] Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. Obsoleted by RFC 4120.
[8] Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。已被RFC 4120淘汰。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[10] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[10] 达勒姆，D.，博伊尔，J.，科恩，R.，赫尔佐格，S.，拉詹，R.，和A.萨斯特里，“共同开放政策服务协议”，RFC 2748，2000年1月。
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[11] Herzog，S.，Boyle，J.，Cohen，R.，Durham，D.，Rajan，R.，和A.Sastry，“警察对RSVP的使用”，RFC 2749，2000年1月。
[12] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[12] Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[13] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[13] Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[14] Hess, R. and S. Herzog, "RSVP Extensions for Policy Control", Work in Progress, June 2001.
[14] Hess，R.和S.Herzog，“政策控制的RSVP扩展”，正在进行的工作，2001年6月。
[15] "Secure Hash Standard, NIST, FIPS PUB 180-1", Federal Information Processing Society, April 1995.
[15] “安全哈希标准，NIST，FIPS PUB 180-1”，联邦信息处理协会，1995年4月。
[16] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[16] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[17] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[17] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[18] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types", RFC 2495, January 1999.
[18] Fowler，D.，“DS1、E1、DS2和E2接口类型的托管对象定义”，RFC 2495，1999年1月。
[19] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[19] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[20] Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress, July 2002.
[20] Hornstein，K.和J.Altman，“使用DNS分发Kerberos KDC和领域信息”，正在进行的工作，2002年7月。
[21] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A strengthened version of RIPEMD in Fast Software Encryption", LNCS vol. 1039, pp. 71-82, 1996.
[21] Dobbertin，H.，Bosselaers，A.，和B.Preneel，“RIPEMD-160：快速软件加密中RIPEMD的强化版本”，LNCS第1039卷，第71-82页，1996年。
[22] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA Laboratories CryptoBytes, vol. 2, no. 2, 1996.
[22] Dobbertin，H.，“最近一次攻击后MD5的状态”，RSA实验室加密字节，第2卷，第2期，1996年。
[23] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[23] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[24] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[24] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[25] "Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems", April 2000.
[25] “适用于Microsoft Windows 2000操作系统的Microsoft授权数据规范v.1.0”，2000年4月。
[26] Cable Television Laboratories, Inc., "PacketCable Security Specification, PKT-SP-SEC-I01-991201", website: http://www.PacketCable.com/, June 2003.
[26] 有线电视实验室有限公司，“打包电缆安全规范，PKT-SP-SEC-I01-991201”，网站：http://www.PacketCable.com/，2003年6月。
[27] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[27] 迈尔斯，M.，安克尼，R.，马尔帕尼，A.，加尔佩林，S.，和C.亚当斯，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC2560，1999年6月。
[28] Malpani, A., Housley, R., and T. Freeman, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, October 2005.
[28] Malpani，A.，Housley，R.，和T.Freeman，“简单证书验证协议（SCVP）”，正在进行的工作，2005年10月。
[29] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[29] Housley，R.，“加密消息语法（CMS）”，RFC3369，2002年8月。
[30] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[30] Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[31] "Specifications and standard documents", website: http://www.PacketCable.com/, March 2002.
[31] “规范和标准文件”，网站：http://www.PacketCable.com/，2002年3月。
[32] Davis, D. and D. Geer, "Kerberos With Clocks Adrift: History, Protocols and Implementation", USENIX Computing Systems, vol 9 no. 1, Winter 1996.
[32] Davis，D.和D.Geer，“时钟漂移的Kerberos：历史、协议和实现”，USENIX计算系统，第9卷第1期，1996年冬季。
[33] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[33] Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[34] Tschofenig, H., Buechli, M., Van den Bosch, S., and H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
[34] Tschofenig，H.，Buechli，M.，Van den Bosch，S.，和H.Schulzrinne，“NSIS认证、授权和会计问题”，正在进行的工作，2003年3月。
[35] Tschofenig, H., Buechli, M., Van den Bosch, S., Schulzrinne, H., and T. Chen, "QoS NSLP Authorization Issues", Work in Progress, June 2003.
[35] Tschofenig，H.，Buechli，M.，Van den Bosch，S.，Schulzrinne，H.，和T.Chen，“QoS NSLP授权问题”，正在进行的工作，2003年6月。
[36] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", Work in Progress, October 2002.
[36] Thomas，M.，“移动IP和RSVP交互的分析”，正在进行的工作，2002年10月。
[37] Gai, S., Gaitonde, S., Elfassy, N., and Y. Bernet, "RSVP Proxy", Work in Progress, March 2002.
[37] Gai，S.，Gaitonde，S.，Elfasse，N.，和Y.Bernet，“RSVP代理”，正在进行的工作，2002年3月。
[38] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., and K. Raatikainen, "Localized RSVP", Work in Progress, September 2004.
[38] Way，J.，Suiko，T.，Kojo，M.，Liljeberg，M.，和K.Raatikainen，“本地化RSVP”，正在进行的工作，2004年9月。
[39] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[39] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[40] Thomas, M., "Kerberized Internet Negotiation of Keys (KINK)", Work in Progress, October 2005.
[40] Thomas，M.“Kerberized Internet密钥协商（扭结）”，正在进行的工作，2005年10月。
[41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, November 2005.
[41] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年11月。
[42] Herzog, S., "Accounting and Access Control in RSVP", PhD Dissertation, USC, Work in Progress, November 1995.
[42] Herzog，S.，“RSVP中的会计和访问控制”，南加州大学博士论文，进展中的工作，1995年11月。
[43] Herzog, S., "Accounting and Access Control for Multicast Distributions: Models and Mechanisms", June 1996.
[43] Herzog，S.，“多播分发的记帐和访问控制：模型和机制”，1996年6月。
[44] Pato, J., "Using Pre-Authentication to Avoid Password Guessing Attacks", Open Software Foundation DCE Request for Comments, December 1992.
[44] Pato，J，“使用预认证，以避免密码猜测攻击”，开放软件基金会DCE请求评论，1992年12月。
[45] Tung, B. and L. Zhu, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, November 2005.
[45] Tung，B.和L.Zhu，“Kerberos中用于初始身份验证的公钥加密”，正在进行的工作，2005年11月。
[46] Wu, T., "A Real-World Analysis of Kerberos Password Security", in Proceedings of the 1999 Internet Society Network and Distributed System Security Symposium, San Diego, February 1999.
[46] Wu，T.，“Kerberos密码安全的真实世界分析”，1999年互联网社会网络和分布式系统安全研讨会论文集，圣地亚哥，1999年2月。
[47] Wu, T., Wu, F., and F. Gong, "Securing QoS: Threats to RSVP Messages and Their Countermeasures", IEEE IWQoS, pp. 62-64, 1999.
[47] Wu，T.，Wu，F.，和F.Gong，“保护QoS：对RSVP消息的威胁及其对策”，IEEE IWQoS，第62-64页，1999年。
[48] Talwar, V., Nahrstedt, K., and F. Gong, "Securing RSVP For Multimedia Applications", Proc ACM Multimedia 2000 (Multimedia Security Workshop), November 2000.
[48] Talwar，V.，Nahrstedt，K.，和F.Gong，“多媒体应用的RSVP安全”，Proc ACM Multimedia 2000（多媒体安全研讨会），2000年11月。
[49] Talwar, V., Nahrstedt, K., and S. Nath, "RSVP-SQoS: A Secure RSVP Protocol", International Conf on Multimedia and Exposition, Tokyo, Japan, August 2001.
[49] Talwar，V.，Nahrstedt，K.，和S.Nath，“RSVP SQoS：一个安全的RSVP协议”，国际多媒体和博览会会议，日本东京，2001年8月。
[50] Jablon, D., "Strong Password-only Authenticated Key Exchange", ACM Computer Communication Review, 26(5), pp. 5-26, October 1996.
[50] Jablon，D.，“仅强密码认证密钥交换”，ACM计算机通信评论，26（5），第5-26页，1996年10月。
Kerberos might be used with RSVP as described in this document. Because dictionary attacks are often mentioned in relationship with Kerberos, a few issues are addressed here.
Kerberos可能与本文档中描述的RSVP一起使用。由于经常提到字典攻击与Kerberos的关系，因此这里将讨论几个问题。
The initial Kerberos AS_REQ request (without pre-authentication, without various extensions, and without PKINIT) is unprotected. The response message AS_REP is encrypted with the client's long-term key. An adversary can take advantage of this fact by requesting AS_REP messages to mount an off-line dictionary attack. Pre-authentication ([44]) can be used to reduce this problem. However, pre-authentication does not entirely prevent dictionary attacks by an adversary who can still eavesdrop on Kerberos messages along the path between a mobile node and a KDC. With mandatory pre-authentication for the initial request, an adversary cannot request a Ticket Granting Ticket for an arbitrary user. On-line password guessing attacks are still possible by choosing a password (e.g., from a dictionary) and then transmitting an initial request that includes a pre-authentication data field. An unsuccessful authentication by the KDC results in an error message and thus gives the adversary a hint to restart the protocol and try a new password.
初始Kerberos AS_REQ请求（无预身份验证、无各种扩展和无PKINIT）不受保护。响应消息AS_REP使用客户端的长期密钥加密。对手可以通过请求AS_REP消息发起离线字典攻击来利用这一事实。预认证（[44]）可用于减少此问题。但是，预身份验证并不能完全防止敌方的字典攻击，因为敌方仍然可以沿着移动节点和KDC之间的路径窃听Kerberos消息。对于初始请求的强制预验证，对手无法为任意用户请求票据授予票据。通过选择密码（例如，从字典中），然后发送包含预认证数据字段的初始请求，仍然可以进行在线密码猜测攻击。KDC验证失败会导致错误消息，从而提示对手重新启动协议并尝试新密码。
There are, however, some proposals that prevent dictionary attacks. The use of Public Key Cryptography for initial authentication [45] (PKINIT) is one such solution. Other proposals use strong-password-based authenticated key agreement protocols to protect the user's password during the initial Kerberos exchange. [46] discusses the security of Kerberos and also discusses mechanisms to prevent dictionary attacks.
然而，有一些建议可以防止字典攻击。使用公钥加密进行初始身份验证[45]（PKINIT）就是这样一种解决方案。其他建议使用基于强密码的认证密钥协议协议在初始Kerberos交换期间保护用户的密码。[46]讨论了Kerberos的安全性，还讨论了防止字典攻击的机制。
The following Section describes an example of user-to-PDP authentication. Note that the description below is not fully covered by the RSVP specification and hence it should only be viewed as an example.
以下部分描述了用户到PDP身份验证的示例。请注意，RSVP规范并未完全涵盖以下描述，因此仅应将其视为示例。
Windows 2000, which integrates Kerberos into RSVP, uses a configuration with the user authentication to the PDP as described in [25]. The steps for authenticating the user to the PDP in an intra-realm scenario are the following:
将Kerberos集成到RSVP中的Windows 2000使用了一种配置，该配置具有[25]中所述的对PDP的用户身份验证。在域内场景中向PDP验证用户的步骤如下：
o Windows 2000 requires the user to contact the KDC and to request a Kerberos service ticket for the PDP account AcsService in the local realm.
o Windows 2000要求用户联系KDC并为本地域中的PDP帐户AcsService请求Kerberos服务票证。
o This ticket is then embedded into the AUTH_DATA element and included in either the PATH or the RESV message. In the case of Microsoft's implementation, the user identity encoded as a distinguished name is encrypted with the session key provided with the Kerberos ticket. The Kerberos ticket is sent without the Kerberos authdata element that contains authorization information, as explained in [25].
o 然后，该票证被嵌入到AUTH_数据元素中，并包含在PATH或RESV消息中。在Microsoft的实现中，编码为可分辨名称的用户标识使用Kerberos票证提供的会话密钥进行加密。Kerberos票证在发送时没有包含授权信息的Kerberos authdata元素，如[25]中所述。
o The RSVP message is then intercepted by the PEP, which forwards it to the PDP. [25] does not state which protocol is used to forward the RSVP message to the PDP.
o 然后，政治公众人物拦截RSVP消息，并将其转发给PDP。[25]未说明用于将RSVP消息转发至PDP的协议。
o The PDP that finally receives the message and decrypts the received service ticket. The ticket contains the session key used by the user's host to
o 最终接收消息并解密接收到的服务票证的PDP。票证包含用户的主机用于访问的会话密钥
* Encrypt the principal name inside the policy locator field of the AUTH_DATA object and to
* 在AUTH_数据对象的策略定位器字段内加密主体名称并
* Create the integrity-protected Keyed Message Digest field in the INTEGRITY object of the POLICY_DATA element. The protection described here is between the user's host and the PDP. The RSVP INTEGRITY object on the other hand is used to protect the path between the user's host and the first-hop router, because the two message parts terminate at different nodes, and different security associations must be used. The interface between the message-intercepting, first-hop router and the PDP must be protected as well.
* 在POLICY_数据元素的integrity对象中创建integrity protected Keyed Message Digest字段。此处描述的保护在用户主机和PDP之间。另一方面，RSVP INTEGRITY对象用于保护用户主机和第一跳路由器之间的路径，因为这两个消息部分终止于不同的节点，并且必须使用不同的安全关联。消息拦截、第一跳路由器和PDP之间的接口也必须受到保护。
* The PDP does not maintain a user database, and [25] describes how the PDP may query the Active Directory (a LDAP based directory service) for user policy information.
* PDP不维护用户数据库，[25]描述了PDP如何查询Active Directory（基于LDAP的目录服务）以获取用户策略信息。
Few documents address the security of RSVP signaling. This section briefly describes some important documents.
很少有文件涉及RSVP信令的安全性。本节简要介绍一些重要文件。
Improvements to RSVP are proposed in [47] to deal with insider attacks. Insider attacks are caused by malicious RSVP routers that modify RSVP signaling messages in such a way that they cause harm to the nodes participating in the signaling message exchange.
[47]中建议对RSVP进行改进，以应对内部攻击。内部攻击是由恶意RSVP路由器引起的，这些路由器修改RSVP信令消息，从而对参与信令消息交换的节点造成伤害。
As a solution, non-mutable RSVP objects are digitally signed by the sender. This digital signature is added to the RSVP PATH message. Additionally, the receiver attaches an object to the RSVP RESV message containing a "signed" history. This value allows
作为解决方案，不可变的RSVP对象由发送方进行数字签名。此数字签名将添加到RSVP路径消息中。此外，接收方将对象附加到包含“已签名”历史记录的RSVP RESV消息。此值允许
intermediate RSVP routers (by examining the previously signed value) to detect a malicious RSVP node.
中间RSVP路由器（通过检查先前签名的值）来检测恶意RSVP节点。
A few issues are, however, left open in this document. Replay attacks are not covered, and it is therefore assumed that timestamp-based replay protection is used. To identify a malicious node, it is necessary that all routers along the path are able to verify the digital signature. This may require a global public key infrastructure and also client-side certificates. Furthermore, the bandwidth and computational requirements to compute, transmit, and verify digital signatures for each signaling message might place a burden on a real-world deployment.
然而，本文件中有几个问题尚未解决。不包括重播攻击，因此假定使用基于时间戳的重播保护。要识别恶意节点，路径上的所有路由器都必须能够验证数字签名。这可能需要一个全局公钥基础设施和客户端证书。此外，计算、传输和验证每个信令消息的数字签名的带宽和计算要求可能会给实际部署带来负担。
Authorization is not considered in the document, which might have an influence on the implications of signaling message modification. Hence, the chain-of-trust relationship (or this step in a different direction) should be considered in relationship with authorization.
文档中未考虑授权，这可能会影响信令消息修改的含义。因此，信任链关系（或另一个方向的这一步骤）应该与授权联系起来考虑。
In [48], the above-described idea of detecting malicious RSVP nodes is improved by addressing performance aspects. The proposed solution is somewhere between hop-by-hop security and the approach in [47], insofar as it separates the end-to-end path into individual networks. Furthermore, some additional RSVP messages (e.g., feedback messages) are introduced to implement a mechanism called "delayed integrity checking." In [49], the approach presented in [48] is enhanced.
在[48]中，通过解决性能方面的问题，改进了上述检测恶意RSVP节点的思想。建议的解决方案介于逐跳安全性和[47]中的方法之间，因为它将端到端路径分离为单独的网络。此外，还引入了一些额外的RSVP消息（例如，反馈消息）来实现一种称为“延迟完整性检查”的机制。在[49]中，对[48]中介绍的方法进行了增强。
Authors' Addresses
作者地址
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环汉内斯·茨霍芬尼西门子奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 USA
Richard Graveman RFG安全美国新泽西州莫里斯镇公园大道15号07960
EMail: rfg@acm.org
EMail: rfg@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。