Internet Engineering Task Force (IETF) W. Atwood
Request for Comments: 5796 Concordia University/CSE
Updates: 4601 S. Islam
Category: Standards Track IRS-EMT
ISSN: 2070-1721 M. Siami
Concordia University/CIISE
March 2010
Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
プロトコル独立マルチキャストスパースモード（PIM-SM）リンクローカルメッセージでの認証と機密性
Abstract
抽象
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601.
スパースモード（PIM-SM）ルーティングプロトコル - RFC 4601の任務は、IPsecを使用することは、プロトコル独立マルチキャストにおけるリンクローカルメッセージの認証を確実にします。この文書では、セキュリティペイロード（ESP）または（オプションで）認証ヘッダー（AH）カプセル化IPセキュリティ（IPsec）を使用して、PIM-SMのリンクローカルのメッセージを認証するためのメカニズムを指定します。これは、ESPを使用して機密性を提供するために、オプションのメカニズムを指定します。手動キーは必須とデフォルトのグループ鍵管理ソリューションとして指定されています。手動キー入力で存在するスケーラビリティとセキュリティの問題に対処するには、自動化されたグループ鍵管理の仕組みをオプションでサポートが提供されています。しかし、自動化されたグループ鍵管理を実装するための手順は、他の文書に残されています。この文書は、RFC 4601に更新します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc5796.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5796で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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 ....................................................4
1.1. Goals and Non-Goals ........................................4
2. Terminology .....................................................5
3. Transport Mode versus Tunnel Mode ...............................5
4. Authentication ..................................................5
5. Confidentiality .................................................6
6. IPsec Requirements ..............................................6
7. Key Management ..................................................8
7.1. Manual Key Management ......................................8
7.2. Automated Key Management ...................................8
7.3. Communications Patterns ....................................9
7.4. Neighbor Relationships ....................................10
8. Number of Security Associations ................................11
9. Rekeying .......................................................12
9.1. Manual Rekeying Procedure .................................13
9.2. KeyRolloverInterval .......................................14
9.3. Rekeying Interval .........................................14
10. IPsec Protection Barrier and SPD/GSPD .........................14
10.1. Manual Keying ............................................14
10.1.1. SAD Entries .......................................14
10.1.2. SPD Entries .......................................14
10.2. Automatic Keying .........................................15
10.2.1. SAD Entries .......................................15
10.2.2. GSPD Entries ......................................15
10.2.3. PAD Entries .......................................15
11. Security Association Lookup ...................................16
12. Activating the Anti-Replay Mechanism ..........................16
13. Implementing a Security Policy Database per Interface .........17
14. Extended Sequence Number ......................................17
15. Security Considerations .......................................18
16. Acknowledgements ..............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
All the PIM-SM [RFC4601] control messages have IP protocol number 103. Some control messages are unicast; the rest are multicast with Time to Live (TTL) = 1. The source address used for unicast messages is a domain-wide reachable address. For the multicast messages, a link-local address of the interface on which the message is being sent is used as the source address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination address. These messages are called link-local messages. Hello, Join/Prune, and Assert messages are included in this category. A forged link-local message may be sent to the ALL_PIM_ROUTERS multicast address by an attacker. This type of message affects the construction of the distribution tree [RFC4601]. The effects of these forged messages are outlined in Section 6.1 of [RFC4601]. Some of the effects are very severe, whereas some are minor.
すべてのPIM-SM [RFC4601]の制御メッセージは、いくつかの制御メッセージは、ユニキャストされているIPプロトコル番号103を持っています。残りは、ユニキャストメッセージに使用される生存期間（TTL）= 1.送信元アドレスでマルチキャストされていることは、ドメイン全体の到達可能なアドレスです。マルチキャストメッセージの場合、メッセージが送信されているインターフェイスのリンクローカルアドレスを送信元アドレスと特別なマルチキャストアドレスとして使用され、ALL_PIM_ROUTERS（IPv4およびFF02に224.0.0.13 :: IPv6におけるD）は、以下のように使用され宛先アドレス。これらのメッセージは、リンクローカルメッセージと呼ばれています。こんにちは、/プルーンに参加し、アサートメッセージは、このカテゴリに含まれています。鍛造リンクローカルメッセージが攻撃者によってALL_PIM_ROUTERSマルチキャストアドレスに送信されてもよいです。このタイプのメッセージは、配信ツリー[RFC4601]の構成に影響を与えます。これらの偽造メッセージの効果は、[RFC4601]の6.1節で概説されています。いくつかの軽微なものであるのに対し、効果のいくつかは、非常に厳しいです。
PIM-SM version 2 was originally specified in RFC 2117 [RFC2117], and revised in RFC 2362 [RFC2362] and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a number of deficiencies. The "Security Considerations" section of RFC 4601 is based primarily on the Authentication Header (AH) specification described in RFC 4302 [RFC4302].
PIM-SMバージョン2は元々RFC 2117 [RFC2117]で指定され、RFC 2362 [RFC2362]及びRFCに改訂された4601 RFC 4601は、RFC 2362を廃止し、欠陥の数を補正します。 RFC 4601の「セキュリティ上の考慮事項」の項は、主に、RFC 4302 [RFC4302]に記載の認証ヘッダ（AH）の仕様に基づいています。
Securing the unicast messages can be achieved by the use of a normal unicast IPsec Security Association (SA) between the two communicants.
ユニキャストメッセージをセキュアには、2つのコミュニ間の通常のユニキャストのIPsecセキュリティアソシエーション（SA）の使用により達成することができます。
This document focuses on the security issues for link-local messages. It provides some guidelines to take advantage of the new permitted AH functionality in RFC 4302 and the new permitted ESP functionality in RFC 4303 [RFC4303], and to bring the PIM-SM specification into alignment with the new AH and ESP specifications. In particular, in accordance with RFC 4301, the use of ESP is made mandatory and AH is specified as optional. This document specifies manual key management as mandatory to implement, i.e., that all implementations MUST support, and provides the necessary structure for an automated key management protocol that the PIM routers may use.
この文書では、リンクローカルメッセージのセキュリティ上の問題に焦点を当てています。これは、RFC 4302で新しい許可AH機能およびRFC 4303 [RFC4303]で新しい許可ESPの機能を利用するために、新しいAHとESPの仕様との整合にPIM-SM仕様をもたらすためにいくつかのガイドラインを提供します。具体的には、RFC 4301に従って、ESPの使用は必須で作られ、AHは、オプションとして指定されています。この文書は、すべての実装がサポートしなければならないこと、すなわち、実装が必須と手動鍵管理を特定し、PIMルータが使用することができる自動化された鍵管理プロトコルに必要な構造を提供します。
The primary goal for link-local security is to provide data origin authentication for each link-local message. A secondary goal is to ensure that communication only happens between legitimate peers (i.e., adjacent routers). An optional goal is to provide data confidentiality for the link-local messages.
リンクローカルセキュリティのための第一の目的は、各リンクローカルメッセージのためのデータ発信元認証を提供することです。第二の目標は、通信のみ正当ピア（すなわち、隣接ルータ）との間に起こることを保証することです。オプションの目標は、リンクローカルメッセージのためのデータの機密性を提供することです。
The first goal implies that each router has a unique identity. It is possible (but not mandatory) that this identity will be based on the unicast identity of the router. (The unicast identity could be, for example, based on some individually configured property of the router, or be part of a region-wide public key infrastructure.) The existence of this unique identity is assumed in this specification, but procedures for establishing it are out of scope for this document.
最初の目標は、各ルータが一意のIDを持っていることを意味します。これは、このアイデンティティは、ルータのユニキャストアイデンティティに基づいてされることを（必須ではない）ことも可能です。 （ユニキャスト同一ルータのいくつかの個別に設定プロパティに基づいて、例えば、である、あるいは領域全体の公開鍵インフラストラクチャの一部であってもよい。）このユニークなアイデンティティの存在は、本明細書において想定されるが、それを確立するための手順このドキュメントの範囲外です。
The second goal implies that there is some form of "adjacency matrix" that controls the establishment of Security Associations among adjacent multicast routers. For manual keying, this control will be exercised by the Administrator of the router(s), through the setting of initialization parameters. For automated keying, the existence of this control will be reflected by the contents of the Peer Authorization Database (PAD) (see RFC 4301 [RFC4301]) or the Group Security Policy Database (GSPD) (see RFC 5374 [RFC5374]) in each router. Procedures for controlling the adjacency and building the associated PAD and GSPD are out of scope for this document.
第二の目標は、隣接するマルチキャストルータ間のセキュリティアソシエーションの確立を制御し、「隣接行列」のいくつかのフォームがあることを意味します。手動キーイングのために、この制御は、初期化パラメータの設定を介して、ルータ（複数可）の管理者によって行使されるであろう。自動化されたキーの場合、このコントロールの存在は、ピア認証データベース（PAD）の内容（RFC 4301 [RFC4301]を参照）、またはグループセキュリティポリシーデータベース（GSPD）で反映されます（RFC 5374 [RFC5374]を参照）、各中ルータ。隣接関係を制御し、関連するパッドとGSPDを構築するための手順は、この文書の範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. They indicate requirement levels for compliant PIM-SM implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。彼らは準拠したPIM-SMの実装のための要件レベルを示します。
All implementations conforming to this specification MUST support SA in transport mode to provide required IPsec security to PIM-SM link-local messages. They MAY also support SA in tunnel mode to provide required IPsec security to PIM-SM link-local messages. If tunnel mode is used, both destination address preservation and source address preservation MUST be used, as described in Section 3.1 of RFC 5374 [RFC5374].
この仕様に準拠するすべての実装は、PIM-SMのリンクローカルメッセージに必要なIPsecセキュリティを提供するために、トランスポートモードでSAをサポートしなければなりません。彼らはまた、PIM-SMのリンクローカルメッセージに必要なIPsecセキュリティを提供するために、トンネルモードでSAをサポートするかもしれません。トンネルモードを使用する場合は、RFC 5374 [RFC5374]のセクション3.1に記載されているように、両方の宛先アドレス保存およびソースアドレス保存は、使用しなければなりません。
Implementations conforming to this specification MUST support authentication for PIM-SM link-local messages. Implementations conforming to this specification MUST support HMAC-SHA1 [RFC2404].
この仕様に準拠した実装では、PIM-SMのリンクローカルメッセージの認証をサポートしなければなりません。この仕様に準拠した実装はHMAC-SHA1 [RFC2404]をサポートしなければなりません。
In order to provide authentication of PIM-SM link-local messages, implementations MUST support ESP [RFC4303] and MAY support AH [RFC4302].
PIM-SMのリンクローカルメッセージの認証を提供するために、実装はESP [RFC4303]をサポートしなければならないとAH [RFC4302]をサポートするかもしれません。
If ESP in transport mode is used, it will only provide authentication to PIM-SM protocol packets excluding the IP header, extension headers, and options.
トランスポートモードでESPを使用する場合、それは、IPヘッダ、拡張ヘッダ、及びオプションを除くPIM-SMプロトコルパケットに認証を提供します。
If AH in transport mode is used, it will provide authentication to PIM-SM protocol packets, selected portions of the IP header, extension headers and options.
トランスポートモードでAHが使用される場合、それは、PIM-SMプロトコルパケット、IPヘッダの選択された部分、拡張ヘッダとオプションへの認証を提供します。
Note: when authentication for PIM-SM link-local messages is enabled,
注意：PIM-SMのリンクローカルメッセージに対する認証が有効になっている場合、
o PIM-SM link-local packets that are not protected with AH or ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
IPsecの実装は、そのようなパケットのカウンタを維持することができるがO AHまたはESPで保護されていないPIM-SMリンクローカルパケットは、黙って、IPSecで破棄されます。
o PIM-SM link-local packets that fail the authentication checks will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
IPsecの実装は、そのようなパケットのカウンタを維持することができるものの、O認証チェックに失敗PIM-SMリンクローカルパケットは、黙って、IPSecで破棄されます。
Implementations conforming to this specification SHOULD support confidentiality for PIM-SM. Implementations supporting confidentiality MUST support AES-CBC [RFC3602] with a 128-bit key.
この仕様に準拠した実装では、PIM-SMのための機密性をサポートする必要があります。機密性をサポートする実装は、128ビット鍵のAES-CBC [RFC3602]をサポートしなければなりません。
If confidentiality is provided, ESP MUST be used.
機密性が提供されている場合は、ESPを使用しなければなりません。
Since authentication MUST be supported by a conforming implementation, an implementation MUST NOT generate the combination of NON-NULL Encryption and NULL Authentication.
認証が適合実装によってサポートされなければならないので、実装は、非NULL暗号化およびNULL認証の組み合わせを生成してはいけません。
Note: when confidentiality for PIM-SM link-local packets is enabled,
注意：PIM-SMのリンクローカルパケットのための機密性を有効にした場合、
o PIM-SM packets that are not protected with ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
IPsecの実装は、そのようなパケットのカウンタを維持することができるがO ESPで保護されていないPIM-SMパケットは静かに、IPSecで破棄されます。
In order to implement this specification, the following IPsec capabilities are required.
この仕様を実装するためには、次のIPsec機能が必要とされています。
Transport mode IPsec in transport mode MUST be supported.
トランスポートモードでのトランスポートモードのIPsecをサポートしなければなりません。
Multiple Security Policy Databases (SPDs) The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface.
複数のセキュリティポリシーデータベース（SPDを）実装では、インターフェイスに基づいて特定のSPDを選択する機能を提供するSPD選択機能を持つ複数のSPDをサポートしなければなりません。
Selectors The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.
セレクタは、実装は、SPDのセレクタとして、送信元アドレス、宛先アドレス、プロトコル、および方向を使用することができなければなりません。
Interface ID tagging The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) on which they arrived.
実装をタグ付けインターフェイスIDは、彼らが到着した（物理または仮想）インターフェイスのIDと着信パケットにタグを付けることができなければなりません。
Manual key support It MUST be possible to use manually configured keys to secure the specified traffic.
手動キーのサポートは、指定されたトラフィックを保護するために、手動で構成されたキーを使用することが可能でなければなりません。
Encryption and authentication algorithms Encryption and authentication algorithm requirements described in RFC 4835 [RFC4835] apply when ESP and AH are used to protect PIM-SM. Implementations MUST support ESP-NULL, and if providing confidentiality, MUST support the ESP transforms providing confidentiality required by [RFC4835]. However, in any case, implementations MUST NOT allow the user to choose a stream cipher or block mode cipher in counter mode for use with manual keys.
ESPとAHは、PIM-SMを保護するために使用されている場合、RFC 4835 [RFC4835]で説明した暗号化および認証アルゴリズム、暗号化および認証アルゴリズムの要件が適用されます。実装は、ESP-NULLをサポートしなければならない、と機密性を提供する場合、ESPは[RFC4835]で必要な機密性を提供する変換サポートしなければなりません。しかし、どのような場合には、実装は、ユーザーが手動キーで使用するためのカウンタモードでのストリーム暗号またはブロックモード暗号を選択するのを許してはなりません。
Encapsulation of ESP packets IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
ESPパケットのESPパケットのIPカプセル化のカプセル化をサポートしなければなりません。簡単にするために、ESPパケットのUDPカプセル化を使用してはいけません。
If the automatic keying features of this specification are implemented, the following additional IPsec capabilities are required:
この仕様書の自動キーイング機能が実装されている場合は、以下の追加のIPsec機能が必要とされています。
Group Security Policy Database (GSPD) The implementation MUST support the GSPD that is described in RFC 5374 [RFC5374].
グループセキュリティポリシーデータベース（GSPD）の実装は、RFC 5374 [RFC5374]で説明されてGSPDをサポートしなければなりません。
Multiple Group Security Policy Databases The implementation MUST support multiple GSPDs with a GSPD selection function that provides an ability to choose a specific GSPD based on interface.
複数のグループのセキュリティポリシーは、実装がインターフェイスに基づいて、特定のGSPDを選択する機能を提供するGSPD選択機能を持つ複数のGSPDsをサポートしなければならないデータベース。
Selectors The implementation MUST be able to use source address, destination address, protocol and direction as selectors in the GSPD.
セレクタ実装はGSPDのセレクタとして、送信元アドレス、宛先アドレス、プロトコル、および方向を使用することができなければなりません。
All the implementations MUST support manual configuration of the Security Associations (SAs) that will be used to authenticate PIM-SM link-local messages. This does not preclude the use of a negotiation protocol such as the Group Domain Of Interpretation (GDOI) [RFC3547] or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] to establish these SAs.
すべての実装は、PIM-SMのリンクローカルのメッセージを認証するために使用されるセキュリティアソシエーション（SA）の手動設定をサポートしなければなりません。これは、これらのSAを確立するために、このような解釈のグループのドメイン（GDOI）[RFC3547]またはグループセキュア協会鍵管理プロトコル（GSAKMP）[RFC4535]と交渉プロトコルの使用を排除するものではありません。
To establish the SAs at PIM-SM routers, manual key configuration will be feasible when the number of peers (directly connected routers) is small. The Network Administrator will configure a router manually. At that time, the authentication method and the choice of keys SHOULD be configured. The parameters for the Security Association Database (SAD) will be entered. The Network Administrator will also configure the Security Policy Database of a router to ensure the use of the associated SA while sending a link-local message.
ピアの数（直接接続されたルータ）が小さい場合PIM-SMルータでSAを確立するために、手動のキー設定が可能であろう。ネットワーク管理者は、ルータを手動で設定します。その時に、認証方法とキーの選択は、設定する必要があります。セキュリティアソシエーションデータベース（SAD）のためのパラメータが入力されます。ネットワーク管理者はまた、リンクローカルメッセージを送信中に関連したSAの使用を保証するために、ルータのセキュリティポリシーデータベースを構成します。
All the link-local messages of the PIM-SM protocol are sent to the destination address, ALL_PIM_ROUTERS, which is a multicast address. By using the sender address in conjunction with the destination address for Security Association lookup, link-local communication turns into a Source-Specific Multicast (SSM) or "one-to-many" communication.
PIM-SMプロトコルのすべてのリンクローカルメッセージは、マルチキャストアドレス、宛先アドレス、ALL_PIM_ROUTERSに送信されます。セキュリティアソシエーションのルックアップのための宛先アドレスと一緒に送信者アドレスを使用することにより、リンクローカル通信は、ソース固有のマルチキャスト（SSM）または「1対多」の通信になります。
The procedures for automated key management are not specified in this document.
自動化された鍵管理のための手順は、この文書で指定されていません。
One option is to use Group Domain Of Interpretation (GDOI) [RFC3547], which enables a group of users or devices to exchange encrypted data using IPsec data encryption. GDOI has been developed to be used in multicast applications, where the number of end users or devices may be large and the end users or devices can dynamically join/leave a multicast group. However, a PIM router is not expected to join/leave very frequently, and the number of routers is small when compared to the possible number of users of a multicast application. Moreover, most of the PIM routers will be located inside the same administrative domain and are considered to be trusted parties. It is possible that a subset of GDOI functionalities will be sufficient.
1つのオプションは、IPsecのデータ暗号化を使用して暗号化されたデータを交換するために、ユーザーまたはデバイスのグループを可能にする、解釈のグループのドメイン（GDOI）[RFC3547]を使用することです。 GDOIは、エンドユーザーまたはデバイスの数が多くてもよく、エンドユーザまたはデバイスが動的にマルチキャストグループを去る/参加できるマルチキャストアプリケーションにおいて使用されるように開発されました。しかし、PIMルータは非常に頻繁に残す/参加することを期待、およびマルチキャストアプリケーションのユーザの可能な数と比較すると、ルータの数が少ないされていません。また、PIMルータのほとんどは、同じ管理ドメイン内に位置するであろうし、信頼できる関係者であると考えられています。 GDOIの機能のサブセットが十分となる可能性があります。
Another option is to use the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535].
別のオプションは、グループセキュア協会鍵管理プロトコル（GSAKMP）[RFC4535]を使用することです。
Before discussing the set of Security Associations that are required to properly manage a multicast region that is under the control of a single administration, it is necessary to understand the communications patterns that will exist among the routers in this region. From the perspective of a speaking router, the information from that router is sent (multicast) to all of its neighbors. From the perspective of a listening router, the information coming from each of its neighbors is distinct from the information coming from every other router to which it is directly connected. Thus, an administrative region contains many (small) distinct groups, all of which happen to be using the same multicast destination address (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is centered on the associated speaking router.
適切単回投与の制御下にあるマルチキャスト地域を管理するために必要とされるセキュリティアソシエーションのセットを説明する前に、この領域内のルータ間で存在する通信パターンを理解することが必要です。話すルータの観点から、そのルータからの情報は、その隣人のすべてに（マルチキャスト）が送信されます。リスニングルータの観点から、その近隣の各々からの情報は、それが直接接続されているすべての他のルータからの情報と区別されます。このように、管理領域は、同一のマルチキャスト宛先アドレス（例えば、ALL_PIM_ROUTERS、セクション11を参照）を使用することが起こる全てが多くの（小）の異なる基を含み、その各々は、関連話すルータを中心とします。
Consider the example configuration as shown in Figure 1.
図1に示すように、構成例を考えます。
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnections
図1：ルータの相互接続の設定
In this configuration, router R1 has four interfaces, and is the speaking router for a group whose listening routers are routers R2 through R11. Router R9 is the speaking router for a group whose listening routers are routers R1, R8, and R10-R14.
この構成では、ルータR1は、4つのインターフェイスを有しており、リスニングルータであるルータR2 R11を介して、グループのために言えばルータです。ルータR9は、リスニングルータであるルータR1、R8、及びR10-R14のグループのために言えばルータです。
From the perspective of R1 as a speaking router, if a Security Association SA1 is assigned to protect outgoing packets from R1, then it is necessary to distribute the key for this association to each of the routers R2 through R11. Similarly, from the perspective of R9 as a speaking router, if a Security Association is assigned to protect the outgoing packets from R9, then it is necessary to distribute the key for this association to each of the routers R1, R8, and R10 through R14.
セキュリティアソシエーションSA1は、R1から発信パケットを保護するために割り当てられている場合を話すルータとしてR1の観点から、ルータR11経由R2のそれぞれにこの関連付けのために鍵を配布する必要があります。セキュリティアソシエーションは、R9から送信パケットを保護するために割り当てられている場合も同様に、話すルータとしてR9の観点から、R14を介してルータR1、R8、及びR10の各々にこの関連付けのために鍵を配布する必要があります。
From the perspective of R1 as a listening router, all packets arriving from R2 through R11 need to be distinguished from each other, to permit selecting the correct Security Association in the SAD. (Packets from each of the peer routers (R2 through R11) represent communication from a different speaker, with a separate sequence-number space, even though they are sent using the same destination address.) For a multicast Security Association, RFC 4301 permits using the source address in the selection function. If the source addresses used by routers R2 through R11 are globally unique, then the source addresses of the peer routers are sufficient to achieve the differentiation. If the sending routers use link-local addresses, then these addresses are unique only on a per-interface basis, and it is necessary to use the Interface ID tag as an additional selector, i.e., either the selection function has to have the Interface ID tag as one of its inputs or separate SADs have to be maintained for each interface.
リスニングルータとしてR1の観点からは、R11を通じてR2から到着するすべてのパケットはSADで正しいセキュリティアソシエーションを選択可能にするために、個々に区別する必要があります。マルチキャストセキュリティ協会（ピアルータのそれぞれからのパケット（R11を介してR2）、それらが同一の宛先アドレスを使用して送信されていても、別個のシーケンス番号空間と、異なる話者からの通信を表す。）、RFC 4301のを許可使用選択機能のソースアドレス。 R11を通じてルータR2で使用される送信元アドレスがグローバルに一意である場合には、ピアルータの送信元アドレスは、分化を達成するのに十分です。送信ルータはリンクローカルアドレスを使用する場合、これらのアドレスは、インターフェイスごとに一意であり、追加のセレクタとしてのインタフェースIDタグを使用する必要がある、すなわち、いずれかの選択機能は、インタフェースIDを持たなければなりませんその入力又は別のSADの一つとして、タグは、各インターフェイスのために維持されなければなりません。
If the assumption of connectivity to the key server can be made (which is true in the PIM-SM case), then the Group Controller/Key Server (GC/KS) that is used for the management of the keys can be centrally located (and duplicated for reliability). If this assumption cannot be made (i.e., in the case of adjacencies for a unicast router), then some form of "local" key server must be available for each group. Given that the listening routers are never more than one hop away from the speaking router, the speaking router is the obvious place to locate the "local" key server. As such, this may be a useful approach even in the PIM-SM case. This approach has the additional advantage that there is no need to duplicate the local key server for reliability, since if the key server is down, it is very likely that the speaking router is also down.
鍵サーバへの接続の仮定は（PIM-SMの場合も同様である）行うことができる場合は、[グループコントローラ/鍵サーバは、鍵の管理に使用されている（GC / KS）は、中央に配置することができます（そして、）信頼性のために複製。この仮定は（即ち、ユニキャストルータの隣接関係の場合）することができない場合は、「ローカル」キーサーバーのいくつかのフォームは、各グループのために利用可能でなければなりません。リスニングルータがホップ以上離れて話すルータから決してしていないことを考えると、話すルータは、「ローカル」キーサーバーを検索する明白な場所です。このように、これもPIM-SMの場合に有用なアプローチであり得ます。鍵サーバがダウンしている場合、話すルータがダウンしてもである可能性が非常に高いので、このアプローチは、信頼性のためのローカルキーサーバを複製する必要がないというさらなる利点を有します。
Each distinct group consists of one speaker, and the set of directly connected listeners. If the decision is made to maintain one Security Association per speaker (see Section 8), then the key server will need to be aware of the adjacencies of each speaker. Procedures for managing and distributing these adjacencies are out of scope for this document.
各別個のグループには、1つのスピーカ、および直接接続されたリスナーの集合から成ります。決定はスピーカーごとにセキュリティアソシエーション（セクション8を参照）を維持するために行われている場合、鍵サーバは、各スピーカーの隣接関係を認識する必要があります。これらの隣接関係を管理し、配信するための手順は、このドキュメントの範囲外です。
The number of Security Associations to be maintained by a PIM router depends on the required security level and available key management.
PIMルータによって維持されるセキュリティアソシエーションの数は、必要なセキュリティレベルと利用可能な鍵の管理に依存します。
This SHOULD be decided by the Network Administrator. Two different ways are shown in Figures 2 and 3. It is assumed that A, B, and C are three PIM routers, where B and C are directly connected with A, and there is no direct link between B and C.
これは、ネットワーク管理者によって決定されるべきです。二つの異なる方法は、A、B、及びCは、BとCが直接Aに接続された3つのPIMルータ、であり、BとCの間には直接のリンクが存在しないと仮定される図2および図3に示します。
|
+++++ |
+ B + SAb ------------>|
+ + SAa <------------|
+++++ |
|
+++++ SAb <------------|
+ + ---->|
+ + /
+ A + SAa -------
+ + \
+ + ---->|
+++++ SAc <------------|
|
+++++ |
+ C + SAc ------------>|
+ + SAa <------------|
+++++ |
|
Directly connected network
Figure 2: Activate unique Security Association for each peer
図2：各ピアに一意のセキュリティアソシエーションを有効にします
The first method, shown in Figure 2, SHOULD be supported by every implementation. In this method, each node will use a unique SA for its outbound traffic. A, B, and C will use SAa, SAb, and SAc, respectively, for sending any traffic. Each node will include the source address when searching the SAD for a match. Router A will use SAb and SAc for packets received from B and C, respectively. The number of SAs to be activated and maintained by a PIM router will be equal to the number of directly connected routers, plus one for sending its own traffic. Also, the addition of a PIM router in the network will require the addition of another SA on every directly connected PIM router. This solution will be scalable and practically feasible with an automated key management protocol. However, it MAY be used with manual key management, if the number of directly connected routers is small.
図2に示す第1の方法は、すべての実装によってサポートされてください。この方法では、各ノードがそのアウトバウンドトラフィックのためのユニークなSAを使用します。 、B、及びCは、すべてのトラフィックを送信するために、それぞれ、SAaに、SAbを、およびSACを使用します。一致するSADを検索するときに各ノードは送信元アドレスが含まれます。ルータAは、それぞれ、B及びCから受信したパケットに対してたSAbとSACを使用します。 SAの数は活性化され、それ自身のトラフィックを送信するために直接接続されたルータの数プラス1に等しくなりPIMルータによって維持されます。また、ネットワーク内のPIMルータの追加は、すべての直接接続されているPIMルータ上の別のSAの追加が必要になります。このソリューションは、自動化された鍵管理プロトコルでスケーラブルかつ実用的に実現可能になります。直接接続されたルータの数が少ない場合しかし、それは、手動鍵管理に使用されるかもしれません。
|
+++++ |
+ B + SAo ------------>|
+ + SAi <------------|
+++++ |
|
+++++ SAi <------------|
+ + ---->|
+ + /
+ A + SAo -------
+ + \
+ + ---->|
+++++ SAi <------------|
|
+++++ |
+ C + SAo ------------>|
+ + SAi <------------|
+++++ |
|
Directly connected network
Figure 3: Activate two Security Associations
図3：2セキュリティアソシエーションを有効にします
The second method, shown in Figure 3, MUST be supported by every implementation. In this simple method, all the nodes will use two SAs, one for sending (SAo) and the other for receiving (SAi) traffic. Thus, the number of SAs is always two and will not be affected by addition of a PIM router. Although two different SAs (i.e., SAo and SAi) are used in this method, the SA parameters (keys, Security Parameter Index (SPI), etc.) for the two SAs are identical, i.e., the same information is shared among all the routers in an administrative region. This document RECOMMENDS this second method for manual key configuration. However, it MAY also be used with automated key configuration.
図3に示す第2の方法は、すべての実装によってサポートされなければなりません。この単純な方法では、すべてのノードが2つのSA、送信のための1つ（SAO）及び（SAiの）トラフィックを受信するための他の使用されます。このように、SAの数は常に2で、PIMルータの添加によって影響されることはありません。二つの異なるSAの（すなわち、SAOとSAiの）はこの方法で使用されているが、2つのSAのためのSAパラメータ（キー、セキュリティパラメータインデックス（SPI）、等）、すなわち、同一であり、同一の情報は、すべての間で共有されています行政地域内のルータ。この文書では、手動鍵設定のため、この第二の方法を推奨しています。しかし、それはまた、自動化されたキー構成で使用されるかもしれません。
An analysis of the considerations for key management is provided in RFC 4107 [RFC4107].
鍵管理のための考慮事項の分析は、RFC 4107 [RFC4107]に提供されます。
In PIM-SM deployments it is expected that secure sessions will be relatively long-lived, and it is not expected that keys will be significantly exposed through normal operational activity. Manual keying is judged acceptable in the light of the relatively low rate of change that is required.
PIM-SMでは、安全なセッションが比較的長寿命であることが期待されるデプロイメント、およびキーが大きく、通常の運用活動を介して公開されることが期待されていません。手動キーが必要とされる変化の比較的低い速度に照らして許容されると判定されました。
To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically, to limit the risk of undetected key disclosure. Keys SHOULD also be changed when there is a change of trusted personnel.
リンクのセキュリティを維持するために、認証と暗号化キーの値が検出されないキーの開示のリスクを制限するために、定期的に変更する必要があります。信頼された人員の変更があった場合キーも変更する必要があります。
Manual keying offers the ability to change keys in a coordinated way, but it has several drawbacks in PIM-SM systems. Some of these are listed in Section 15 ("Security Considerations") of this document.
手動キーイングは協調して、キーを変更する機能を提供していますが、それは、PIM-SMのシステムにいくつかの欠点を有します。これらのいくつかは、このドキュメントのセクション15（「セキュリティの考慮事項」）に記載されています。
According to an analysis in line with RFC 4107 [RFC4107], PIM-SM would benefit from automated key management and roll over because all the disadvantages of manual keys listed in Section 15 would be eliminated. However, suitable techniques for automated key management do not currently exist. Work is in hand in the IETF to develop suitable solutions. In the meantime, implementations MUST support manual rekeying as described below. Implementers and deployers need to be aware of the requirement to upgrade to support automated key management as soon as suitable techniques are available.
RFC 4107 [RFC4107]に沿った分析によれば、PIM-SMは、自動化された鍵管理の恩恵を受けるとセクション15に記載されているマニュアルキーの全ての欠点が解消されることになるので、ロールオーバーであろう。しかし、自動化された鍵管理のための適切な技術は現在存在しません。作業は、適切なソリューションを開発するために、IETFで手にあります。以下に説明するように、その間に、実装は、手動キー更新をサポートしなければなりません。実装者とデプロイヤはすぐに適切な技術が利用できるよう自動鍵管理をサポートするためにアップグレードする必要性を認識する必要があります。
In accordance with the requirements of RFC 4107 [RFC4107], the following three-step procedure provides a possible mechanism to rekey the routers on a link without dropping PIM-SM protocol packets or disrupting the adjacency, while ensuring that it is always clear which key is being used.
RFC 4107 [RFC4107]の要件に応じて、次の三段階の手順は、必ずしも明確であることを保証しながら、PIM-SMプロトコルパケットをドロップまたは隣接を中断することなく、リンク上のルータをリキーするための可能なメカニズムを提供するキー使用されています。
1. For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
1.リンク上のすべてのルータの場合は、新しいSPI、新しいキーを使用してリキーされているインタフェースのための追加のインバウンドSAを作成します。
2. For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation MUST be atomic with respect to sending PIM-SM packets on the link, so that no PIM-SM packets are sent without authentication/encryption
2.リンク上のすべてのルータの場合は、新しいSPIおよびキー値を使用して1と元アウトバウンドSAを交換してください。何PIM-SMパケットは認証/暗号化せずに送信されないようにSAの交換作業は、リンク上のPIM-SMパケットの送信に対してアトミックでなければなりません
Note that all routers on the link MUST complete step 1 before any begin step 2. Likewise, all the routers on the link MUST complete step 2 before any begin step 3.
同様に、ステップ2を開始し、リンク上のすべてのルータは、任意の前に、ステップ1を完了しなければならないことに注意してください、リンク上のすべてのルータは、ステップ3を開始する前に任意のステップ2を完了する必要があります。
One way to control the progression from one step to another is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.
各ルータは、一定KeyRolloverInterval設定可能な時間を持っているため、別の1つのステップからの進行を制御するための1つの方法です。ルータが所与のリンク上でステップ1を開始した後、それはこの間隔の間待機してからステップ2に移動した後、同様にステップ2に移動し、それはこの間隔の間待機してからステップ3に進みます。
In order to achieve smooth key transition, all routers on a link MUST use the same value for KeyRolloverInterval and MUST initiate the key rollover process within this time period.
滑らかなキー移行を達成するために、リンク上のすべてのルータがKeyRolloverIntervalに同じ値を使用する必要があり、この時間内にキーロールオーバプロセスを開始しなければなりません。
At the end of this time period, all the routers on the link will have a single inbound and outbound SA for PIM-SM with the new SPI and key values.
この期間の終わりに、リンク上のすべてのルータが新しいSPIおよびキー値を持つPIM-SMのための単一のインバウンドとアウトバウンドのSAを持っています。
The configured value of KeyRolloverInterval needs to be long enough to allow the Administrator to change keys on all the PIM-SM routers. As this value can vary significantly depending on the implementation and the deployment, it is left to the Administrator to choose an appropriate value.
KeyRolloverIntervalの設定された値は、管理者がすべてのPIM-SMルータ上のキーを変更することができるように十分な長さが必要です。この値は実装と展開によって大きく異なる可能性がありますが、適切な値を選択するには、管理者に任されています。
In keeping with the goal of reducing key exposure, the encryption and authentication keys SHOULD be changed at least every 90 days.
キーエクスポージャーを削減するという目標を踏まえて、暗号化および認証鍵は、少なくとも90日ごとに変更する必要があります。
The Administrator must configure the necessary Security Associations. Each SA entry has the source address of an authorized peer, and a Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the manually configured SAs MUST be assigned by the Administrator to ensure that the SPI does not conflict with existing SPI values in the SAD.
管理者は、必要なセキュリティアソシエーションを設定する必要があります。各SAエントリは、許可ピアの送信元アドレス、およびALL_PIM_ROUTERSの宛先アドレスを持っています。手動で設定したSAのためのユニークなSPI値は、SPIは、SADの既存のSPI値と競合しないことを確実にするには、管理者によって割り当てなければなりません。
The Administrator must configure the necessary SPD entries. The SPD entry must ensure that any outbound IP traffic packet traversing the IPsec boundary, with PIM as its next layer protocol and sent to the Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH. Note that this characterization includes all the link-local messages (Hello, Join/Prune, Bootstrap, Assert).
管理者は、必要なSPDエントリを設定する必要があります。 SPDエントリは、任意の発信IPトラフィックのパケットは、その次の層のプロトコルとしてPIMで、IPsecの境界を横断してALL_PIM_ROUTERSの宛先アドレスに送信され、ESPまたはAHで保護されていることを確認する必要があります。この特性は、すべてのリンクローカルメッセージを含んでいることに注意してください（こんにちは、参加/プルーン、ブートストラップ、アサート）。
When automatic keying is used, the SA creation is done dynamically using a group key management protocol. The GSPD and PAD tables are configured by the Administrator. The PAD table provides the link between the IPsec subsystem and the group key management protocol.
自動キーを使用した場合、SAの作成は、グループ鍵管理プロトコルを使用して動的に行われます。 GSPDとパッドの表は、管理者によって設定されています。 PADのテーブルは、IPsecサブシステムおよびグループ鍵管理プロトコルとの間のリンクを提供します。
For automatic keying, the implementation MUST support the multicast extensions described in [RFC5374].
自動キーイングのために、実装は、[RFC5374]に記載されたマルチキャスト拡張をサポートしなければなりません。
All PIM routers participate in an authentication scheme that identifies permitted neighbors and achieves peer authentication during SA negotiation, leading to child SAs being established and saved in the SAD.
すべてのPIMルータが許可隣人を識別し、SAがSADに設立され、保存されている子につながる、SAのネゴシエーション中にピア認証を実現する認証スキームに参加しています。
The Administrator must configure the necessary GSPD entries for "sender only" directionality. This rule MUST trigger the group key management protocol for a registration exchange. This exchange will set up the outbound SAD entry that encrypts the multicast PIM control message. Considering that this rule is "sender only", no inbound SA is created in the reverse direction.
管理者は、「送信者のみ」の方向性のために必要なGSPDエントリを設定する必要があります。この規則は、登録交換のためのグループ鍵管理プロトコルを起動する必要があります。この交換は、マルチキャストPIM制御メッセージを暗号化し、アウトバウンドSADエントリを設定します。このルールは、「送信者のみ」であることを考えると、何のインバウンドSAは、逆方向に作成されません。
In addition, the registration exchange will trigger the installation of the GSPD entries corresponding to each legitimate peer router, with direction "receiver only". Procedures for achieving the registration exchange are out of scope for this document.
また、登録交換は方向「のみ受信」で、各正規のピア・ルータに対応するGSPDエントリのインストールをトリガします。登録交換を達成するための手順は、このドキュメントの範囲外です。
A router SHOULD NOT dynamically detect new neighbors as the result of receiving an unauthenticated PIM-SM link-local message or an IPsec packet that fails an SAD lookup. An automated key management protocol SHOULD provide a means of notifying a router of new, legitimate neighbors.
ルータが動的に認証されていないPIM-SMのリンクローカルメッセージやSADのルックアップに失敗したIPsecパケットを受信した結果として、新しい隣人は検出されません。自動化された鍵管理プロトコルは、新たな、正当な隣人のルータに通知する手段を提供する必要があります。
The PAD will be configured with information to permit identification of legitimate group members and senders (i.e., to control the adjacency). Procedures for doing this are out of scope for this document.
PADは、（隣接関係を制御する、すなわち）正当なグループメンバーと送信者の識別を可能にするための情報で構成されます。これを行うための手順は、このドキュメントの範囲外です。
For an SA that carries unicast traffic, three parameters (SPI, destination address, and security protocol type (AH or ESP)) are used in the Security Association lookup process for inbound packets. The SPI is sufficient to specify an SA. However, an implementation may use the SPI in conjunction with the IPsec protocol type (AH or ESP) for the SA lookup process. According to RFC 4301 [RFC4301], for multicast SAs, in conjunction with the SPI, the destination address or the destination address plus the sender address may also be used in the SA lookup. This applies to both ESP and AH. The security protocol field is not employed for a multicast SA lookup.
ユニキャストトラフィックを運ぶSA、3つのパラメータ（SPI、宛先アドレス、およびセキュリティプロトコルの種類（AHまたはESP））インバウンドパケットのセキュリティアソシエーションの検索プロセスで使用されています。 SPIは、SAを特定するのに十分です。しかし、実装がSAルックアッププロセスのためのIPsecプロトコルタイプ（AHまたはESP）と一緒にSPIを使用することができます。 RFC 4301によれば、[RFC4301]、マルチキャストSAの、SPIと連動して、宛先アドレスまたは宛先アドレスと送信元アドレスもSAルックアップで使用されてもよいです。これは、ESPとAHの両方に適用されます。セキュリティプロトコルフィールドは、マルチキャストSAの検索に採用されていません。
Given that, from the prospective of a receiving router, each peer router is an independent sender and given that the destination address will be the same for all senders, the receiving router MUST use SPI plus destination address plus sender address when performing the SA lookup. In effect, link-local communication is an SSM communication that happens to use an Any-Source Multicast (ASM) address (which is shared among all the routers).
SAの検索を行うときに、受信側ルータの将来から、各ピアルータが独立して、送信者である、ということを考えると、宛先アドレスがすべての送信者のために同じであることを考えると、受信ルータはSPIプラスの宛先アドレスと送信元アドレスを使用する必要があります。実際には、リンクローカル通信は、（すべてのルータ間で共有されている）でも、ソースマルチキャスト（ASM）アドレスを使用するように起こるSSM通信です。
Given that it is always possible to distinguish a connection using IPsec from a connection not using IPsec, it is recommended that the address ALL_PIM_ROUTERS be used, to maintain consistency with present practice.
IPsecを使用していない接続からのIPsecを使用して接続を区別することが常に可能であることを考えると、現在の練習との整合性を維持するために、アドレスALL_PIM_ROUTERSを使用することをお勧めします。
Given that the sender address of an incoming packet may be only locally unique (because of the use of link-local addresses), it is necessary for a receiver to use the interface ID tag to determine the associated SA for that sender. Therefore, this document mandates that the interface ID tag, the SPI, and the sender address MUST be used in the SA lookup process.
受信機は、その送信者に関連付けられたSAを決定するために、インタフェースIDタグを使用する着信パケットの送信元アドレスが（なぜなら、リンクローカルアドレスの使用）のみ局所的に一意とすることができることを考えると、それが必要です。したがって、インタフェースIDタグ、SPI、および送信元アドレスは、SA検索プロセスで使用する必要があり、この文書の義務。
Although link-level messages on a link constitute a multiple-sender, multiple-receiver group, the use of the interface ID tag and sender address for SA lookup essentially resolves the communication into a separate SA for each sender/destination pair, even for the case where only two SAs (with identical SA parameters) are used for the entire administrative region. Therefore, the statement in the AH RFC (Section 2.5 of [RFC4302]) that "for a multi-sender SA, the anti-replay features are not available" becomes irrelevant to the PIM-SM link-local message exchange.
リンクのリンク・レベル・メッセージは、複数の送信者、複数の受信機群を構成するが、SAルックアップするためのインタフェースIDタグと送信元アドレスの使用は、本質的にもために、各送信元/宛先ペアのための別個のSAへの通信を解決します（同一のSAパラメータを持つ）2つだけのSA全体の管理領域に使用されている場合。したがって、「マルチ送信者SAのために、アンチリプレイ機能は利用できません」というAH RFC（[RFC4302]のセクション2.5）内のステートメントは、PIM-SMリンクローカルメッセージ交換に無関係となります。
To activate the anti-replay mechanism in a unicast communication, the receiver uses the sliding window protocol and it maintains a sequence number for this protocol. This sequence number starts from zero.
ユニキャスト通信におけるアンチリプレイ機構を活性化するために、受信機は、スライディング・ウィンドウ・プロトコルを使用し、それがこのプロトコルのシーケンス番号を維持します。このシーケンス番号は0から始まります。
Each time the sender sends a new packet, it increments this number by one. In a multi-sender multicast group communication, a single sequence number for the entire group would not be enough.
送信者が、新たなパケットを送信するたびに、それは1で、この番号をインクリメントします。マルチ送信側マルチキャストグループ通信では、グループ全体のための単一のシーケンス番号が十分ではないであろう。
The whole scenario is different for PIM link-local messages. These messages are sent to local links with TTL = 1. A link-local message never propagates through one router to another. The use of the sender address and the interface ID tag for SA lookup converts the relationship from a multiple-sender group to multiple single-sender associations. This specification RECOMMENDS activation of the anti-replay mechanism only if the SAs are assigned using an automated key management procedure. If manual key management is used, the anti-replay SHOULD NOT be activated.
全体のシナリオは、PIMリンクローカルメッセージに対して異なっています。これらのメッセージは、TTL = 1のリンクローカルメッセージが別のルーターを介して伝播したことがないとのローカルリンクに送信されます。 SAルックアップのための送信元アドレス及びインタフェースIDタグの使用は、複数の単一の送信者団体への複数の送信者グループから関係を変換します。この仕様は、SASは、自動化された鍵管理手順を使用して割り当てられている場合にのみ、アンチリプレイ機構の活性化を推奨しています。手動鍵管理が使用されている場合、アンチリプレイをアクティブにしないでください。
If an existing router has to restart, in accordance with RFC 4303 [RFC4303], the sequence-number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced.
既存のルータは、RFC 4303 [RFC4303]に基づいて、再起動する必要がある場合、キーが交換されるまで、送信側のシーケンス番号カウンタが正しく、など地元の再起動後、全体で維持しなければなりません。
RFC 4601 suggests that it may be desirable to implement a separate Security Policy Database (SPD) for each router interface. The use of link-local addresses in certain circumstances implies that differentiation of ambiguous speaker addresses requires the use of the interface ID tag in the SA lookup. One way to do this is through the use of multiple SPDs. Alternatively, the interface ID tag may be a specific component of the selector algorithm. This is in conformance with RFC 4301, which explicitly removes the requirement for separate SPDs that was present in RFC 2401 [RFC2401].
RFC 4601は、各ルータインターフェイスのための個別のセキュリティポリシーデータベース（SPD）を実装することが望ましい場合があることを示唆しています。特定の状況でリンクローカルアドレスを使用すると、あいまいな話者アドレスの分化がSA検索におけるインタフェースIDタグの使用が必要であることを意味します。これを行う1つの方法は、複数のSPDを使用することです。代替的に、インタフェースIDタグは、セレクタアルゴリズムの具体的な構成要素であってもよいです。これは、明示的にRFC 2401 [RFC2401]に存在していた別のSPDのための要件を除去RFC 4301、に準拠しています。
In the [RFC4302], there is a provision for a 64-bit Extended Sequence Number (ESN) as the counter of the sliding window used in the anti-replay protocol. Both the sender and the receiver maintain a 64-bit counter for the sequence number, although only the lower order 32 bits are sent in the transmission. In other words, it will not affect the present header format of AH. If ESN is used, a sender router can send 2^64 -1 packets without any intervention. This number is very large, and from a PIM router's point of view, a PIM router can never exceed this number in its lifetime. This makes it reasonable to permit manual configuration for a small number of PIM routers, since the sequence number will never roll over. For this reason, when manual configuration is used, ESN SHOULD be deployed as the sequence number for the sliding window protocol. In addition, when an ESN is used with a manually keyed SA, it MUST be saved over a reboot, along with an indication of which sequence numbers have been used.
[RFC4302]において、アンチリプレイプロトコルで使用されるスライディング・ウィンドウのカウンタとして64ビット拡張シーケンス番号（ESN）のための規定があります。唯一の下位32ビットが送信で送信されているが送信側と受信側の両方が、シーケンス番号の64ビットカウンタを維持します。換言すれば、AHの現在のヘッダフォーマットに影響を与えないであろう。 ESNを使用する場合、送信元ルータは、任意の介入なしに2 ^ 64 -1のパケットを送信することができます。この数は非常に多く、ビューのPIMルータの観点から、PIMルータはその一生の間に、この数を超えることはできません。シーケンス番号はロールオーバーすることはありませんので、これは、PIMルータの数が少ないため、手動設定を可能とすることが合理的になります。手動設定を使用する場合、このような理由から、ESNは、スライディングウィンドウプロトコルのシーケンス番号として展開されるべきです。 ESNを手動でキー付きSAで使用された場合に加えて、それはシーケンス番号が使用されているかの指示とともに、再起動にわたって保存しなければなりません。
The whole document considers the security issues of PIM link-local messages and proposes a mechanism to protect them.
文書全体は、PIMリンクローカルメッセージのセキュリティ問題を考慮し、それらを保護するためのメカニズムを提案しています。
Limitations of manual keys:
手動キーの制限事項：
The following are some of the known limitations of the usage of manual keys.
次の手動キーの使用の既知の制限のいくつかです。
o If replay protection cannot be provided, the PIM routers will not be secured against all the attacks that can be performed by replaying PIM packets.
リプレイ保護を提供することができない場合は、O、PIMルータがPIMパケットを再生することにより行うことができるすべての攻撃から保護されることはありません。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
手動キーは、通常は長生きしているO（多くの場合、それらを変更することは面倒な作業です）。これは、攻撃者に鍵を発見するのに十分な時間を与えます。
o As the Administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).
管理者が手動でキーを設定されているようにO、構成されたキーが（DES / 3DESのための既知の弱いキーが少なくとも存在する）弱い可能性があります。
Impersonation attacks:
偽装攻撃：
The usage of the same key on all the PIM routers connected to a link leaves them all insecure against impersonation attacks if any one of the PIM routers is compromised, malfunctioning, or misconfigured.
PIMルータのいずれかが、誤動作妥協、または誤って設定されている場合、リンクに接続されたすべてのPIMルータで同じキーの使用は、なりすまし攻撃に対する安全でないそれらをすべて残します。
Detailed analysis of various vulnerabilities of routing protocols is provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and multicast security, the reader is referred to RFC 5294 [RFC5294], RFC 4609 [RFC4609], and the Security Considerations section of RFC 4601 [RFC4601].
ルーティングプロトコルの様々な脆弱性の詳細な分析は、RFC 4593 [RFC4593]に提供されます。 PIM-SMおよびマルチキャストセキュリティの詳細な説明については、読者は、RFC 5294 [RFC5294]、RFC 4609 [RFC4609]、およびRFC 4601 [RFC4601]のSecurity Considerations部と呼ばれます。
The structure and text of this document draw heavily from RFC 4552 [RFC4552]. The authors of this document thank M. Gupta and N. Melam for permission to do this.
このドキュメントの構造とテキストは、RFC 4552 [RFC4552]から大きく描きます。本書の著者は、これを行うための許可をM.グプタとN.メラムに感謝します。
The quality of this document was substantially improved after SECDIR pre-review by Brian Weis, and after AD review by Adrian Farrel.
このドキュメントの品質は、実質的にブライアン・ワイスによってSECDIR事前審査の後、およびエードリアンファレルによるADの審査後に改善しました。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[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月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]フランケル、S.、グレン、R.、およびS.ケリー、 "AES-CBC暗号アルゴリズムおよびIPSecでの使用"、RFC 3602、2003年9月。
[RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997.
[RFC2117] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL 。魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2117、1997年6月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、およびV. Jacobsonの、「プロトコル独立マルチキャスト - スパースモード（PIM-SM） ：プロトコル仕様」、RFC 2362、1998年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008.
[RFC5294] Savola、P.およびJ.リンガード、RFC 5294、2008年8月 "プロトコル独立マルチキャスト（PIM）へのホストの脅威"。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006.
[RFC4609] Savola、P.、Lehtonenの、R.、およびD.マイヤー、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）マルチキャストルーティングセキュリティの問題と機能拡張"、RFC 4609、2006年10月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]グプタ、M.およびN.メラム、 "OSPFv3のための認証/機密性"、RFC 4552、2006年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
Authors' Addresses
著者のアドレス
J. William Atwood Concordia University/CSE 1455 de Maisonneuve Blvd. West Montreal, QC H3G 1M8 Canada
J.ウィリアム・アトウッドコンコーディア大学/ SSC 1455デMaisonneuveブルバード西モントリオール、QC H3G 1M8カナダ
Phone: +1(514)848-2424 ext3046 EMail: bill@cse.concordia.ca URI: http://users.encs.concordia.ca/~bill
電話：+1(514)848-2424 ext3046 Eメール：URI bill@cse.concordia.ca：http://users.encs.concordia.ca/~bill
Salekul Islam INRS Energie, Materiaux et Telecommunications 800 de La Gauchetiere, Suite 800 Montreal, QC H5A 1K6 Canada
Salekulイスラム教INRSエネルギー材料と電気通信800ラGauchetiere、スイート800モントリオール、QC H5A 1K6カナダ
EMail: Salekul.Islam@emt.inrs.ca URI: http://users.encs.concordia.ca/~salek_is
電子メール：Salekul.Islam@emt.inrs.ca URI：http://users.encs.concordia.ca/~salek_is
Maziar Siami Concordia University/CIISE 1455 de Maisonneuve Blvd. West Montreal, QC H3G 1M8 Canada
Maziar Siamiコンコーディア大学/ CIISE 1455デMaisonneuveブルバード西モントリオール、QC H3G 1M8カナダ
EMail: mzrsm@yahoo.ca
メールアドレス：mzrsm@yahoo.ca