Internet Engineering Task Force (IETF) M. Behringer
Request for Comments: 6411 F. Le Faucheur
Category: Informational B. Weis
ISSN: 2070-1721 Cisco Systems
October 2011
Internet Engineering Task Force (IETF) M. Behringer
Request for Comments: 6411 F. Le Faucheur
Category: Informational B. Weis
ISSN: 2070-1721 Cisco Systems
October 2011
Applicability of Keying Methods for RSVP Security
RSVP安全的密钥方法的适用性
Abstract
摘要
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages.
资源预留协议（RSVP）允许逐跳保护RSVP邻居的完整性。这需要使用参与节点之间的共享秘密对消息进行加密保护。本文档将RSVP的组键控与每邻居或每接口键控进行了比较，并讨论了相关的密钥提供方法以及这些方法的适用性和局限性。本文档还讨论了加密RSVP消息的适用性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6411.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6411.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 4
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Per-Interface and Per-Neighbor Keys . . . . . . . . . . . 5
3.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8
4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Per-Neighbor and Per-Interface Key Negotiation . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 12
7. End-Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . . 16
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The RSVP Hop-by-Hop Trust Model . . . . . . . . . . . . . . . 4
3. Applicability of Key Types for RSVP . . . . . . . . . . . . . 5
3.1. Per-Interface and Per-Neighbor Keys . . . . . . . . . . . 5
3.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Provisioning Methods for RSVP . . . . . . . . . . . . . . 8
4.1. Static Key Provisioning . . . . . . . . . . . . . . . . . 8
4.2. Dynamic Keying . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Per-Neighbor and Per-Interface Key Negotiation . . . . 8
4.2.2. Dynamic Group Key Distribution . . . . . . . . . . . . 8
5. Specific Cases Supporting Use of Group Keying . . . . . . . . 9
5.1. RSVP Notify Messages . . . . . . . . . . . . . . . . . . . 9
5.2. RSVP-TE and GMPLS . . . . . . . . . . . . . . . . . . . . 9
6. Applicability of IPsec for RSVP . . . . . . . . . . . . . . . 10
6.1. General Considerations Using IPsec . . . . . . . . . . . . 10
6.2. Comparing AH and the INTEGRITY Object . . . . . . . . . . 11
6.3. Applicability of Tunnel Mode . . . . . . . . . . . . . . . 11
6.4. Non-Applicability of Transport Mode . . . . . . . . . . . 12
6.5. Applicability of Tunnel Mode with Address Preservation . . 12
7. End-Host Considerations . . . . . . . . . . . . . . . . . . . 13
8. Applicability to Other Architectures and Protocols . . . . . . 14
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Subverted Nodes . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . . 16
The Resource reSerVation Protocol [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747]. In this mode, an integrity object is attached to each RSVP message to transmit a keyed message digest. This message digest allows the recipient to verify the identity of the RSVP node that sent the message and to validate the integrity of the message. Through the inclusion of a sequence number in the scope of the digest, the digest also offers replay protection.
资源预留协议[RFC2205]允许对RSVP邻居进行逐跳身份验证，如[RFC2747]中所述。在此模式下，完整性对象附加到每个RSVP消息，以传输密钥消息摘要。此消息摘要允许收件人验证发送消息的RSVP节点的身份，并验证消息的完整性。通过在摘要范围中包含序列号，摘要还提供了重播保护。
[RFC2747] does not dictate how the key for the integrity operation is derived. Currently, most implementations of RSVP use a statically configured key, per interface or per neighbor. However, to manually configure a key per router pair across an entire network is operationally hard, especially when key changes are to be performed on a regular basis. Effectively, many users of RSVP therefore resort to using the same key throughout their RSVP network, and they change it rarely, if ever, because of the operational burden. However, it is often necessary to change keys due to network operational requirements (e.g., change of operational staff).
[RFC2747]不规定完整性操作的密钥如何派生。目前，RSVP的大多数实现使用静态配置的密钥，每个接口或每个邻居。然而，在整个网络中手动配置每个路由器对的密钥在操作上是困难的，特别是当需要定期执行密钥更改时。实际上，许多RSVP用户因此在整个RSVP网络中使用相同的密钥，并且由于操作负担，他们很少更改密钥。但是，由于网络运营需求（例如，运营人员的变更），通常需要更改密钥。
This document discusses a variety of keying methods and their applicability to different RSVP deployment environments, for both message integrity and encryption. It is meant as a comparative guide to understand where each RSVP keying method is best deployed and the limitations of each method. Furthermore, it discusses how RSVP hop-by-hop authentication is impacted in the presence of non-RSVP nodes, or subverted nodes, in the reservation path.
本文档讨论了各种密钥方法及其对不同RSVP部署环境的适用性，包括消息完整性和加密。这是一个比较指南，旨在了解每个RSVP键控方法的最佳部署位置以及每个方法的局限性。此外，还讨论了在保留路径中存在非RSVP节点或被颠覆节点时，RSVP逐跳身份验证是如何受到影响的。
"RSVP Security Properties" ([RFC4230]) provides an overview of RSVP security, including RSVP Cryptographic Authentication [RFC2747], but does not discuss key management. It states that "RFC 2205 assumes that security associations are already available". The present document focuses specifically on key management with different key types, including group keys. Therefore, this document complements [RFC4230].
“RSVP安全属性”（[RFC4230]）概述了RSVP安全性，包括RSVP加密身份验证[RFC2747]，但未讨论密钥管理。它指出，“RFC 2205假定安全关联已经可用”。本文件特别关注具有不同密钥类型（包括组密钥）的密钥管理。因此，本文件是对[RFC4230]的补充。
A security domain is defined in this document as two or more nodes that share a common RSVP security policy.
安全域在本文档中定义为共享公共RSVP安全策略的两个或多个节点。
When a key is mentioned in this document, it is a symmetric key. A symmetric key best meets the operational requirements of RSVP deployments and is the only type of key currently explicitly supported for protecting RSVP messages.
本文档中提到的密钥是对称密钥。对称密钥最符合RSVP部署的操作要求，是目前明确支持用于保护RSVP消息的唯一密钥类型。
Many protocol security mechanisms used in networks require and use per-peer authentication. Each hop authenticates messages from its neighbor with a shared key or certificate. This is also the model used for RSVP. Trust in this model is transitive. Each RSVP node trusts explicitly only its RSVP next-hop peers, through the message digest contained in the INTEGRITY object. The next-hop RSVP speaker in turn trusts its own peers and so on. See also "RSVP Security Properties" [RFC4230] for more background.
网络中使用的许多协议安全机制需要并使用每对等身份验证。每个跃点使用共享密钥或证书对来自其邻居的消息进行身份验证。这也是RSVP使用的模型。该模型中的信任是可传递的。通过INTEGRITY对象中包含的消息摘要，每个RSVP节点仅显式信任其RSVP下一跳对等节点。下一跳RSVP演讲者反过来信任自己的对等者，以此类推。有关更多背景信息，请参见“RSVP安全属性”[RFC4230]。
The keys used for protecting RSVP messages can, in particular, be group keys (for example, distributed via the Group Domain of Interpretation (GDOI) [RFC6407], as discussed in [GDOI-MAC]). If a group key is used, the authentication granularity becomes group membership of devices, not (individual) peer authentication between devices.
用于保护RSVP消息的密钥尤其可以是组密钥（例如，如[GDOI-MAC]中所述，通过组解释域（GDOI）[RFC6407]分发）。如果使用组密钥，身份验证粒度将成为设备的组成员身份，而不是设备之间的（单个）对等身份验证。
The trust an RSVP node has to another RSVP node within a common security domain has an explicit and an implicit component. Explicitly, the node trusts the other node to maintain the RSVP messages intact or confidential, depending on whether authentication or encryption (or both) is used. This means only that the message has not been altered or seen by another, non-trusted node. Implicitly, each node trusts the other node to maintain the level of protection specified within that security domain. In any group-keying scheme like GDOI, a node trusts all the other members of the group (because the authentication is now based on group membership, as noted above).
一个RSVP节点对公共安全域内另一个RSVP节点的信任具有显式和隐式组件。明确地说，该节点信任另一个节点保持RSVP消息的完整性或机密性，这取决于使用的是身份验证还是加密（或两者都使用）。这只意味着消息没有被另一个不受信任的节点更改或看到。隐式地，每个节点都信任另一个节点来维持该安全域中指定的保护级别。在任何像GDOI这样的组密钥方案中，节点信任组的所有其他成员（因为认证现在基于组成员身份，如上所述）。
The RSVP protocol can operate in the presence of a non-RSVP router in the path from the sender to the receiver. The non-RSVP hop will ignore the RSVP message and just pass it along. The next RSVP node can then process the RSVP message. For RSVP authentication or encryption to work in this case, the key used for computing the RSVP message digest needs to be shared by the two RSVP neighbors, even if they are not IP neighbors. In the presence of non-RSVP hops, while an RSVP node always knows the next IP hop before forwarding an RSVP message, it does not always know the RSVP next hop. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, for example, because of a routing change). Thus, the presence of non-RSVP hops impacts operation of RSVP authentication or encryption and may influence the selection of keying approaches.
RSVP协议可以在从发送方到接收方的路径中存在非RSVP路由器的情况下运行。非RSVP跃点将忽略RSVP消息，只传递它。然后，下一个RSVP节点可以处理RSVP消息。要使RSVP身份验证或加密在这种情况下起作用，用于计算RSVP消息摘要的密钥需要由两个RSVP邻居共享，即使它们不是IP邻居。在存在非RSVP跃点的情况下，虽然RSVP节点在转发RSVP消息之前总是知道下一个IP跃点，但并不总是知道RSVP下一个跃点。事实上，路径消息的一部分作用正是发现RSVP下一跳（并在它改变时动态地重新发现它，例如，由于路由改变）。因此，非RSVP跳的存在影响RSVP认证或加密的操作，并且可能影响键控方法的选择。
Figure 1 illustrates this scenario. R2 in this picture does not participate in RSVP; the other nodes do. In this case, R2 will pass on any RSVP messages unchanged and will ignore them.
图1说明了这个场景。图中R2不参与RSVP；其他节点可以。在这种情况下，R2将不加更改地传递任何RSVP消息，并将忽略它们。
----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
----R3---
/ \
sender----R1---R2(*) R4----receiver
\ /
----R5---
(*) Non-RSVP hop
（*）非RSVP跳
Figure 1: A Non-RSVP Node in the Path
图1：路径中的非RSVP节点
This creates a challenge for RSVP authentication and encryption. In the presence of a non-RSVP hop, with some RSVP messages such as a PATH message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. For example, in Figure 1, R1 knows that the next IP hop for a Path message addressed to the receiver is R2, but it does not necessarily know if the RSVP next hop is R3 or R5. This means that per-interface and per-neighbor keys cannot easily be used in the presence of non-RSVP routers on the path between senders and receivers.
这给RSVP身份验证和加密带来了挑战。在存在非RSVP跃点的情况下，对于一些RSVP消息（如路径消息），RSVP路由器在转发该消息时不知道该消息的RSVP下一跳。例如，在图1中，R1知道寻址到接收器的路径消息的下一个IP跃点是R2，但它不一定知道RSVP下一个跃点是R3还是R5。这意味着，在发送方和接收方之间的路径上存在非RSVP路由器的情况下，无法轻松使用每个接口和每个邻居密钥。
Section 4.3 of [RFC2747] states that "... the receiver MAY initiate an integrity handshake with the sender". If this handshake is taking place, it can be used to determine the identity of the next RSVP hop. In this case, non-RSVP hops can be traversed also using per-interface or per-neighbor keys.
[RFC2747]第4.3节规定“……接收方可发起与发送方的完整性握手”。如果正在进行此握手，则可以使用它来确定下一个RSVP跳的标识。在这种情况下，还可以使用每个接口或每个邻居密钥遍历非RSVP跳。
Group keying will naturally work in the presence of non-RSVP routers. Referring back to Figure 1, with group keying, R1 would use the group key to protect a Path message addressed to the receiver and forwards it to R2. Being a non-RSVP node, R2 will ignore and forward the Path message to R3 or R5 depending on the current shortest path as determined by routing. Whether it is R3 or R5, the RSVP router that receives the Path message will be able to authenticate the message successfully using the group key.
组键控自然会在非RSVP路由器存在的情况下工作。回到图1，使用组键控，R1将使用组键保护发送给接收器的路径消息，并将其转发给R2。作为非RSVP节点，R2将忽略路径消息，并根据路由确定的当前最短路径将其转发到R3或R5。无论是R3还是R5，接收路径消息的RSVP路由器都能够使用组密钥成功地对消息进行身份验证。
Most current RSVP authentication implementations support per-interface RSVP keys. When the interface is point-to-point (and therefore an RSVP router has only a single RSVP neighbor on each interface), this is equivalent to per-neighbor keys in the sense that a different key is used for each neighbor. In the point-to-point case, the security domain is simply between the router and its neighbor. However, when the interface is multipoint, all RSVP speakers on a given subnet have to belong to the same security domain and share the same key in this model. This makes it unsuitable for
大多数当前的RSVP身份验证实现都支持每个接口的RSVP密钥。当接口是点对点（因此RSVP路由器在每个接口上只有一个RSVP邻居）时，这相当于每邻居密钥，即每个邻居使用不同的密钥。在点对点的情况下，安全域仅位于路由器与其邻居之间。但是，当接口为多点时，给定子网上的所有RSVP扬声器必须属于相同的安全域，并且在此模型中共享相同的密钥。这使得它不适合于任何人
deployment scenarios where nodes from different security domains are present on a subnet, for example, Internet exchange points. In such cases, per-neighbor keys are required, and the security domain is between the router and its neighbor.
来自不同安全域的节点位于子网（例如，Internet交换点）上的部署场景。在这种情况下，需要每个邻居的密钥，安全域位于路由器与其邻居之间。
With per-neighbor keys, each RSVP key is bound to an interface plus a neighbor on that interface. It allows for the existence of different security domains on a single interface and subnet.
使用每邻居密钥，每个RSVP密钥绑定到一个接口以及该接口上的一个邻居。它允许在单个接口和子网上存在不同的安全域。
Per-interface and per-neighbor keys can be used within a single security domain.
每个接口和每个邻居的密钥可以在单个安全域中使用。
These key types can also be used between security domains, since they are specific to a particular interface or neighbor.
这些密钥类型也可以在安全域之间使用，因为它们特定于特定接口或邻居。
Both monotonically increasing sequence number (e.g., the INTEGRITY object simple sequence numbers [RFC2747], or the Encapsulating Security Payload (ESP) and Authentication Header (AH) anti-replay service [RFC4301] sequence numbers) and time-based anti-replay methods (e.g., the INTEGRITY sequence numbers based on a clock [RFC2747]) can be used with per-neighbor and per-interface keys.
单调递增的序列号（例如，完整性对象简单序列号[RFC2747]，或封装安全有效载荷（ESP）和认证头（AH）反重放服务[RFC4301]序列号）和基于时间的反重放方法（例如，基于时钟的完整性序列号[RFC2747]）可与每个邻居和每个接口键一起使用。
As discussed in the previous section, per-neighbor and per-interface keys can not be used in the presence of non-RSVP hops.
如前一节所述，在存在非RSVP跳时，不能使用每邻居和每接口密钥。
In the case of group keys, all members of a group of RSVP nodes share the same key. This implies that a node uses the same key regardless of the next RSVP hop that will process the message (within the group of nodes sharing the particular key). It also implies that a node will use the same key on the receiving as on the sending side (when exchanging RSVP messages within the group).
对于组密钥，一组RSVP节点的所有成员共享同一个密钥。这意味着节点使用相同的密钥，而不管下一个RSVP跳将处理消息（在共享特定密钥的节点组内）。它还意味着节点将在接收端使用与发送端相同的密钥（在组内交换RSVP消息时）。
Group keys apply naturally to intra-domain RSVP authentication, where all RSVP nodes are part of the same security domain and implicitly trust each other. The nodes also extended trust to a group key server (GKS), which administers group membership and provides group keys. This is represented in Figure 2.
组密钥自然适用于域内RSVP身份验证，其中所有RSVP节点都是同一安全域的一部分，并且彼此隐式信任。这些节点还将信任扩展到组密钥服务器（GKS），该服务器管理组成员资格并提供组密钥。如图2所示。
......GKS1.............
: : : : :
: : : : :
source--R1--R2--R3-----destination
| |
|<-----domain 1----------------->|
......GKS1.............
: : : : :
: : : : :
source--R1--R2--R3-----destination
| |
|<-----domain 1----------------->|
Figure 2: A Group Key Server within a Single Security Domain
图2：单个安全域中的组密钥服务器
A single group key cannot normally be used to cover multiple security domains because, by definition, the different domains do not trust each other. They would therefore not be willing to trust the same group key server. For a single group key to be used in several security domains, there is a need for a single group key server, which is trusted by both sides. While this is theoretically possible, in practice it is unlikely that there is a single such entity trusted by both domains. Figure 3 illustrates this setup.
单个组密钥通常不能用于覆盖多个安全域，因为根据定义，不同的域彼此不信任。因此，他们不愿意信任同一个组密钥服务器。对于要在多个安全域中使用的单个组密钥，需要一个双方都信任的单个组密钥服务器。虽然这在理论上是可能的，但在实践中，两个域都不可能信任一个这样的实体。图3说明了此设置。
...............GKS1....................
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
...............GKS1....................
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
Figure 3: A Single Group Key Server across Security Domains
图3：跨安全域的单个组密钥服务器
A more practical approach for RSVP operation across security domains, is to use a separate group key server for each security domain, and to use per-interface or per-neighbor keys between the two domains (thus comprising a third security domain). Figure 4 shows this setup.
跨安全域的RSVP操作的更实际的方法是，为每个安全域使用单独的组密钥服务器，并在两个域之间使用每个接口或每个邻居密钥（因此包括第三个安全域）。图4显示了此设置。
....GKS1...... ....GKS2.........
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
|<-->|
domain 3
....GKS1...... ....GKS2.........
: : : : : : : :
: : : : : : : :
source--R1--R2--R3--------R4--R5--R6--destination
| | | |
|<-----domain 1--->| |<-------domain 2----->|
|<-->|
domain 3
Figure 4: A Group Key Server per Security Domain
图4：每个安全域的组密钥服务器
As discussed in Section 2, group keying can be used in the presence of non-RSVP hops.
如第2节所述，组键控可在存在非RSVP跳时使用。
Because a group key may be used to verify messages from different peers, monotonically increasing sequence number methods are not appropriate. Time-based anti-replay methods (e.g., the INTEGRITY sequence numbers based on a clock [RFC2747]) can be used with group keys.
由于组密钥可用于验证来自不同对等方的消息，因此单调递增的序列号方法是不合适的。基于时间的反重放方法（例如，基于时钟的完整性序列号[RFC2747]）可与组密钥一起使用。
Static keys are preconfigured, either manually or through a network management system. The simplest way to implement RSVP authentication is to use static keys. Static keying can be used with per-interface keys, per-neighbor keys, or group keys.
静态密钥可以手动或通过网络管理系统预配置。实现RSVP身份验证的最简单方法是使用静态密钥。静态键控可以与每个接口键、每个邻居键或组键一起使用。
The provisioning of static keys requires either manual operator intervention on each node or a network management system performing the same task. Time synchronization of static key provisioning and changes is critical in order to avoid inconsistent keys within a security domain.
提供静态密钥需要操作员对每个节点进行手动干预，或者需要网络管理系统执行相同的任务。为了避免安全域中的密钥不一致，静态密钥设置和更改的时间同步至关重要。
Static key provisioning is therefore not an ideal model in a large network.
因此，在大型网络中，静态密钥供应不是理想的模型。
Often, the number of interconnection points across two domains where RSVP is allowed to transit is relatively small and well controlled. Also, the different domains may not be in a position to use an infrastructure trusted by both domains to update keys on both sides. Thus, statically provisioned keys may be applicable to inter-domain RSVP authentication.
通常，允许RSVP传输的跨两个域的互连点数量相对较少且控制良好。另外，不同的域可能无法使用两个域都信任的基础结构来更新双方的密钥。因此，静态配置的密钥可适用于域间RSVP认证。
Since it is not feasible to carry out a key change at the exact same time in communicating RSVP nodes, some grace period needs to be implemented during which an RSVP node will accept both the old and the new key. Otherwise, RSVP operation would suffer interruptions. (Also with dynamic keying approaches, there can be a grace period where two keys are valid at the same time; however, the grace period in manual keying tends to be significantly longer than with dynamic key rollover schemes.)
由于在通信RSVP节点的同时执行密钥更改是不可行的，因此需要实施一些宽限期，在此期间RSVP节点将同时接受旧密钥和新密钥。否则，RSVP操作将中断。（同样，对于动态键控方法，两个键同时有效时可能会有一个宽限期；但是，手动键控的宽限期往往比动态键翻转方案的宽限期长得多。）
To avoid the problem of manual key provisioning and updates in static key deployments, key negotiation between RSVP neighbors could be used to derive either per-interface or per-neighbor keys.
为了避免静态密钥部署中的手动密钥设置和更新问题，可以使用RSVP邻居之间的密钥协商来派生每个接口或每个邻居的密钥。
With this approach, group keys are dynamically distributed among a set of RSVP routers. For example, [GDOI-MAC] describes a mechanism to distribute group keys to a group of RSVP speakers, using GDOI [RFC6407]. In this solution, each RSVP node requests a group key
通过这种方法，组密钥在一组RSVP路由器之间动态分布。例如，[GDOI-MAC]描述了使用GDOI[RFC6407]将组密钥分发给一组RSVP扬声器的机制。在此解决方案中，每个RSVP节点请求一个组密钥
from a key server as part of an encrypted and integrity-protected key agreement protocol. Once the key server has authenticated and authorized the RSVP nodes, it distributes a group key to the group member. The authentication in this model can be based on public key mechanisms, thereby avoiding the need for static key provisioning.
来自密钥服务器，作为加密和完整性保护密钥协议的一部分。密钥服务器对RSVP节点进行身份验证和授权后，将向组成员分发组密钥。该模型中的身份验证可以基于公钥机制，从而避免了静态密钥提供的需要。
[RFC3473] introduces the Notify message and allows such messages to be sent in a non-hop-by-hop fashion. As discussed in the Security Considerations section of [RFC3473], this can interfere with RSVP's hop-by-hop integrity and authentication model. [RFC3473] describes how standard IPsec-based integrity and authentication can be used to protect Notify messages.
[RFC3473]引入Notify消息，并允许以非逐跳方式发送此类消息。如[RFC3473]的安全注意事项部分所述，这可能会干扰RSVP的逐跳完整性和身份验证模型。[RFC3473]描述了如何使用标准的基于IPsec的完整性和身份验证来保护Notify消息。
Group keying may allow use of regular RSVP authentication [RFC2747] for protection of non-hop-by-hop Notify messages. For example, RSVP Notify messages commonly used for traffic engineering in MPLS networks are non-hop-by-hop messages. Such messages may be sent from an ingress node directly to an egress node. Group keying in such a case avoids the establishment of node-to-node keying when node-to-node keying is not otherwise used.
组密钥可允许使用常规RSVP身份验证[RFC2747]来保护非逐跳通知消息。例如，MPLS网络中常用于流量工程的RSVP Notify消息是非逐跳消息。这样的消息可以从入口节点直接发送到出口节点。在这种情况下，组键控可避免在不使用节点到节点键控时建立节点到节点键控。
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Reroute [RFC4090] deserves additional considerations.
对RSVP-TE[RFC3209]和RSVP-TE快速重路由[RFC4090]使用RSVP身份验证值得额外考虑。
With the facility backup method of Fast Reroute, a backup tunnel from the Point of Local Repair (PLR) to the Merge Point (MP) is used to protect Label Switched Paths (protected LSPs) against the failure of a facility (e.g., a router) located between the PLR and the MP. During the failure of the facility, the PLR redirects a protected LSP inside the backup tunnel and as a result, the PLR and MP then need to exchange RSVP control messages between each other (e.g., for the maintenance of the protected LSP). Some of the RSVP messages between the PLR and MP are sent over the backup tunnel (e.g., a Path message from PLR to MP), while some are directly addressed to the RSVP node (e.g., a Resv message from MP to PLR). During the rerouted period, the PLR and the MP effectively become RSVP neighbors, while they may not be directly connected to each other and thus do not behave as RSVP neighbors in the absence of failure. This point is raised in the Security Considerations section of [RFC4090] that says: "Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other". Such environments may benefit from group keying. A group key can be used
对于快速重路由的设施备份方法，使用从本地修复点（PLR）到合并点（MP）的备份隧道来保护标签交换路径（受保护的LSP），防止位于PLR和MP之间的设施（例如路由器）发生故障。在设施故障期间，PLR在备份隧道内重定向受保护的LSP，因此，PLR和MP需要在彼此之间交换RSVP控制消息（例如，为了维护受保护的LSP）。PLR和MP之间的一些RSVP消息通过备份隧道发送（例如，从PLR到MP的路径消息），而一些直接发送到RSVP节点（例如，从MP到PLR的Resv消息）。在重新路由期间，PLR和MP实际上成为RSVP邻居，而它们可能不直接彼此连接，因此在没有故障的情况下不会表现为RSVP邻居。[RFC4090]的“安全注意事项”一节中提出了这一点，其中指出：“请注意，设施备份方法要求PLR及其所选合并点信任从彼此接收的RSVP消息”。这样的环境可能受益于组键控。可以使用组密钥
among a set of routers enabled for Fast Reroute, thereby easily ensuring that PLR and MP authenticate messages from each other, without requiring prior specific configuration of keys, or activation of key update mechanism, for every possible pair of PLR and MP.
在为快速重路由启用的一组路由器中，从而容易地确保PLR和MP对来自彼此的消息进行身份验证，而无需针对每个可能的PLR和MP对事先特定的密钥配置或密钥更新机制的激活。
Where RSVP-TE or RSVP-TE Fast Reroute is deployed across AS boundaries (see [RFC4216]), the considerations presented above in Sections 3.1 and 3.2 apply, such that per-interface or per-neighbor keys can be used between two RSVP neighbors in different ASes (independently of the keying method used by the RSVP router to talk to the RSVP routers in the same AS).
如果跨AS边界部署RSVP-TE或RSVP-TE快速重路由（请参见[RFC4216]），则上述第3.1节和第3.2节中的注意事项适用，因此每个接口或每个邻居密钥可在不同ASE中的两个RSVP邻居之间使用（独立于RSVP路由器使用的键控方法，以与相同的方式与RSVP路由器通话）。
[RFC4875] specifies protocol extensions for support of Point-to-Multipoint (P2MP) RSVP-TE. RSVP message integrity mechanisms for hop-by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE signaling (see the Security Considerations in [RFC4875]).
[RFC4875]指定支持点对多点（P2MP）RSVP-TE的协议扩展。逐跳RSVP信令的RSVP消息完整性机制适用于逐跳P2MP RSVP-TE信令（参见[RFC4875]中的安全注意事项）。
[RFC4206] defines LSP Hierarchy with GMPLS TE and uses non-hop-by-hop signaling. Because it reuses LSP Hierarchy procedures for some of its operations, P2MP RSVP-TE also uses non-hop-by-hop signaling. Both LSP hierarchy and P2MP RSVP-TE rely on the security mechanisms defined in [RFC3473] and [RFC4206] for non hop-by-hop RSVP-TE signaling. Group keying can simplify protection of non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP-TE.
[RFC4206]使用GMPLS TE定义LSP层次结构，并使用非逐跳信令。由于P2MP RSVP-TE在某些操作中重用LSP层次结构过程，因此P2MP RSVP-TE也使用非逐跳信令。LSP层次结构和P2MP RSVP-TE都依赖于[RFC3473]和[RFC4206]中为非逐跳RSVP-TE信令定义的安全机制。组键控可以简化LSP层次和P2MP RSVP-TE的非逐跳信令保护。
The discussions about the various keying methods in this document are also applicable when using IPsec [RFC4301] to protect RSVP. Section 1.2 of [RFC2747] states that IPsec is not an optimal choice to protect RSVP. The key argument is that an IPsec security association (SA) and an RSVP SA are not based on the same parameters. Nevertheless, IPsec can be used to protect RSVP. The Security Policy Database (SPD) traffic selectors for related RSVP flows will not be constant. In some cases, the source and destination addresses are end hosts, and sometimes they are RSVP routers. Therefore, traffic selectors in the SPD are expected to specify ANY for the source address and destination addresses, and to specify IP protocol 46 (RSVP).
当使用IPsec[RFC4301]保护RSVP时，本文档中关于各种键控方法的讨论也适用。[RFC2747]第1.2节指出，IPsec不是保护RSVP的最佳选择。关键参数是IPsec安全关联（SA）和RSVP SA基于的参数不同。然而，IPsec可以用来保护RSVP。相关RSVP流的安全策略数据库（SPD）流量选择器将不是常量。在某些情况下，源地址和目标地址是终端主机，有时是RSVP路由器。因此，SPD中的流量选择器应指定源地址和目标地址的任意值，并指定IP协议46（RSVP）。
"The Multicast Group Security Architecture" [RFC3740] defines in detail a "Group Security Association" (GSA). This definition is also applicable in the context discussed here, and allows the use of IPsec for RSVP. The existing GDOI specification [RFC6407] manages group security associations, which can be used by IPsec. An example GDOI
“多播组安全体系结构”[RFC3740]详细定义了“组安全关联”（GSA）。此定义也适用于此处讨论的上下文，并允许将IPsec用于RSVP。现有的GDOI规范[RFC6407]管理可由IPsec使用的组安全关联。一个示例GDOI
policy would be to encrypt or authenticate all packets of the RSVP protocol itself (IP protocol 46). A router implementing GDOI and the AH and/or ESP protocols is therefore able to implement this policy.
策略是加密或验证RSVP协议本身（IP协议46）的所有数据包。因此，实现GDOI和AH和/或ESP协议的路由器能够实现此策略。
Because the traffic selectors for an SA cannot be predicted, SA lookup is expected to use only the Security Parameters Index (SPI) (or SPI plus protocol).
由于无法预测SA的流量选择器，SA查找应仅使用安全参数索引（SPI）（或SPI plus协议）。
The INTEGRITY object defined by [RFC2747] provides integrity protection for RSVP also in a group-keying context, as discussed above. AH [RFC4302] is an alternative method to provide integrity protection for RSVP packets.
[RFC2747]定义的完整性对象也在组键控上下文中为RSVP提供完整性保护，如上所述。AH[RFC4302]是为RSVP数据包提供完整性保护的替代方法。
The RSVP INTEGRITY object protects the entire RSVP message, but does not protect the IP header of the packet nor the IP options (in IPv4) or extension headers (in IPv6).
RSVP INTEGRITY对象保护整个RSVP消息，但不保护数据包的IP头，也不保护IP选项（在IPv4中）或扩展头（在IPv6中）。
AH tunnel mode (transport mode is not applicable; see Section 6.4) protects the entire original IP packet, including the IP header of the original IP packet ("inner header"), IP options or extension headers, plus the entire RSVP packet. It also protects the immutable fields of the outer header.
AH隧道模式（传输模式不适用；参见第6.4节）保护整个原始IP数据包，包括原始IP数据包的IP报头（“内部报头”）、IP选项或扩展报头，以及整个RSVP数据包。它还保护外部标头的不可变字段。
The difference between the two schemes in terms of covered fields is therefore whether the IPv4 header and IP options, or the IPv6 header and extension headers, of the original IP packet are protected (as is the case with AH) or not (as is the case with the INTEGRITY object). Also, AH covers the immutable fields of the outer header.
因此，就覆盖字段而言，这两个方案之间的区别在于原始IP数据包的IPv4报头和IP选项，或IPv6报头和扩展报头是否受到保护（如AH所示）或未受到保护（如完整性对象所示）。此外，AH覆盖了外部标头的不可变字段。
As described in the next section, IPsec tunnel mode cannot be applied for RSVP traffic in the presence of non-RSVP nodes; therefore, the security associations in both cases, AH and INTEGRITY object, are between the same RSVP neighbors. From a keying point of view, both approaches are therefore comparable.
如下一节所述，在存在非RSVP节点的情况下，IPsec隧道模式不能应用于RSVP流量；因此，在这两种情况下，AH和INTEGRITY对象的安全关联都位于相同的RSVP邻居之间。因此，从关键点的角度来看，这两种方法具有可比性。
IPsec tunnel mode encapsulates the original packet, prepending a new IP header plus an ESP or AH sub-header. The entire original packet plus the ESP/AH sub-header is secured. However, in the case of ESP, the new, outer IP header is not cryptographically secured in this process.
IPsec隧道模式封装原始数据包，在新的IP报头加上ESP或AH子报头之前加上前缀。整个原始数据包加上ESP/AH子报头是安全的。但是，对于ESP，新的外部IP报头在此过程中不受加密保护。
Protecting RSVP packets with IPsec tunnel mode works with any of the keying methods described above (per-interface, per-neighbor, or group keying), as long as there are no non-RSVP nodes on the path (however,
只要路径上没有非RSVP节点（但是，
see the group-keying considerations below). For RSVP messages to be visible and considered at each hop, such a tunnel would not cross routers, but each RSVP node would establish a tunnel with each of its peers, effectively leading to link protection.
请参阅下面的组键控注意事项）。为了使RSVP消息在每个跃点可见并被考虑，这样的隧道不会穿过路由器，但每个RSVP节点将与其每个对等节点建立一个隧道，从而有效地实现链路保护。
In the presence of a non-RSVP hop, tunnel mode cannot be applied because a router upstream from a non-RSVP hop does not know the next RSVP hop, and thus cannot apply the correct tunnel header. The same situation applies to a host attached to the network by a non-RSVP-enabled first hop. This is independent of the key type used.
在存在非RSVP跳时，无法应用隧道模式，因为非RSVP跳上游的路由器不知道下一个RSVP跳，因此无法应用正确的隧道头。同样的情况也适用于通过未启用RSVP的第一跳连接到网络的主机。这与使用的键类型无关。
The use of group keying with ESP tunnel mode where a security gateway places a peer security gateway address as the destination of the ESP packet has consequences. In particular, if a man-in-the-middle attacker redirects the ESP-protected reservation to a different security gateway, the receiving security gateway cannot detect that the destination address was changed. However, it has received and will act upon an RSVP reservation that will be routed along an unintended path. Because RSVP routers encountering the RSVP packet path will not be aware that this is an unintended path, they will act upon it, and the resulting RSVP state along both the intended path and unintended path will be incorrect. Therefore, using group keying with ESP tunnel mode is not recommended, unless address preservation is used (see Section 6.5).
在安全网关将对等安全网关地址作为ESP数据包的目的地的情况下，使用ESP隧道模式的组键控会产生后果。特别是，如果中间人攻击者将受ESP保护的保留重定向到其他安全网关，则接收安全网关无法检测到目标地址已更改。但是，它已接收到一个RSVP保留，并将对该保留采取行动，该保留将沿非预期路径路由。由于遇到RSVP数据包路径的RSVP路由器不会意识到这是一条非预期路径，因此它们将对其进行操作，并且沿预期路径和非预期路径产生的RSVP状态将不正确。因此，不建议在ESP隧道模式下使用组键控，除非使用地址保留（见第6.5节）。
IPsec transport mode, as defined in [RFC4303] is not suitable for securing RSVP Path messages, since those messages preserve the original source and destination. [RFC4301] states explicitly that "the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself". This would not be the case for RSVP Path messages.
[RFC4303]中定义的IPsec传输模式不适合保护RSVP路径消息，因为这些消息保留原始源和目标。[RFC4301]明确指出，“只有当源地址（对于出站数据包）或目标地址（对于入站数据包）是属于中间系统本身的地址时，才允许中间系统（例如，安全网关）使用传输模式”。RSVP路径消息的情况并非如此。
When the identity of the next-hop RSVP peer is not known, it is not possible to use a tunnel-endpoint destination address in the tunnel mode outer IP header. Section 3.1 of "Multicast Extensions to the Security Architecture for the Internet Protocol" [RFC5374] defines a new tunnel mode: tunnel mode with address preservation. This mode copies the destination and optionally the source address from the inner header to the outer header. Therefore, the encapsulated packet will have the same destination address as the original packet, and will be normally subject to the same routing decisions. While [RFC5374] is focusing on multicast environments, tunnel mode with
当下一跳RSVP对等方的标识未知时，无法在隧道模式外部IP报头中使用隧道端点目标地址。“互联网协议安全架构的多播扩展”[RFC5374]第3.1节定义了一种新的隧道模式：具有地址保留的隧道模式。此模式将目标地址和源地址从内部标头复制到外部标头（可选）。因此，封装的分组将具有与原始分组相同的目的地地址，并且通常将服从相同的路由决策。[RFC5374]专注于多播环境，而隧道模式
address preservation can be used also to protect unicast traffic in conjunction with group keying. In this tunnel mode, the RSVP speakers act as security gateways because they maintain the original end-system addresses of the RSVP packets in the tunnel mode outer IP header. This addressing scheme is used by RSVP to ensure that the packets continue along the routed path toward the destination end host.
地址保留还可以与组键控一起用于保护单播通信量。在此隧道模式下，RSVP扬声器充当安全网关，因为它们在隧道模式外部IP报头中保留RSVP数据包的原始终端系统地址。RSVP使用此寻址方案来确保数据包沿着路由路径继续向目标端主机发送。
Tunnel mode with address preservation, in conjunction with group keying, allows the use of AH or ESP for protection of RSVP even in cases where non-RSVP nodes have to be traversed. This is because it allows routing of the IPsec-protected packet through the non-RSVP nodes in the same way as if it were not IPsec protected.
具有地址保留的隧道模式，结合组键控，允许使用AH或ESP保护RSVP，即使在必须遍历非RSVP节点的情况下也是如此。这是因为它允许IPsec保护的数据包通过非RSVP节点进行路由，就像它没有IPsec保护一样。
When used with group keying, tunnel mode with address preservation can be used to mitigate redirection attacks where a man-in-the-middle modifies the destination of the outer IP header of the tunnel mode packet. The inbound processing rules for tunnel mode with address preservation (Section 5.2 of [RFC5374]) require that the receiver verify that the addresses in the outer IP header and the inner IP header are consistent. Therefore, the attack can be detected, and RSVP reservations will not proceed along an unintended path.
当与组键控一起使用时，具有地址保留的隧道模式可用于减轻重定向攻击，其中中间人修改隧道模式数据包的外部IP报头的目的地。具有地址保留的隧道模式的入站处理规则（RFC5374）要求接收器验证外部IP报头和内部IP报头中的地址是否一致。因此，可以检测到攻击，并且RSVP保留不会沿着意外路径进行。
Unless RSVP Proxy entities [RFC5945] are used, RSVP signaling is controlled by end systems and not routers. As discussed in [RFC4230], RSVP allows both user-based security and host-based security. User-based authentication aims at "providing policy based admission control mechanism based on user identities or application" [RFC3182]. 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. This way, a user may authenticate to the Policy Decision Point (or directly to the first-hop router). Host-based security relies on the same mechanisms as between routers (i.e., the INTEGRITY object) as specified in [RFC2747]. For host-based security, per-interface or per-neighbor keys may be used; however, key management with statically provisioned keys can be difficult in a large-scale deployment, as described in Section 4. In principle, an end host can also be part of a group key scheme, such as GDOI. If the end systems are part of the same security domain as the RSVP hops in the network, group keying can be extended to include the end systems. If the end systems and the network are in different zones of trust, group keying cannot be used.
除非使用RSVP代理实体[RFC5945]，否则RSVP信令由终端系统而不是路由器控制。如[RFC4230]中所述，RSVP允许基于用户的安全性和基于主机的安全性。基于用户的认证旨在“提供基于用户身份或应用程序的基于策略的准入控制机制”[RFC3182]。为了标识用户或应用程序，一个名为AUTH_DATA的策略元素（包含在policy_数据对象中）由用户主机上的RSVP守护进程创建，并在RSVP消息中传输。这样，用户可以向策略决策点（或直接向第一跳路由器）进行身份验证。基于主机的安全性依赖于与[RFC2747]中规定的路由器（即完整性对象）之间相同的机制。对于基于主机的安全性，可以使用每个接口或每个邻居的密钥；但是，如第4节所述，在大规模部署中，使用静态配置的密钥进行密钥管理可能很困难。原则上，终端主机也可以是组密钥方案的一部分，例如GDOI。如果终端系统与网络中的RSVP跳属于同一安全域，则可以扩展组密钥以包括终端系统。如果终端系统和网络位于不同的信任区域，则不能使用组密钥。
While, so far, this document discusses only RSVP security assuming the traditional RSVP model as defined by [RFC2205] and [RFC2747], the analysis is also applicable to other RSVP deployment models as well as to similar protocols. These include the following:
虽然到目前为止，本文仅讨论了RSVP安全性，假设[RFC2205]和[RFC2747]定义的传统RSVP模型，但分析也适用于其他RSVP部署模型以及类似协议。这些措施包括：
o "Aggregation of RSVP for IPv4 and IPv6 Reservations" [RFC3175]: This scheme defines aggregation of individual RSVP reservations, and discusses use of RSVP authentication for the signaling messages. Group keying is applicable to this scheme, particularly when automatic Deaggregator discovery is used, since in that case, the Aggregator does not know ahead of time which Deaggregator will intercept the initial end-to-end RSVP Path message.
o “IPv4和IPv6保留的RSVP聚合”[RFC3175]：此方案定义了单个RSVP保留的聚合，并讨论了对信令消息使用RSVP身份验证。组键控适用于此方案，特别是在使用自动解聚集器发现时，因为在这种情况下，聚合器不会提前知道哪个解聚集器将拦截初始端到端RSVP路径消息。
o "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations" [RFC4860]: This document also discusses aggregation of individual RSVP reservations. Here again, group keying applies and is mentioned in the Security Considerations section.
o “通用聚合资源预留协议（RSVP）预留”[RFC4860]：本文档还讨论了单个RSVP预留的聚合。在这里，组键控同样适用，并在“安全注意事项”一节中提到。
o "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels" [RFC4804]: This scheme also defines a form of aggregation of RSVP reservation, but this time over MPLS-TE tunnels. Similarly, group keying may be used in such an environment.
o “MPLS TE/DS-TE隧道上的资源预留协议（RSVP）预留聚合”[RFC4804]：此方案还定义了RSVP预留聚合的一种形式，但这次是在MPLS-TE隧道上。类似地，可以在这样的环境中使用组键控。
o "Pre-Congestion Notification (PCN) Architecture" [RFC5559]: defines an architecture for flow admission and termination based on aggregated pre-congestion information. One deployment model for this architecture is based on Intserv over Diffserv: the Diffserv region is PCN-enabled. Also, RSVP signaling is used end-to-end, but the PCN-domain is a single RSVP hop, i.e., only the PCN-boundary-nodes process RSVP messages. In this scenario, RSVP authentication may be required among PCN-boundary-nodes, and the considerations about keying approaches discussed earlier in this document apply. In particular, group keying may facilitate operations since the ingress PCN-boundary-node does not necessarily know ahead of time which PCN-egress-node will intercept and process the initial end-to-end Path message. From the viewpoint of securing end-to-end RSVP in this scenario (from the end host to the PCN-ingress-node, to the PCN-egress-node, to the other end host), there are a lot of similarities in scenarios involving RSVP Aggregation over aggregate RSVP reservations [RFC3175] [RFC4860], RSVP Aggregation over MPLS-TE tunnels [RFC4804], and RSVP (Aggregation) over PCN ingress-egress aggregates.
o “拥塞前通知（PCN）体系结构”[RFC5559]：定义基于聚合的拥塞前信息的流量接纳和终止体系结构。此体系结构的一个部署模型基于区分服务之上的Intserv：区分服务区域启用了PCN。此外，端到端使用RSVP信令，但是PCN域是单个RSVP跳，即，只有PCN边界节点处理RSVP消息。在这种情况下，PCN边界节点之间可能需要RSVP身份验证，并且本文档前面讨论的有关键控方法的注意事项适用。特别地，组键控可促进操作，因为入口PCN边界节点不一定提前知道哪个PCN出口节点将拦截和处理初始端到端路径消息。从该场景中保护端到端RSVP（从终端主机到PCN入口节点，到PCN出口节点，再到另一个终端主机）的角度来看，在涉及聚合RSVP保留[RFC3175][RFC4860]上的RSVP聚合、MPLS-TE隧道上的RSVP聚合[RFC4804]和RSVP的场景中有很多相似之处（聚合）PCN入口-出口聚合。
The following table summarizes the various approaches for RSVP keying, and their applicability to various RSVP scenarios. In particular, such keying can be used for RSVP authentication (e.g., using the RSVP INTEGRITY object or AH) and/or for RSVP encryption (e.g., using ESP in tunnel mode).
下表总结了RSVP键控的各种方法及其对各种RSVP场景的适用性。具体而言，此类密钥可用于RSVP认证（例如，使用RSVP完整性对象或AH）和/或RSVP加密（例如，在隧道模式下使用ESP）。
+----------------------------+-----------------+--------------------+
| | per-neighbor / | group keys |
| | per-interface | |
| | keys | |
+----------------------------+-----------------+--------------------+
| Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (e.g., GDOI) |
+----------------------------+-----------------+--------------------+
+----------------------------+-----------------+--------------------+
| | per-neighbor / | group keys |
| | per-interface | |
| | keys | |
+----------------------------+-----------------+--------------------+
| Works intra-domain | Yes | Yes |
| Works inter-domain | Yes | No |
| Works over non-RSVP hops | No | Yes (1) |
| Dynamic keying | Yes (IKE) | Yes (e.g., GDOI) |
+----------------------------+-----------------+--------------------+
Table 1: Overview of Keying Approaches and Their Applicability
表1：键控方法及其适用性概述
(1): RSVP integrity with group keys works over non-RSVP nodes; RSVP encryption with ESP and RSVP authentication with AH work over non-RSVP nodes in tunnel mode with address preservation; RSVP encryption with ESP and RSVP authentication with AH do not work over non-RSVP nodes in tunnel mode.
（1） ：带有组密钥的RSVP完整性在非RSVP节点上工作；带ESP的RSVP加密和带AH的RSVP认证在隧道模式下通过非RSVP节点工作，并保留地址；带ESP的RSVP加密和带AH的RSVP身份验证在隧道模式下不适用于非RSVP节点。
We also make the following observations:
我们还提出以下意见：
o All key types can be used statically, or with dynamic key negotiation. This impacts the manageability of the solution, but not the applicability itself.
o 所有密钥类型都可以静态使用，也可以与动态密钥协商一起使用。这会影响解决方案的可管理性，但不会影响其适用性本身。
o For encryption of RSVP messages, IPsec ESP in tunnel mode can be used.
o 对于RSVP消息的加密，可以使用隧道模式下的IPsec ESP。
o There are some special cases in RSVP, like non-RSVP hosts, the Notify message (as discussed in Section 5.1, the various RSVP deployment models discussed in Section 8, and MPLS Traffic Engineering and GMPLS discussed in Section 5.2, which would benefit from a group-keying approach.
o RSVP中有一些特殊情况，如非RSVP主机、Notify消息（如第5.1节所述）、第8节所述的各种RSVP部署模型以及第5.2节所述的MPLS流量工程和GMPLS，这些都将受益于组键控方法。
This entire document discusses RSVP security; this section describes specific security considerations relating to subverted RSVP nodes.
整个文档讨论RSVP安全性；本节介绍与被颠覆的RSVP节点相关的特定安全注意事项。
An undetected subverted node, for example, one that an intruder has gained control over, is still implicitly a trusted node. However, it is a threat to the security of RSVP. Since RSVP authentication is hop by hop and not end to end, a subverted node in the path breaks the chain of trust. This is, to a large extent, independent of the type of keying used.
一个未被检测到的被破坏节点，例如，一个入侵者已经控制的节点，仍然隐含着一个受信任的节点。然而，这对RSVP的安全构成了威胁。由于RSVP身份验证是逐跳的，而不是端到端的，因此路径中被破坏的节点会破坏信任链。这在很大程度上与所使用的键控类型无关。
For per-interface or per-neighbor keying, the subverted node can now introduce fake messages to its neighbors. This can be used in a variety of ways, for example, by changing the receiver address in the Path message or by generating fake Path messages. This allows path states to be created on every RSVP router along any arbitrary path through the RSVP domain. That in itself could result in a form of denial of service by allowing exhaustion of some router resources (e.g., memory). The subverted node could also generate fake Resv messages upstream corresponding to valid Path states. In doing so, the subverted node can reserve excessive amounts of bandwidth thereby possibly performing a denial-of-service attack.
对于每个接口或每个邻居键控，被颠覆的节点现在可以向其邻居引入假消息。这可以以多种方式使用，例如，通过更改路径消息中的接收器地址或通过生成假路径消息。这允许在每个RSVP路由器上沿RSVP域中的任意路径创建路径状态。这本身可能导致某种形式的拒绝服务，允许耗尽某些路由器资源（例如内存）。被颠覆的节点还可以在上游生成与有效路径状态对应的伪Resv消息。这样，被破坏的节点可以保留过多的带宽，从而可能执行拒绝服务攻击。
Group keying allows the additional abuse of sending fake RSVP messages to any node in the RSVP domain, not just adjacent RSVP nodes. However, in practice, this can be achieved to a large extent also with per-neighbor or per-interface keys, as discussed above. Therefore, the impact of subverted nodes on the path is comparable for all keying schemes discussed here (per-interface, per-neighbor, and group keys).
组键控允许向RSVP域中的任何节点（而不仅仅是相邻的RSVP节点）发送虚假RSVP消息。然而，在实践中，这在很大程度上也可以通过每个邻居或每个接口键来实现，如上所述。因此，对于本文讨论的所有密钥方案（每个接口、每个邻居和组密钥），被颠覆节点对路径的影响是可比的。
The authors would like to thank everybody who provided feedback on this document. Specific thanks to Bob Briscoe, Hannes Tschofenig, Ran Atkinson, Stephen Kent, and Kenneth G. Carlberg.
作者要感谢对本文件提供反馈的所有人。特别感谢鲍勃·布里斯科、汉内斯·茨霍芬尼、阿金森、斯蒂芬·肯特和肯尼斯·G·卡尔伯格。
[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
[GDOI-MAC]Weis，B.和S.Rowles，“GDOI通用消息认证代码策略”，正在进行的工作，2011年9月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", RFC 4804, February 2007.
[RFC4804]Le Faucheur，F.，“MPLS TE/DS-TE隧道上资源预留协议（RSVP）预留的聚合”，RFC 4804，2007年2月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用聚合资源预留协议（RSVP）预留”，RFC 48602007年5月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，“拥塞前通知（PCN）体系结构”，RFC555592009年6月。
[RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
[RFC5945]Le Faucheur，F.，Way，J.，Wing，D.，和A.Guillou，“资源预留协议（RSVP）代理方法”，RFC 59452010年10月。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6407]Weis，B.，Rowles，S.，和T.Hardjono，“解释的集团领域”，RFC 6407，2011年10月。
Authors' Addresses
作者地址
Michael H. Behringer Cisco Systems Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 Biot - Sophia Antipolis 06410 France
Michael H.Behringer Cisco Systems Village d'Enterprises Green Side 400，法国巴蒂门特T3比奥-索菲亚安提波利斯06410
EMail: mbehring@cisco.com
URI: http://www.cisco.com
EMail: mbehring@cisco.com
URI: http://www.cisco.com
Francois Le Faucheur Cisco Systems Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 Biot - Sophia Antipolis 06410 France
Francois Le Faucheur Cisco Systems Village d'Enterprises Green Side 400，巴蒂门特T 3 Biot，法国索菲亚安提波利斯06410
EMail: flefauch@cisco.com
URI: http://www.cisco.com
EMail: flefauch@cisco.com
URI: http://www.cisco.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号95134-1706
EMail: bew@cisco.com
URI: http://www.cisco.com
EMail: bew@cisco.com
URI: http://www.cisco.com