[要約] RFC 6411は、RSVPセキュリティのための鍵生成方法の適用可能性について説明しています。このRFCの目的は、RSVPセキュリティの実装において、適切な鍵生成方法を選択するためのガイダンスを提供することです。
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のグループキーイングをneighborごとまたはインターフェイスごとのキーイングと比較し、関連する主要なプロビジョニング方法と、これらのアプローチの適用性と制限について説明します。このドキュメントでは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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ノードのIDを確認し、メッセージの整合性を検証できます。ダイジェストの範囲にシーケンス番号を含めることにより、ダイジェストはリプレイ保護も提供します。
[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ノードは、整合性オブジェクトに含まれるメッセージダイジェストを介して、RSVPのネクストホップピアのみを明示的に信頼します。Next-Hop 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）で説明されているように、解釈のグループドメイン（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ノードは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---
(*) 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認証と暗号化の課題が生じます。PATHメッセージなどの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ルーターは各インターフェイスに1つの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.
さまざまなセキュリティドメインからのノードがサブネット（たとえばインターネット交換ポイント）に存在する展開シナリオ。そのような場合、隣人ごとのキーが必要であり、セキュリティドメインはルーターとその隣接の間にあります。
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.
インターフェイスごとのキーと1つのセキュリティドメイン内で使用できます。
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.
前のセクションで説明したように、NEIGHBORごととインターフェイスごとのキーは、非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.
単一のグループキーを通常、複数のセキュリティドメインをカバーするために使用することはできません。これは、定義上、異なるドメインが互いに信頼していないためです。したがって、彼らは同じグループキーサーバーを信頼する意思がないでしょう。いくつかのセキュリティドメインで使用される単一のグループキーの場合、双方が信頼する単一のグループキーサーバーが必要です。これは理論的には可能ですが、実際には、両方のドメインから信頼されるそのようなエンティティが1つあるとは考えにくいです。図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つのドメイン間でインターフェイスごとまたはニーボールごとのキーを使用することです（したがって、3番目のセキュリティドメインを含む）。図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]は、Notifyメッセージを導入し、そのようなメッセージを非ホップバイホップファッションで送信できるようにします。[RFC3473]のセキュリティに関する考慮事項セクションで説明したように、これは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]を使用できる場合があります。たとえば、RSVPは、MPLSネットワークのトラフィックエンジニアリングに一般的に使用されるメッセージに通知します。このようなメッセージは、侵入ノードから出口ノードに直接送信される場合があります。このような場合のグループキーイングは、ノード間キーイングが他の方法で使用されない場合、ノード間キーイングの確立を回避します。
Use of RSVP authentication for RSVP-TE [RFC3209] and for RSVP-TE Fast Reroute [RFC4090] deserves additional considerations.
RSVP-TE [RFC3209]およびRSVP-TE Fast Reroute [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
施設のバックアップFast Rerouteを使用すると、ローカル修理ポイント（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).
RSVP-TEまたはRSVP-TE Fast Rerouteが境界として展開されている場合（[RFC4216]を参照）、上記のセクション3.1および3.2に示されている考慮事項が適用されます。異なるASE（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メッセージ整合性メカニズムHop-by-Hop 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階層を定義し、非ホップバイホップシグナリングを使用します。一部の操作のLSP階層手順を再利用するため、P2MP RSVP-TEは非ホップバイホップシグナリングも使用します。LSP階層とP2MP RSVP-TEの両方は、非ホップバイホップRSVP-TEシグナル伝達について[RFC3473]および[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を保護するための最適な選択ではないと述べています。重要な議論は、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）を詳細に定義しています。この定義は、ここで説明するコンテキストでも適用され、RSVPにIPSECを使用できます。既存の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プラスプロトコル）のみを使用することが期待されます。
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ヘッダー、RSVPパケット全体を含む元の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の場合と同様）かどうか（同様）整合性オブジェクトの場合）。また、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ノードの存在下でRSVPトラフィックにIPSECトンネルモードを適用することはできません。したがって、どちらの場合も、AHと整合性のオブジェクトの両方のセキュリティ関連は、同じ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,
IPSECトンネルモードでRSVPパケットを保護することは、パスに非RSVPノードがない限り、上記のキーイングメソッド（インターフェイスごと、neighbor、またはグループキーイング）で動作します（ただし、グループキーイング）
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
Next-Hop 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.
アドレス保存を備えたトンネルモードは、グループキーイングと組み合わせて、非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.
グループキーイングとともに使用する場合、アドレス保存付きのトンネルモードを使用して、トンネルモードパケットの外側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]を目的としています。ユーザーまたはアプリケーションを識別するために、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.
o 「IPv4およびIPv6予約のRSVPの集約」[RFC3175]：このスキームは、個々のRSVP予約の集約を定義し、シグナリングメッセージのRSVP認証の使用について説明します。グループキーイングは、特に自動ディーグレジャーの発見が使用される場合、このスキームに適用できます。その場合、アグリゲーターはどのDeaggregatorが最初のエンドツーエンド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]：集約された事前調理情報に基づいて、流れの入場と終了のアーキテクチャを定義します。このアーキテクチャの展開モデルの1つは、diffservのintservに基づいています。Diffserv領域はPCN対応です。また、RSVPシグナル伝達はエンドツーエンドで使用されますが、PCNドメインは単一のRSVPホップです。つまり、PCN結合ノードのみがRSVPメッセージを処理します。このシナリオでは、RSVP認証がPCNバウンドリーノードの間で必要になる場合があり、このドキュメントで前述したキーイングアプローチに関する考慮事項が適用されます。特に、Ingress PCN-Boundary-Nodeは、どのPCN-Egress-Nodeが最初のエンドツーエンドパスメッセージを傍受して処理するかを事前に知っているわけではないため、グループキーイングが操作を促進する可能性があります。このシナリオでエンドツーエンドのRSVPを保護するという観点から（エンドホストからPCN-ingress-Node、PCN-Egress-Nodeまで、もう一方のエンドホストまで）、シナリオには多くの類似点がありますRSVP凝集を総計RSVP予約[RFC3175] [RFC4860]、MPLS-TEトンネル上のRSVP凝集[RFC4804]、およびPCN侵入侵入 - 侵入凝集体を介した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シナリオへの適用性をまとめたものです。特に、このようなキーイングは、RSVP認証（たとえば、RSVP IntegrityオブジェクトまたはAHを使用する）および/またはRSVP暗号化（例：ESPでトンネルモードで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) |
+----------------------------+-----------------+--------------------+
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トラフィックエンジニアリングとGMPL）など、いくつかの特別なケースがあります。グループキーイングアプローチ。
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メッセージを送信する追加の悪用が可能になります。ただし、実際には、上記で説明したように、これはまた、傍1つまたはインターフェイスごとのキーを使用しても大幅に達成できます。したがって、パスに対する破壊されたノードの影響は、ここで説明するすべてのキーキースキームに匹敵します（インターフェイスごと、ニグボールごと、およびグループキー）。
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 Genericメッセージ認証コードポリシー」、2011年9月、Work in Progress。
[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 2205、1997年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 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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP Tunnelsの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] 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、「The Multicast Group Security Architecture」、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 4090、2005年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）階層」、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 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] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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 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] 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）アーキテクチャ」、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] Le Faucheur、F.、Mather、J.、Wing、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] 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
マイケルH.ベーリンガーシスコシステムビレッジD'Entreprises Green Side 400、Avenue Roumanille、Batiment T 3 Biot -Sophia Antipolis 06410 France
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
フランソワ・ル・ファウチュール・シスコ・システムヴィレッジ・グリーン・サイド400、アベニュー・ルーマニル、バティメントT 3 Biot -Sophia Antipolis 06410 France
EMail: 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