[要約] RFC 5796は、PIM-SMリンクローカルメッセージの認証と機密性に関する規格です。目的は、PIM-SMプロトコルでのセキュリティを向上させ、リンクローカルメッセージの認証と機密性を提供することです。
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.
RFC 4601は、IPSECを使用して、プロトコルに依存しないマルチキャスト - スパースモード（PIM-SM）ルーティングプロトコルでのリンクローカルメッセージの認証を確保することを義務付けています。このドキュメントは、セキュリティペイロード（ESP）をカプセル化するIPセキュリティ（IPSEC）または（オプションでは）認証ヘッダー（AH）を使用して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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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 ....................................................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があります。一部のコントロールメッセージはユニカストです。残りはマルチキャストで、Live（TTL）= 1の時間があります。ユニキャストメッセージに使用されるソースアドレスは、ドメイン全体の到達可能なアドレスです。マルチキャストメッセージの場合、メッセージが送信されているインターフェイスのリンクローカルアドレスがソースアドレスと特別なマルチキャストアドレスとして使用されます。ALL_PIM_Routers（IPv4の224.0.0.13およびIPv6のFF02 :: D）を使用して使用します。宛先アドレス。これらのメッセージは、link-localメッセージと呼ばれます。こんにちは、参加/プルン、そしてこのカテゴリにアサートメッセージが含まれています。攻撃者は、鍛造リンクローカルメッセージを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 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.
このドキュメントは、Link-Localメッセージのセキュリティ問題に焦点を当てています。RFC 4302の新しい許可されたAH機能とRFC 4303 [RFC4303]の新しい許可されたESP機能を活用し、PIM-SM仕様を新しいAHおよびESP仕様と整列させるためのいくつかのガイドラインを提供します。特に、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.
Link-Local Securityの主な目標は、各Link-Localメッセージのデータ起源認証を提供することです。二次的な目標は、正当なピア（つまり、隣接するルーター）間で通信が発生するようにすることです。オプションの目標は、Link-Localメッセージにデータの機密性を提供することです。
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.
最初の目標は、各ルーターが一意のアイデンティティを持っていることを意味します。このアイデンティティがルーターのユニキャストアイデンティティに基づいていることは可能です（必須ではありません）。（例えば、ユニキャストのアイデンティティは、ルーターの個別に構成されたプロパティに基づいているか、地域全体の公開インフラストラクチャの一部である可能性があります。）この独自のアイデンティティの存在は、この仕様で想定されていますが、それを確立する手順は想定されています。このドキュメントの範囲外です。
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.
2番目の目標は、隣接するマルチキャストルーター間のセキュリティ関連の確立を制御する何らかの形の「隣接マトリックス」があることを意味します。手動キーの場合、このコントロールは、初期化パラメーターの設定を通じて、ルーターの管理者によって行使されます。自動化されたキーイングの場合、このコントロールの存在は、ピア認証データベース（PAD）（RFC 4301 [RFC4301]を参照）またはグループセキュリティポリシーデータベース（GSPDを参照）（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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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 Link-Localメッセージに必要な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 Link-Localメッセージの認証を提供するために、実装は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 In Transport Modeを使用すると、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 Link-Localメッセージの認証が有効になっている場合、
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.
o AHまたはESPで保護されていないPIM-SM Link-Localパケットは、IPSECによって静かに破棄されますが、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.
o IPSECの実装はそのようなパケットのカウンターを維持する場合がありますが、認証チェックに失敗する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.
認証は、適合の実装によってサポートされる必要があるため、実装は非ヌル暗号化とヌル認証の組み合わせを生成してはなりません。
Note: when confidentiality for PIM-SM link-local packets is enabled,
注：PIM-SM Link-Localパケットの機密性が有効になっている場合、
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.
o ESPで保護されていないPIM-SMパケットは、IPSECによって静かに破棄されますが、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.
暗号化と認証アルゴリズムRFC 4835 [RFC4835]で説明されている暗号化と認証アルゴリズムの要件は、PIM-SMを保護するためにESPとAHを使用する場合に適用されます。実装はESP-Nullをサポートする必要があり、機密性を提供する場合は、[RFC4835]で必要な機密性を提供するESP変換をサポートする必要があります。ただし、いずれにせよ、実装では、ユーザーがマニュアルキーで使用するためにカウンターモードでストリーム暗号またはブロックモード暗号を選択できるようにしてはなりません。
Encapsulation of ESP packets IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
ESPパケットのカプセル化IP ESPパケットのカプセル化をサポートする必要があります。簡単にするために、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選択関数を備えた複数のGSPDをサポートする必要があります。
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リンクローカルメッセージの認証に使用されるセキュリティ協会（SAS）の手動構成をサポートする必要があります。これは、これらのSASを確立するために、グループセキュアアソシエーションキー管理プロトコル（GSAKMP）[RFC4535]など、解釈のグループドメイン（GDOI）[RFC3547]またはグループセキュアーアソシエーションの主要な管理プロトコルなどのネゴシエーションプロトコルの使用を排除するものではありません。
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ルーターでSASを確立するために、ピア数（直接接続されたルーター）が小さい場合、手動のキー構成が実行可能になります。ネットワーク管理者は、手動でルーターを構成します。その時点で、認証方法とキーの選択を構成する必要があります。セキュリティ協会データベース（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プロトコルのすべてのLink-Localメッセージは、マルチキャストアドレスである宛先アドレス、ALL_PIM_Routersに送信されます。セキュリティ協会の検索のための宛先アドレスと組み合わせて送信者アドレスを使用することにより、Link-Local Communicationはソース固有のマルチキャスト（SSM）または「1対Many」通信に変わります。
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つのオプションは、グループドメインの解釈（GDOI）[RFC3547]を使用することです。これにより、ユーザーまたはデバイスのグループがIPSECデータ暗号化を使用して暗号化されたデータを交換できます。GDOIは、マルチキャストアプリケーションで使用されるように開発されており、エンドユーザーまたはデバイスの数が大きくなり、エンドユーザーまたはデバイスがマルチキャストグループに動的に結合/離れることができます。ただし、PIMルーターは非常に頻繁に結合/放置することは期待されておらず、マルチキャストアプリケーションのユーザー数と比較すると、ルーターの数は少なくなります。さらに、ほとんどのPIMルーターは同じ管理ドメイン内に配置され、信頼できる当事者と見なされます。GDOI機能のサブセットで十分である可能性があります。
Another option is to use the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535].
別のオプションは、グループSecure Association Key Management Protocol（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.
この構成では、Router R1には4つのインターフェイスがあり、リスニングルーターがR1からR11からルーターがルーターであるグループのスピーキングルーターです。Router 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.
R1のスピーキングルーターとしての観点から、セキュリティアソシエーションSA1がR1から発信パケットを保護するために割り当てられている場合、この協会のキーを各ルーターR2からR11に分配する必要があります。同様に、R9のスピーキングルーターとしての観点から、発信パケットをR9から保護するためにセキュリティアソシエーションが割り当てられている場合、この関連付けのキーを各ルーターR1、R8、およびR14からR14に分配する必要があります。。
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の観点から見ると、R2からR11からR11から到着するすべてのパケットは、SADで正しいセキュリティアソシエーションを選択できるようにするために互いに区別する必要があります。（ピアルーターのそれぞれ（R2からR11）のパケットは、同じ宛先アドレスを使用して送信されている場合でも、別のスピーカーからの通信を表します。選択関数のソースアドレス。ルーターR2からR11で使用されるソースアドレスがグローバルに一意である場合、ピアルーターのソースアドレスは分化を達成するのに十分です。送信ルーターがリンクローカルアドレスを使用する場合、これらのアドレスはインターフェイスごとにのみ一意であり、インターフェイスIDタグを追加セレクターとして使用する必要があります。つまり、選択関数にはインターフェイスIDが必要です。インターフェイスごとに、入力または個別のSADの1つとしてタグを維持する必要があります。
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）を中央に配置できます（信頼性のために複製）。この仮定を行うことができない場合（つまり、ユニキャストルーターの隣接の場合）、各グループで何らかの形の「ローカル」キーサーバーが利用可能でなければなりません。リスニングルーターがスピーキングルーターから1つ以上離れていないことを考えると、スピーキングルーターは「ローカル」キーサーバーを見つけるための明らかな場所です。そのため、これは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つのスピーカーと、直接接続されたリスナーのセットで構成されています。スピーカーごとに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.
これは、ネットワーク管理者によって決定される必要があります。2つの異なる方法を図2と3に示します。A、B、およびCは3つのPIMルーターであり、BとCはAに直接接続されており、BとCの間に直接的なリンクはありません。
|
+++++ |
+ 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に示す最初の方法は、すべての実装によってサポートされる必要があります。この方法では、各ノードはアウトバウンドトラフィックに一意のSAを使用します。A、B、およびCは、トラフィックを送信するためにそれぞれSAA、SAB、およびSACを使用します。各ノードには、試合をSADを検索するときにソースアドレスが含まれます。ルーターAは、それぞれBとCから受信したパケットにSABとSACを使用します。PIMルーターによってアクティブ化および維持されるSAの数は、直接接続されたルーターの数に加えて、独自のトラフィックを送信するために等しくなります。また、ネットワークに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つのSASを使用します。1つは送信（SAO）に、もう1つは受信（SAI）トラフィック用に使用されます。したがって、SASの数は常に2つであり、PIMルーターの添加により影響を受けません。この方法では2つの異なるSAS（つまり、SAOとSAI）が使用されていますが、2つのSAのSAパラメーター（キー、セキュリティパラメーターインデックス（SPI）など）は同一です。つまり、同じ情報がすべての間で共有されます。管理地域のルーター。このドキュメントは、手動キー構成のためにこの2番目の方法を推奨しています。ただし、自動化されたキー構成でも使用できます。
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]の要件に従って、次の3段階の手順は、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とキー値を使用して、元のアウトバウンドSAを使用したものに置き換えます。SA置換操作は、リンク上のPIM-SMパケットの送信に関してアトミックでなければなりません。そうすれば、PIM-SMパケットは認証/暗号化なしで送信されません。
3. For every router on the link, remove the original inbound SA.
3. リンク上のすべてのルーターについて、元のインバウンドSAを削除します。
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.
あるステップから別のステップへの進行を制御する1つの方法は、各ルーターが構成可能な時代定数Keyrolovervalvalを持つことです。ルーターが特定のリンクでステップ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.
スムーズなキー遷移を実現するには、リンク上のすべてのルーターがKeyroloverIntervalに同じ値を使用する必要があり、この期間内にキーロールオーバープロセスを開始する必要があります。
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.
KeyroloverIntervalの構成された値は、管理者がすべての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の宛先アドレスがあります。手動で構成されたSASの一意の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エントリは、PIMを次のレイヤープロトコルとして使用して、IPSEC境界を通過するアウトバウンドIPトラフィックパケットがALL_PIM_Routersの宛先アドレスに送信されることを確認する必要があります。この特性評価には、すべてのリンクローカルメッセージが含まれていることに注意してください（Hello、Join/Prune、Bootstrap、Assert）。
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とパッドテーブルは、管理者によって構成されています。パッドテーブルは、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の交渉中にピア認証を達成する認証スキームに参加し、子SASが確立され、SADに保存されます。
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コントロールメッセージを暗号化するアウトバウンドの悲しいエントリが設定されます。このルールが「送信者のみ」であることを考慮すると、逆方向にインバウンド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リンクローカルメッセージまたは悲しい検索に失敗する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.
パッドは、正当なグループメンバーと送信者の識別を許可するために情報で構成されます（つまり、隣接を制御するため）。これを行うための手順は、このドキュメントの範囲外です。
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]によれば、マルチキャストSASの場合、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プラスデスティネーションアドレスと送信者アドレスを使用する必要があります。実際、Link-Local通信は、任意のソースマルチキャスト（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_Routerを使用して、現在の実践との一貫性を維持することをお勧めします。
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.
着信パケットの送信者アドレスがローカルでのみ一意である可能性があることを考えると（リンクローカルアドレスの使用のため）、受信者はインターフェイスIDタグを使用してその送信者の関連するSAを決定する必要があります。したがって、このドキュメントは、インターフェイス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に通信が解決されます。管理地域全体に2つのSAS（同一の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.
ユニキャスト通信でアンチレプレイメカニズムをアクティブにするために、受信機はスライディングウィンドウプロトコルを使用し、このプロトコルのシーケンス番号を維持します。このシーケンス番号はゼロから始まります。
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 Link-Localメッセージで異なります。これらのメッセージは、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 4301に準拠しており、RFC 2401 [RFC2401]に存在する個別のSPDの要件を明示的に削除します。
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）の規定があります。送信者と受信機の両方がシーケンス番号の64ビットカウンターを維持しますが、低次の32ビットのみが送信に送信されます。つまり、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]のセキュリティに関する考慮事項セクションと呼ばれます。
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. GuptaとN. Melamに感謝します。
The quality of this document was substantially improved after SECDIR pre-review by Brian Weis, and after AD review by Adrian Farrel.
このドキュメントの品質は、ブライアン・ワイスによるSecdir Pre-Reviewの後、およびAdrian Farrelによる広告レビューの後に大幅に改善されました。
[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] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[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月。
[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. Glenn、「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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。、およびL。Wei、「プロトコル独立したマルチキャストスパールモード（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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M。、およびV. Jacobson、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、「GSAKMP：Group Secure Association Key Management Protocol」、RFC 4535、2006年6月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、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. Lingard、「Protocol Independent Multicast（PIM）に対するホストの脅威」、RFC 5294、2008年8月。
[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. Meyer、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）マルチキャストルーティングセキュリティの問題と機能強化」、RFC 4609、2006年10月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「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.ウィリアムアトウッドコンコルディア大学/CSE 1455 de Maisonneuve Blvd.ウェストモントリオール、QC H3G 1M8カナダ
Phone: +1(514)848-2424 ext3046
EMail: bill@cse.concordia.ca
URI: 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 Islam Inrs Energie、Materiaux et Telecommunications 800 De La Gauchetiere、Suite 800 Montreal、QC H5A 1K6 Canada
EMail: 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 Concordia University/Ciise 1455 De Maisonneuve Blvd.ウェストモントリオール、QC H3G 1M8カナダ
EMail: mzrsm@yahoo.ca