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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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.
[RFC2747]で指定されるようにリソース予約プロトコル[RFC2205]は、RSVP隣人のホップバイホップ認証を可能にします。このモードでは、保全オブジェクトは、キー付きメッセージダイジェストを送信するために各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暗号化認証[RFC2747]を含むRSVPセキュリティの概要を説明し、提供していますが、鍵管理については説明しません。これは、「RFC 2205は、セキュリティアソシエーションはすでに利用可能であると仮定している」と述べています。本書は、グループキーを含むさまざまなタイプのキーとキーの管理に特に重点を置いています。したがって、このドキュメントは[RFC4230]を補完します。
A security domain is defined in this document as two or more nodes that share a common RSVP security policy.
セキュリティドメインは、共通のRSVPのセキュリティポリシーを共有する2つの以上のノードとして、この文書で定義されています。
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のために使用されるモデルです。このモデルでは信頼は推移的です。明示的にのみ、そのRSVPネクストホップピアは、メッセージを介してINTEGRITYオブジェクトに含まれるダイジェスト各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メッセージダイジェストを計算するために使用されるキーは、彼らがIP隣人でない場合でも、2人のRSVP隣人で共有する必要があります。 RSVPノードは常にRSVPメッセージを転送する前に、次のIPホップを知っていながら、非RSVPホップの存在下で、それは常にRSVPネクストホップを知りません。実際には、Pathメッセージの役割の一部を正確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---
(*) 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ホップの存在下では、そのようなPATHメッセージとして、いくつかのRSVPメッセージで、RSVPルータは、それを転送する時に、そのメッセージのRSVPネクストホップを知りません。例えば、図1において、R1はR2であるPathメッセージのための次のIPホップは、受信機宛てことを知っているが、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は、Pathメッセージが受信機宛およびR2に転送し保護するために、グループ鍵を使用します。ルーティングによって決定されるように、非RSVPノードである、R2は、現在の最短経路に応じR3又はR5にPathメッセージを無視して転送します。それはR3またはR5であるかどうか、Pathメッセージを受信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 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.
現在のほとんどのRSVP認証の実装には、インターフェイス単位のRSVPキーをサポートしています。インタフェースは、ポイントツーポイントである場合（したがって、RSVPルータは各インターフェース上の単一のRSVP隣人を有する）、このことは、異なる鍵が各隣接するために使用されるという意味でごとの隣接キーに相当します。ポイントツーポイントの場合は、セキュリティドメインは、単にルータとその隣人との間にあります。インターフェイスはマルチポイントであるときしかし、特定のサブネット上のすべてのRSVPのスピーカーは、同じセキュリティドメインに属し、このモデルで同じキーを共有する必要があります。これは、異なるセキュリティドメインからのノードがサブネット上に存在している展開シナリオ、例えば、インターネットエクスチェンジのために、それは適しません。このような場合には、単位の隣のキーが必要とされており、セキュリティドメインは、ルータとその隣人との間にあります。
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.
両方の単調に増加するシーケンス番号とタイムベースのアンチリプレイの方法（例えば、INTEGRITYは、単純なシーケンス番号[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----------------->|
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----->|
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の動作のためのより実用的なアプローチは、各セキュリティドメインのための別個のグループ鍵サーバを使用すること、及び（従って第三のセキュリティドメインを含む）は、2つのドメイン間の界面ごとまたは隣接キーを使用することです。図4は、このセットアップを示しています。
....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を通過させ2つのドメイン間の相互接続点の数が比較的小さく、十分に制御されます。また、異なるドメインは、両側のキーを更新するために、両方のドメインによって信頼インフラストラクチャを使用する立場にないかもしれません。このように、静的にプロビジョニングされたキーは、ドメイン間の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操作は中断を被ります。 （動的鍵アプローチを用いて、2つのキーが同時に有効な猶予期間が存在することができるが、手動キーイングで猶予期間が有意に長いダイナミックキーロールオーバスキームとよりなる傾向にあります。）
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]は通知メッセージを紹介し、そのようなメッセージは、非ホップバイホップ方式で送信されることを可能にします。 [RFC3473]のSecurity Considerations部で述べたように、これはRSVPのホップバイホップ整合性と認証モデルに干渉することができます。 [RFC3473]は、メッセージを通知し保護するために使用することができますどのように標準のIPsecベースの整合性と認証について説明します。
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通知メッセージは、非ホップバイホップメッセージです。そのようなメッセージは、出力ノードに直接入口ノードから送信されてもよいです。ノード間のキーが他に使用されていない場合、このような場合にキーインググループはノード間キーの確立を回避します。
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Reroute [RFC4090] deserves additional considerations.
高速リルート[RFC4090] RSVP-TE [RFC3209]のためにと、RSVP-TEのための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 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.
高速リルートの施設バックアップ方法では、マージポイント（MP）へのローカル修理のポイント（PLR）からバックアップトンネルは、ラベルを保護するために使用され、施設の故障（例えば、ルータに対してパス（保護されたLSPを）交換）PLRとMPとの間に位置します。設備の故障時に、PLRはバックアップトンネル内、結果として保護されたLSPをリダイレクトし、PLRとMPはその後（例えば、保護されたLSPのメンテナンスのために）互いの間のRSVP制御メッセージを交換する必要があります。いくつかは、直接（例えば、MPからPLRにResvメッセージ）RSVPノードにアドレス指定されながらPLRとMPとの間のRSVPメッセージのいくつかは、バックアップトンネル（PLRからMPへ例えば、Pathメッセージ）を介して送信されます。それらが相互に直接接続されていないので、故障の非存在下でRSVP隣人として挙動しないながら再ルーティング期間中に、PLRとMPを効果、RSVP隣人になります。この点は言う[RFC4090]のSecurity Considerations部で提起された：「施設バックアップ方法がありますPLRとその選択合流点の信頼RSVPメッセージがお互いから受信することを要求します」。このような環境では、グループ・キーイングから利益を得ることができます。グループ鍵は容易PLRのすべての可能なペアについて、前に特定のキーの設定、または鍵更新機構の活性化を必要とせずに、PLRとMPが互いにメッセージを認証することを確実に、高速リルートするための対応ルータの集合の中に使用することができますそして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).
RSVP-TEまたはRSVP-TE高速リルートは境界（参照[RFC4216]）は、セクション3.1および3.2に上記の考察は、インターフェイス単位または隣接キーは、2人のRSVP隣人との間で使用することができるように、適用される全体に導入されます異なるのAS内（独立して同じASに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をサポートするためのプロトコル拡張を指定します。ホップバイホップP2MPのRSVP-TEシグナリングに適用シグナリングホップバイホップRSVPのRSVPメッセージの保全機構（[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と階層を定義し、非ホップバイホップシグナリングを使用します。それは、その操作の一部についてLSP階層プロシージャを再利用するため、P2MP RSVP-TEは、非ホップバイホップシグナリングを使用します。 LSP階層とP2MP RSVP-TEの両方が[RFC3473]及び非ホップバイホップRSVP-TEシグナリングのために[RFC4206]で定義されたセキュリティメカニズムに依存しています。グループキーは、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).
RSVPを保護するためにIPsec [RFC4301]を使用している場合、このドキュメントでは、さまざまなキーイング方法についての議論も適用可能です。 [RFC2747]のセクション1.2は、IPsecは、RSVPを保護するための最適な選択ではないと述べています。 key引数は、IPsecセキュリティアソシエーション（SA）とRSVPのSAが同じパラメータに基づいていないということです。それでも、IPsecはRSVPを保護するために使用することができます。関連RSVPフローのセキュリティポリシーデータベース（SPD）トラフィックセレクタは一定ではありません。いくつかのケースでは、送信元および宛先アドレスは、エンドホストであり、時にはそれらがRSVPルータです。したがって、SPD内のトラフィックセレクタは、ソースアドレスと宛先アドレスのためにANYを指定すると、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 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.
「マルチキャストグループのセキュリティアーキテクチャ」[RFC3740]は詳細に「グループセキュリティアソシエーション」（GSA）を定義します。この定義は、ここで議論し、コンテキストにも適用可能であり、RSVPのためにIPsecを使用することができます。既存のGDOI仕様[RFC6407]はIPSecで使用することができるグループセキュリティアソシエーションを管理します。例えばGDOIポリシーが（IPプロトコル46）RSVPプロトコル自体のすべてのパケットを暗号化または認証することであろう。 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プラスプロトコル）を使用することが期待されます。
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]で定義されたINTEGRITYオブジェクトは、グループ・キーイング文脈においても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ヘッダも（IPv6では）（IPv4の）IPオプションまたは拡張ヘッダを保護しません。
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オプションまたは拡張ヘッダに加え、全体のRSVPパケットのIPヘッダを含む全体の元のIPパケットを、保護します。それはまた、外部ヘッダの不変のフィールドを保護します。
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.
被覆されたフィールドの点における2つの方式の違いは、元のIPパケットのIPv4ヘッダとIPオプション、またはIPv6ヘッダと拡張ヘッダは、（（AHの場合のように）保護されているか否かことですINTEGRITYオブジェクトの場合）。また、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.
次のセクションで説明したように、IPsecトンネルモードは、非RSVPノードの存在下で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, 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.
（インターフェイス単位ごとの隣接、またはグループキーイング）上述のキーイング方法のいずれかで動作するIPsecトンネルモードでRSVPパケットを保護する限り、経路には、非RSVPノードが存在しないように（ただし、基 - 参照）以下の注意事項をキーイング。 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.
IPsecトランスポートモードでは、[RFC4303]で定義されるようにこれらのメッセージは、元のソースとデスティネーションを保つため、RSVPのPathメッセージを確保するには適していません。 [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.
アドレス保存は、グループキーと連動して、ユニキャストトラフィックを保護するためにも使用することができます。それらはトンネルモード外側のIPヘッダ内のRSVPパケットの元のエンドシステムアドレスを維持するため、このトンネルモードでは、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.
アドレス保存とトンネルモードでは、グループキーと組み合わせて、さらに非RSVPノードが横断しなければならない場合にはRSVPの保護のためにAHまたはESPの使用を可能にします。それは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.
グループキーと共に使用される場合、アドレス保存とトンネルモードのman-in-the-middleがトンネルモードパケットの外側IPヘッダの宛先を変更リダイレクト攻撃を軽減するために使用することができます。アドレス保存（[RFC5374]のセクション5.2）とのトンネルモードのインバウンド処理ルールは、受信機が、外側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]「ユーザーIDまたはアプリケーションに基づいたポリシーベースのアドミッション制御メカニズムを提供する」ことを目指しています。ユーザまたはPOLICY_DATAオブジェクトに含まれるアプリケーション、AUTH_DATAというポリシーの要素を識別するために、ユーザのホストで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:
、これまでのところ、この文書は[RFC2205]と[RFC2747]で定義されている伝統的なRSVPモデルを仮定のみ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.
「IPv4とIPv6の予約のためのRSVPの集約」[RFC3175] O：この方式は、個々のRSVP予約の集合を定義し、シグナリングメッセージのためのRSVP認証の使用を論じています。グループキーは、その場合には、アグリゲータは、アグリゲーターが最初のエンドツーエンドのRSVP Pathメッセージを傍受れる事前に知っていないので、自動デアグリゲータの発見が使用されている場合は特に、この方式にも適用可能です。
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予約の凝集を説明します。ここで再び、グループキーイングが適用され、Security Considerations部に記載されています。
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.
[RFC4804] O「リソース予約プロトコル（RSVP）MPLS TE / DS-TEトンネル上予約の集約」：この方式は、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]：集約プレ輻輳情報に基づいて、フローアドミッション及び終了のためのアーキテクチャを定義します。このアーキテクチャのための一つの展開モデルは、Diffservの上イントサーブに基づいています。Diffservの領域はPCNが有効です。また、RSVPシグナリングは、エンドツーエンドで使用されるが、PCNドメイン、すなわち、唯一PCN-境界ノード処理RSVPメッセージ単一RSVPホップです。このシナリオでは、RSVP認証がPCN-境界ノードの間で必要と前にこの文書で論じキーイングアプローチに関する考慮事項が適用されてもよいです。入口PCN境界ノードは、必ずしも前方PCN-出口ノードは、傍受した初期のエンドツーエンドパスのメッセージを処理する時間を知らないので、特に、グループキーは、操作を容易にすることができます。 （他のエンドホストに、PCN-出口ノードに、PCN-入口ノードへのエンドホストから）このシナリオでは、エンドツーエンドのRSVPを確保する観点から、シナリオにおける多くの類似点がありますPCN乗降凝集にわたって集約RSVP予約上RSVP集約[RFC3175]、[RFC4860]、RSVP集約MPLS-TEトンネル[RFC4804]を超えると、RSVP（集約）を含みます。
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シナリオへの適用のための様々なアプローチをまとめました。特に、このようなキー（例えば、トンネル・モードでESPを使用して）（例えば、RSVPのINTEGRITYオブジェクトまたはAHを使用して）RSVP認証用及び/又はRSVP暗号化に使用することができます。
+----------------------------+-----------------+--------------------+
| | 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暗号化; AHとESPとRSVP認証と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から恩恵を受ける5.2節で議論非RSVPホスト、セクション5.1で議論するよう通知メッセージ（セクション8で説明した様々なRSVPの展開モデル、およびMPLSトラフィックエンジニアリングやGMPLSなどのRSVPにおけるいくつかの特殊なケースがありますが、グループキーイングアプローチ。
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.
インターフェイスごと、または隣人キーイングのために、堕落ノードは現在、その隣に偽のメッセージを紹介することができます。これは、例えば、Pathメッセージにおける受信機アドレスを変更することによって、または偽のPathメッセージを生成することによって、様々な方法で使用することができます。これは、パスの状態は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.
作者はこのドキュメントに関するフィードバックを提供する皆様に感謝したいと思います。ボブ・ブリスコー、ハンネスTschofenig、蘭アトキンソン、スティーブン・ケント、およびケネスG.カールバーグに固有のおかげ。
[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.
[GDOI-MAC]ヴァイス、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、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]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "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.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、RFC 3182、2001年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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、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.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]チャン、R.とJ. Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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]ルFaucheur、F.、RFC 4804 "MPLS TE / DS-TEトンネル経由リソース予約プロトコル（RSVP）予約の集約"、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]ルFaucheur、F.、デイビー、B.、ボーズ、P.、Christouの、C.、およびM.ダヴェンポート、 "汎用集計リソース予約プロトコル（RSVP）予約"、RFC 4860、2007年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]アガルワル、R.、Papadimitriou、D.、およびS.安川は、 - 、、RFC 4875の "機能拡張は、予約プロトコルリソースへのポイントツーマルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）がスイッチパス（LSP）" 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]ヴァイス、B.、グロス、G.、およびD. Ignjatic、 "インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡張機能"、RFC 5374、2008年11月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P.、 "プリ輻輳通知（PCN）アーキテクチャ"、RFC 5559、2009年6月。
[RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
[RFC5945]ルFaucheur、F.、マナー、J.、ウィング、D.、およびA. Guillou、 "リソース予約プロトコル（RSVP）プロキシアプローチ"、RFC 5945、2010年10月。
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.
[RFC6407]ヴァイス、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
マイケル・H. Behringerのシスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanille Batiment T 3ビオ - ソフィアアンティポリスフランス06410
EMail: mbehring@cisco.com URI: http://www.cisco.com
電子メール：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
ヴィレッジグリーンサイドのフランソワ・死神シスコシステムズ社400アベニューRoumanille Batiment T 3ビオ - ソフィアアンティポリスフランス06410
EMail: flefauch@cisco.com URI: http://www.cisco.com
電子メール：flefauch@cisco.com URI：http://www.cisco.com
Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA
ブライアン・ワイスシスコシステムズ170 W.タスマン・ドライブサンノゼ、カリフォルニア95134-1706 USA
EMail: bew@cisco.com URI: http://www.cisco.com
電子メール：bew@cisco.com URI：http://www.cisco.com