Network Working Group B. Weis
Request for Comments: 5374 Cisco Systems
Category: Standards Track G. Gross
Secure Multicast Networks LLC
D. Ignjatic
Polycom
November 2008
Multicast Extensions to the
Security Architecture for the Internet Protocol
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast.
インターネットプロトコルのためのセキュリティアーキテクチャは、IP層でのトラフィックのためのセキュリティ・サービスについて説明します。そのアーキテクチャは、主にインターネット・プロトコル（IP）ユニキャストパケットのためのサービスを定義します。この文書では、IPsecセキュリティサービスは、IPマルチキャストパケットに適用する方法について説明します。これらの拡張機能は、マルチキャストをサポートしているIPsec実装に関連しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................4
2. Overview of IP Multicast Operation ..............................6
3. Security Association Modes ......................................7
3.1. Tunnel Mode with Address Preservation ......................7
4. Security Association ............................................8
4.1. Major IPsec Databases ......................................8
4.1.1. Group Security Policy Database (GSPD) ...............8
4.1.2. Security Association Database (SAD) ................12
4.1.3. Group Peer Authorization Database (GPAD) ...........12
4.2. Group Security Association (GSA) ..........................14
4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover .15
4.3. Data Origin Authentication ................................17
4.4. Group SA and Key Management ...............................18
4.4.1. Co-Existence of Multiple Key Management Protocols ..18
5. IP Traffic Processing ..........................................18
5.1. Outbound IP Traffic Processing ............................18
5.2. Inbound IP Traffic Processing .............................19
6. Security Considerations ........................................22
6.1. Security Issues Solved by IPsec Multicast Extensions ......22
6.2. Security Issues Not Solved by IPsec Multicast Extensions ..23
6.2.1. Outsider Attacks ...................................23
6.2.2. Insider Attacks ....................................23
6.3. Implementation or Deployment Issues that Impact Security ..24
6.3.1. Homogeneous Group Cryptographic Algorithm
Capabilities .......................................24
6.3.2. Groups that Span Two or More Security
Policy Domains .....................................24
6.3.3. Source-Specific Multicast Group Sender
Transient Locators .................................25
7. Acknowledgements ...............................................25
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................26
Appendix A - Multicast Application Service Models .................28
A.1 Unidirectional Multicast Applications ......................28
A.2 Bi-directional Reliable Multicast Applications .............28
A.3 Any-To-Any Multicast Applications ..........................30
Appendix B - ASN.1 for a GSPD Entry ...............................30
B.1 Fields Specific to a GSPD Entry ............................30
B.2 SPDModule ..................................................31
The Security Architecture for the Internet Protocol [RFC4301] provides security services for traffic at the IP layer. It describes an architecture for IPsec-compliant systems and a set of security services for the IP layer. These security services primarily describe services and semantics for IPsec Security Associations (SAs) shared between two IPsec devices. Typically, this includes SAs with traffic selectors that include a unicast address in the IP destination field, and results in an IPsec packet with a unicast address in the IP destination field. The security services defined in RFC 4301 can also be used to tunnel IP multicast packets, where the tunnel is a pairwise association between two IPsec devices. RFC 4301 defined manually keyed transport mode IPsec SA support for IP packets with a multicast address in the IP destination address field. However, RFC 4301 did not define the interaction of an IPsec subsystem with a Group Key Management protocol or the semantics of a tunnel mode IPsec SA with an IP multicast address in the outer IP header.
インターネットプロトコル[RFC4301]のためのセキュリティアーキテクチャは、IP層でのトラフィックのセキュリティサービスを提供します。これは、IPsec準拠のシステムのためのアーキテクチャとIP層のセキュリティサービスのセットを記述する。これらのセキュリティサービスは、主に次の2つのIPSecデバイス間で共有IPsecセキュリティアソシエーション（SA）をするためのサービスとセマンティクスを説明します。典型的には、これは、トラフィックのIP宛先フィールドにユニキャストアドレスを含むセレクタ、およびIP宛先フィールドにユニキャストアドレスをIPsecパケット内の結果とSAを含みます。 RFC 4301で定義されたセキュリティサービスはまた、トンネルは2つのIPSecデバイス間のペアワイズ関連でトンネルIPマルチキャストパケットに使用することができます。 RFC 4301は、手動でIP宛先アドレスフィールドにマルチキャストアドレスを持つIPパケットのためのキー付きトランスポート・モードのIPsec SAのサポートを定義しました。ただし、RFC 4301には、グループ鍵管理プロトコルまたは外側のIPヘッダ内のIPマルチキャストアドレスを持つトンネルモードのIPsec SAの意味でのIPsecサブシステムの相互作用を定義していませんでした。
This document describes OPTIONAL extensions to RFC 4301 that further define the IPsec security architecture in order for groups of IPsec devices to share SAs. In particular, it supports SAs with traffic selectors that include a multicast address in the IP destination field and that result in an IPsec packet with an IP multicast address in the IP destination field. It also describes additional semantics for IPsec Group Key Management (GKM) subsystems. Note that this document uses the term "GKM protocol" generically and therefore does not assume a particular GKM protocol.
この文書では、さらにSAを共有するためのIPsecデバイスのグループのための順序でIPsecセキュリティ・アーキテクチャを定義するRFC 4301には、オプションの拡張機能について説明します。特に、それは、IP宛先フィールド内のマルチキャストアドレスとIP宛先フィールド内のIPマルチキャストアドレスを持つIPsecパケットでその結果を含めるトラフィックセレクタとSAをサポートしています。また、IPsecのグループ鍵管理（GKM）サブシステムのための追加的な意味を説明しています。この文書は、用語「GKMプロトコル」を使用して一般的に、したがって、特定のGKMプロトコルを想定していないことに留意されたいです。
An IPsec implementation that does not support multicast is not required to support these extensions.
マルチキャストをサポートしていないIPsec実装は、これらの拡張をサポートする必要はありません。
Throughout this document, RFC 4301 semantics remain unchanged by the presence of these multicast extensions unless specifically noted to the contrary.
特に反対に述べない限り、このドキュメントでは、RFC 4301点の意味は、これらのマルチキャスト拡張の存在によって変更されないまま。
The IPsec extensions described in this document support IPsec Security Associations that result in IPsec packets with IPv4 or IPv6 multicast group addresses as the destination address. Both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] group addresses are supported. These extensions are used when management policy requires that IP multicast packets protected by IPsec remain IP multicast packets. When management policy requires that the IP multicast packets be encapsulated as IP unicast packets (e.g., because the network connected to the unprotected interface does not support IP multicast), the extensions in this document are not used.
宛先アドレスとしてIPv4またはIPv6マルチキャストグループアドレスを持つIPsecパケットの結果、このドキュメントのサポートIPsecセキュリティアソシエーションで説明したIPsec拡張。任意-ソースマルチキャスト（ASM）およびソース固有マルチキャスト（SSM）[RFC3569]グループアドレスがサポートされ、両方。経営方針は、IPsecので保護されたIPマルチキャストパケットがIPマルチキャストパケットのままでいることを必要とするときに、これらの拡張機能が使用されます。管理ポリシーは、（保護されていないインターフェイスに接続されたネットワークがIPマルチキャストをサポートしていないため、例えば、）IPマルチキャストパケットをIPユニキャストパケットとしてカプセル化されることを要求する場合、この文書に記載されている拡張機能が使用されていません。
These extensions also support Security Associations with IPv4 Broadcast addresses that result in an IPv4 link-level Broadcast packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. These destination address types share many of the same characteristics of multicast addresses because there may be multiple candidate receivers of a packet protected by IPsec.
これらの拡張機能はまた、IPv4リンクレベルのブロードキャストパケットにつながるのIPv4ブロードキャストアドレス、およびIPv6エニーキャストパケットにつながるIPv6エニーキャストアドレス[RFC2526]でセキュリティアソシエーションをサポートしています。 IPSecで保護されたパケットの複数の候補の受信機が存在し得るので、これらの宛先アドレスタイプは、マルチキャストアドレスの同じ特徴の多くを共有します。
The IPsec architecture does not make requirements upon entities not participating in IPsec (e.g., network devices between IPsec endpoints). As such, these multicast extensions do not require intermediate systems in a multicast-enabled network to participate in IPsec. In particular, no requirements are placed on the use of multicast routing protocols (e.g., Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]) or multicast admission protocols (e.g., Internet Group Management Protocol (IGMP) [RFC3376]).
IPsecのアーキテクチャは、IPsec（IPsecのエンドポイント間、例えば、ネットワーク機器）に参加していないエンティティ時に要件がありません。このように、これらのマルチキャストの拡張機能は、IPsecに参加するマルチキャスト対応ネットワークにおける中間システムを必要としません。具体的には、何の要件は、マルチキャストルーティングプロトコル（例えば、プロトコル独立マルチキャスト - スパースモード（PIM-SM）[RFC4601]）の使用に配置されていないか、マルチキャストアドミッションプロトコル（例えば、インターネットグループ管理プロトコル（IGMP）[RFC3376]） 。
All implementation models of IPsec (e.g., "bump-in-the-stack", "bump-in-the-wire") are supported.
IPsecのすべての実装モデル（例えば、「バンプ・イン・スタック」、「バンプ・イン・ザ・ワイヤー」）がサポートされています。
This version of the multicast IPsec extension specification requires that all IPsec devices participating in a Security Association be homogeneous. They MUST share a common set of cryptographic transform and protocol-handling capabilities. The semantics of an "IPsec composite group" [COMPGRP], a heterogeneous IPsec cryptographic group formed from the union of two or more sub-groups, is an area for future standardization.
マルチキャストIPsecの拡張仕様のこのバージョンでは、セキュリティアソシエーションに参加するすべてのIPsecデバイスが均一であることが必要です。彼らは、暗号変換とプロトコル処理機能の共通セットを共有しなければなりません。 「IPsecの複合基」[COMPGRP]のセマンティクスは、2つ以上のサブグループの結合から形成される異質のIPsec暗号グループは、将来の標準化のための領域です。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The following key terms are used throughout this document.
以下の重要な用語は、この文書全体で使用されています。
Any-Source Multicast (ASM) The Internet Protocol (IP) multicast service model as defined in RFC 1112 [RFC1112]. In this model, one or more senders source packets to a single IP multicast address. When receivers join the group, they receive all packets sent to that IP multicast address. This is known as a (*,G) group.
どれ-ソースマルチキャスト（ASM）RFC 1112 [RFC1112]で定義されているインターネット・プロトコル（IP）マルチキャストサービスモデル。このモデルでは、単一のIPマルチキャストアドレスへの1つのまたは複数の送信者ソースパケットを。受信機がグループに参加すると、彼らはそのIPマルチキャストアドレスに送信されたすべてのパケットを受信します。これは、（*、G）のグループとして知られています。
Group A set of devices that work together to protect group communications.
グループAは、グループ通信を保護するために一緒に働くデバイスのセット。
Group Controller Key Server (GCKS) A Group Key Management (GKM) protocol server that manages IPsec state for a group. A GCKS authenticates and provides the IPsec SA policy and keying material to GKM Group Members.
グループコントローラキーサーバ（GCKS）グループのためのIPsec状態を管理するグループ鍵管理（GKM）プロトコルサーバ。 GCKSは認証し、GKMグループメンバーへのIPsec SA方針とキーイング材料を提供します。
Group Key Management (GKM) Protocol A key management protocol used by a GCKS to distribute IPsec Security Association policy and keying material. A GKM protocol is used when a group of IPsec devices require the same SAs. For example, when an IPsec SA describes an IP multicast destination, the sender and all receivers need to have the group SA.
グループ鍵管理（GKM）プロトコルのIPsecセキュリティアソシエーションポリシーとキーを配布するためにGCKSが使用する鍵管理プロトコル。 IPSecデバイスのグループは、同じSAを必要とする場合GKMプロトコルが使用されています。 IPsecのSAは、IPマルチキャスト宛先を説明する際、例えば、送信者とすべての受信機は、グループSAを持っている必要があります。
Group Key Management Subsystem A subsystem in an IPsec device implementing a Group Key Management protocol. The GKM subsystem provides IPsec SAs to the IPsec subsystem on the IPsec device. Refer to RFC 3547 [RFC3547] and RFC 4535 [RFC4535] for additional information.
グループ鍵管理サブシステムのグループ鍵管理プロトコルを実装したIPsecデバイスにおけるサブシステム。 GKMサブシステムは、IPsecデバイス上のIPsecサブシステムへのIPsec SAを提供します。詳細については、RFC 3547 [RFC3547]及びRFC 4535 [RFC4535]を参照。
Group Member An IPsec device that belongs to a group. A Group Member is authorized to be a Group Sender and/or a Group Receiver.
グループに属しているグループメンバーアンのIPsecデバイス。グループメンバーは、グループの送信者および/またはグループレシーバーことを許可されています。
Group Owner An administrative entity that chooses the policy for a group.
グループ所有者アングループのポリシーを選択し、管理するエンティティ。
Group Security Association (GSA) A collection of IPsec Security Associations (SAs) and GKM subsystem SAs necessary for a Group Member to receive key updates. A GSA describes the working policy for a group. Refer to RFC 4046 [RFC4046] for additional information.
グループセキュリティ協会（GSA）のIPsecセキュリティアソシエーション（SA）とグループメンバーのために必要なGKMサブシステムのSAのコレクションは、キーの更新を受信します。 GSAは、グループの作業方針を説明しています。詳細については、RFC 4046 [RFC4046]を参照してください。
Group Security Policy Database (GSPD) The GSPD is a multicast-capable security policy database, as mentioned in RFC 3740 and Section 4.4.1.1. of RFC 4301. Its semantics are a superset of the unicast Security Policy Database (SPD) defined by Section 4.4.1 of RFC 4301. Unlike a unicast SPD-S, in which point-to-point traffic selectors are inherently bi-directional, multicast security traffic selectors in the GSPD-S include a "sender only", "receiver only", or "symmetric" directional attribute. Refer to Section 4.1.1 for more details.
RFC 3740および4.4.1.1項で述べたように、グループセキュリティポリシーデータベース（GSPD）はGSPDは、マルチキャスト対応のセキュリティポリシーデータベースです。 RFCの4301、その意味は、ポイントツーポイントのトラフィックセレクタは本質的に双方向されたユニキャストSPD-Sとは異なり、RFC 4301のセクション4.4.1で定義されたユニキャストセキュリティポリシーデータベース（SPD）のスーパーセットでGSPD-Sでのマルチキャストセキュリティトラフィックセレクタは、「送信者のみ」、「のみ受信」、または「対称」の方向属性が含まれます。詳細は、4.1.1項を参照してください。
GSPD-S, GSPD-I, GSPD-O Group Security Policy Database (secure traffic), (inbound), and (outbound), respectively. See Section 4.4.1 of RFC 4301.
それぞれGSPD-S、GSPD-I、GSPD-Oグループセキュリティポリシーデータベース（トラフィックを保護）、（インバウンド）、および（アウトバウンド）、。 RFC 4301の4.4.1項を参照してください。
Group Receiver A Group Member that is authorized to receive packets sent to a group by a Group Sender.
グループ送信者によってグループに送信されたパケットを受信することを許可され、グループレシーバーAグループのメンバー。
Group Sender A Group Member that is authorized to send packets to a group.
グループにパケットを送信することを許可されたグループの送信者Aグループメンバー。
Source-Specific Multicast (SSM) The Internet Protocol (IP) multicast service model as defined in RFC 3569 [RFC3569]. In this model, each combination of a sender and an IP multicast address is considered a group. This is known as an (S,G) group.
ソース固有マルチキャスト（SSM）RFC 3569 [RFC3569]で定義されているインターネットプロトコル（IP）マルチキャストサービスモデル。このモデルでは、送信者の各組み合わせとIPマルチキャストアドレスは、グループと考えられています。これは（S、G）群として知られています。
Tunnel Mode with Address Preservation A type of IPsec tunnel mode used by security gateway implementations when encapsulating IP multicast packets such that they remain IP multicast packets. This mode is necessary for IP multicast routing to correctly route IP multicast packets protected by IPsec.
それらはIPマルチキャストパケット残るようにIPマルチキャストパケットをカプセル化するときに、セキュリティゲートウェイの実装で使用されるIPsecトンネルモードのアドレス保存型のトンネルモード。このモードでは、IPsecで保護され正しくルーティングIPマルチキャストパケットのIPマルチキャストルーティングのために必要です。
IP multicasting is a means of sending a single packet to a "host group", a set of zero or more hosts identified by a single IP destination address. IP multicast packets are delivered to all members of the group either with "best-efforts" reliability [RFC1112] or as part of a reliable stream (e.g., NACK-Oriented Reliable Multicast (NORM) [RFC3940]).
IPマルチキャストは、「ホストグループ」は、単一のIP宛先アドレスによって識別されるゼロ以上のホストのセットに単一のパケットを送信する手段です。 IPマルチキャストパケットは、「最良の努力」信頼[RFC1112]を有する、または信頼できるストリーム（例えば、NACK指向高信頼マルチキャスト（NORM）[RFC3940]）の一部としてのいずれかのグループのすべてのメンバーに配信されます。
A sender to an IP multicast group sets the destination of the packet to an IP address that has been allocated for IP multicast. Allocated IP multicast addresses are defined in [RFC3171], [RFC3306], and [RFC3307]. Potential receivers of the packet "join" the IP multicast group by registering with a network routing device ([RFC3376], [RFC3810]), signaling its intent to receive packets sent to a particular IP multicast group.
IPマルチキャストグループへの送信者がIPマルチキャストのために割り当てられたIPアドレスにパケットの宛先を設定します。割り当てられたIPマルチキャストアドレス[RFC3171]で定義され、[RFC3306]及び[RFC3307]。パケットの潜在的な受信機はネットワークルーティング装置に登録することにより、IPマルチキャストグループに「参加」（[RFC3376]を、[RFC3810]）、特定のIPマルチキャストグループに送信されたパケットを受信するために、その意図をシグナリング。
Network routing devices configured to pass IP multicast packets participate in multicast routing protocols (e.g., PIM-SM) [RFC4601]. Multicast routing protocols maintain state regarding which devices have registered to receive packets for a particular IP multicast group. When a router receives an IP multicast packet, it forwards a copy of the packet out of each interface for which there are known receivers.
IPマルチキャストパケットを通過させるように構成されたネットワーク・ルーティング・デバイスは、マルチキャストルーティングプロトコル（例えば、PIM-SM）[RFC4601]に参加します。マルチキャストルーティングプロトコルは、デバイスが特定のIPマルチキャストグループのパケットを受信するために登録しているかに関する状態を維持します。ルータは、IPマルチキャストパケットを受信すると、受信機が知られているため、各インターフェイスからパケットのコピーを転送します。
IPsec supports two modes of use: transport mode and tunnel mode. In transport mode, IP Authentication Header (AH) [RFC4302] and IP Encapsulating Security Payload (ESP) [RFC4303] provide protection primarily for next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets.
トランスポートモードとトンネルモード：IPsecは、使用の2つのモードがサポートされています。トランスポートモードでは、IP認証ヘッダ（AH）[RFC4302]とIPカプセル化セキュリティペイロード（ESP）[RFC4303]は、主に次の層プロトコルのための保護を提供します。トンネルモードでは、AHとESPは、トンネルIPパケットに適用されます。
A host implementation of IPsec using the multicast extensions MAY use either transport mode or tunnel mode to encapsulate an IP multicast packet. These processing rules are identical to the rules described in Section 4.1 of [RFC4301]. However, the destination address for the IPsec packet is an IP multicast address, rather than a unicast host address.
マルチキャスト拡張を使用したIPsecのホスト実装は、IPマルチキャストパケットをカプセル化するトランスポートモードまたはトンネルモードのいずれかを使用することができます。これら処理規則は[RFC4301]のセクション4.1で説明された規則と同じです。しかし、IPsecパケットの宛先アドレスは、IPマルチキャストアドレスではなく、ユニキャストホストアドレスです。
A security gateway implementation of IPsec MUST use a tunnel mode SA, for the reasons described in Section 4.1 of [RFC4301]. In particular, the security gateway needs to use tunnel mode to encapsulate incoming fragments, since IPsec cannot directly operate on fragments.
IPsecのセキュリティゲートウェイ実装は、[RFC4301]のセクション4.1で説明する理由のために、トンネルモードSAを使用しなければなりません。具体的には、セキュリティゲートウェイは、IPsecを直接フラグメント上で動作することができないため、着信フラグメントをカプセル化するトンネルモードを使用する必要があります。
New (tunnel) header construction semantics are required when tunnel mode is used to encapsulate IP multicast packets that are to remain IP multicast packets. These semantics are due to the following unique requirements of IP multicast routing protocols (e.g., PIM-SM [RFC4601]). This document describes these new header construction semantics as "tunnel mode with address preservation", which is described as follows.
トンネルモードは、IPマルチキャストパケットのままになっているIPマルチキャストパケットをカプセル化するために使用される場合、新しい（トンネル）ヘッダ構造のセマンティクスが必要です。これらのセマンティクスは、IPマルチキャストルーティングプロトコル（例えば、PIM-SM [RFC4601]）の以下の固有の要件に起因しています。この文書は、以下のように記載され、「アドレス保存とトンネルモード」と、これらの新しいヘッダ構造セマンティクスを記述しています。
- When an IP multicast packet is received by a host or router, the destination address of the packet is compared to the local IP multicast state. If the (outer) destination IP address of an IP multicast packet is set to another IP address, the host or router receiving the IP multicast packet will not process it properly. Therefore, an IPsec security gateway needs to populate the multicast IP destination address in the outer header using the destination address from the inner header after IPsec tunnel encapsulation.
- IPマルチキャストパケットは、ホスト又はルータによって受信されると、パケットの宛先アドレスがローカルIPマルチキャスト状態と比較されます。 IPマルチキャストパケットの（外側の）宛先IPアドレスが別のIPアドレスに設定されている場合は、IPマルチキャストパケットを受信したホストまたはルータが適切に処理されません。したがって、IPsecセキュリティゲートウェイは、IPsecトンネルカプセル化の後に内部ヘッダから宛先アドレスを使用して、外部ヘッダ内のマルチキャストIP宛先アドレスを移入する必要があります。
- IP multicast routing protocols typically create multicast distribution trees based on the source address as well as the group address. If an IPsec security gateway populates the (outer) source address of an IP multicast packet (with its own IP address, as called for in RFC 4301), the resulting IPsec-protected packet may fail Reverse Path Forwarding (RPF) checks performed by other routers. A failed RPF check may result in the packet being dropped. To accommodate routing protocol RPF checks, the security gateway implementing the IPsec multicast extensions SHOULD populate the outer IP address from the original packet IP source address. However, it should be noted that a security gateway performing source address preservation will not receive ICMP Path MTU (PMTU) or other messages intended for the security gateway (triggered by packets that have had the outer IP source address set to that of the inner header). Security gateway applications not requiring source address preservation will be able to receive ICMP PMTU messages and process them as described in Section 6.1 of RFC 4301.
- IPマルチキャストルーティングプロトコルは、典型的には、送信元アドレス、ならびにグループアドレスに基づいてマルチキャスト配信ツリーを作成します。 IPsecセキュリティゲートウェイが（RFC 4301中に呼び出されるよう、自身のIPアドレスを持つ）IPマルチキャストパケットの（外側の）ソースアドレスを移入した場合、得られたIPsecで保護されたパケットは、他によって行わリバースパス転送（RPF）チェックに失敗することがありルータ。失敗したRPFチェックは落とされるパケットをもたらすことができます。ルーティングプロトコルRPFチェックを収容するために、IPsecのマルチキャスト拡張を実装するセキュリティゲートウェイは、元のパケットのIPソースアドレスから外部IPアドレスを取り込むべきです。しかし、内部ヘッダのものに設定し、外側のIP送信元アドレスを持っていたパケットによってトリガ（送信元アドレスの保存を行うセキュリティゲートウェイがICMPパスMTU（PMTU）またはセキュリティゲートウェイのために意図他のメッセージを受信しないことに留意すべきです）。 RFC 4301のセクション6.1で説明したように、送信元アドレスの保存を必要としないセキュリティゲートウェイアプリケーションは、ICMP PMTUメッセージを受信し、それらを処理することができるようになります。
Because some applications of address preservation may require that only the destination address be preserved, specification of destination address preservation and source address preservation are separated in the above description. Destination address preservation and source address preservation attributes are described in the Group Security Policy Database (GSPD) (defined later in this document), and are copied into corresponding Security Association Database (SAD) entries.
アドレス保存のいくつかのアプリケーションは、宛先アドレスだけが保存されることを必要とする可能性があるため、宛先アドレス保存及び送信元アドレス保存の仕様は、上記の説明では分離されています。宛先アドレスの保存と送信元アドレスの保存属性が（本書の後半で定義された）グループセキュリティポリシーデータベース（GSPD）に記載されており、セキュリティアソシエーションデータベース（SAD）エントリに対応するにコピーされます。
Address preservation is applicable only for tunnel mode IPsec SAs that specify the IP version of the encapsulating header to be the same version as that of the inner header. When the IP versions are different, IP multicast packets can be encapsulated using a tunnel interface, for example as described in [RFC4891], where the tunnel is also treated as an interface by IP multicast routing protocols.
アドレス保存は、内部ヘッダのと同じバージョンであることをカプセル化ヘッダのIPのバージョンを指定するトンネルモードのIPsec SAの適用可能です。 IPバージョンが異なる場合、トンネルはまたIPマルチキャストルーティングプロトコルによってインターフェイスとして扱われる[RFC4891]に記載されているように、IPマルチキャストパケットは、例えば、トンネルインタフェースを使用してカプセル化することができます。
In summary, propagating both the IP source and destination addresses of the inner IP header into the outer (tunnel) header allows IP multicast routing protocols to route a packet properly when the packet is protected by IPsec. This result is necessary in order for the multicast extensions to allow a host or security gateway to provide IPsec services for IP multicast packets. This method of RFC 4301 tunnel mode is known as "tunnel mode with address preservation".
要約すると、IPソースおよび外側（トンネル）ヘッダに内側IPヘッダの宛先アドレスの両方を伝搬する経路にパケットがIPSecで保護され、適切にパケットをIPマルチキャストルーティングプロトコルを可能にします。この結果は、ホストまたはセキュリティゲートウェイは、IPマルチキャストパケットのためのIPsecサービスを提供できるように、マルチキャスト拡張のために必要です。 RFC 4301トンネルモードのこの方法は、「アドレス保存とトンネルモード」として知られています。
The following sections describe the GKM subsystem and IPsec extension interactions with the IPsec databases. The major IPsec databases need expanded semantics to fully support multicast.
次のセクションでは、IPsecのデータベースとGKMサブシステムとIPsec拡張相互作用を記述する。主要なIPsecのデータベースは完全にマルチキャストをサポートするように拡張セマンティクスを必要としています。
The Group Security Policy Database is a security policy database capable of supporting both unicast Security Associations as defined by RFC 4301 and the multicast extensions defined by this
RFC 4301で定義されたマルチキャストの拡張機能は、このことで定義されるように、グループセキュリティポリシーデータベースは、両方のユニキャストセキュリティアソシエーションをサポート可能なセキュリティポリシーデータベースです
specification. The GSPD is considered to be the SPD, with the addition of the semantics relating to the multicast extensions described in this section. Appendix B provides an example of an ASN.1 definition of a GSPD entry.
仕様。 GSPDは、このセクションで説明マルチキャスト拡張に関連するセマンティクスを添加して、SPDであると考えられます。付録BはGSPDエントリーのASN.1定義の例を提供します。
This document describes a new "address preservation" (AP) flag indicating that tunnel mode with address preservation is to be applied to a GSPD entry. The AP flag has two attributes: AP-L, used in the processing of the local tunnel address, and AP-R, used in the processing of the remote tunnel process. This flag is added to the GSPD "Processing info" field of the GSPD. The following text reproduced from Section 4.4.1.2 of RFC 4301 is amended to include this additional processing. (Note: for brevity, only the "Processing info" text related to tunnel processing has been reproduced.)
このドキュメントは、アドレス保存とトンネルモードはGSPDエントリに適用されることを示す新たな「アドレス保存」（AP）フラグを記述する。ローカルトンネルアドレスの処理に使用されるAP-L、およびAP-R、リモートトンネルプロセスの処理に用いられる：APフラグ2つの属性を有しています。このフラグはGSPD GSPDの「処理情報」フィールドに追加されます。 RFC 4301のセクション4.4.1.2から再生された次のテキストは、この追加処理を含めるように修正されます。 （注：簡潔にするため、トンネル処理に関係するだけで「処理情報」のテキストが再現されています。）
o Processing info -- which action is required -- PROTECT,
BYPASS, or DISCARD. There is just one action that goes with
all the selector sets, not a separate action for each set.
If the required processing is PROTECT, the entry contains the
following information.
- IPsec mode -- tunnel or transport
- (if tunnel mode) local tunnel address -- For a non-mobile
host, if there is just one interface, this is
straightforward; if there are multiple interfaces, this
must be statically configured. For a mobile host, the
specification of the local address is handled externally to
IPsec. If tunnel mode with address preservation is
specified for the local tunnel address, the AP-L attribute
is set to TRUE for the local tunnel address and the local
tunnel address is unspecified. The presence of the AP-L
attribute indicates that the inner IP header source address
will be copied to the outer IP header source address during
IP header construction for tunnel mode.
- (if tunnel mode) remote tunnel address -- There is no
standard way to determine this. See Section 4.5.3 of RFC
4301, "Locating a Security Gateway". If tunnel mode with
address preservation is specified for the remote tunnel
address, the AP-R attribute is set to TRUE for the remote
tunnel address and the remote tunnel address is
unspecified. The presence of the AP-R attribute indicates
that the inner IP header destination address will be copied
to the outer IP header destination address during IP header
construction for tunnel mode.
This document describes unique directionality processing for GSPD entries with a remote IP multicast address. Since an IP multicast address must not be sent as the source address of an IP packet
この文書では、リモートIPマルチキャストアドレスを持つGSPDエントリのためのユニークな方向性の処理を記述します。 IPマルチキャストアドレスは、IPパケットの送信元アドレスとして送信されてはならないので、
[RFC1112], directionality of Local and Remote addresses and ports is maintained during incoming SPD-S and SPD-I checks rather than being swapped. Section 4.4.1 of RFC 4301 is amended as follows:
[RFC1112]、ローカルおよびリモートのアドレスとポートの方向性は、着信SPD-S中に維持され、SPD-Iをチェックするよりもむしろが交換されます。次のようにRFC 4301のセクション4.4.1が改正されています。
Representing Directionality in an SPD Entry
SPDエントリーに方向性を表します
For traffic protected by IPsec, the Local and Remote address and ports in an SPD entry are swapped to represent directionality, consistent with IKE conventions. In general, the protocols that IPsec deals with have the property of requiring symmetric SAs with flipped Local/Remote IP addresses. However, SPD entries with a remote IP multicast address do not have their Local and Remote addresses and ports in an SPD entry swapped during incoming SPD-S and SPD-I checks.
SPDエントリにIPsecの、ローカルおよびリモートのアドレスとポートによって保護されたトラフィックのためのIKEの規則と一致方向性を、表現するためにスワップされます。一般的に、IPsecはを扱うプロトコルが反転し、リモート/ローカルIPアドレスで対称SAを必要とする性質を持っています。ただし、リモートIPマルチキャストアドレスを持つSPDエントリは、着信SPD-SとSPD-Iチェック中にスワップSPDエントリに自分のローカルおよびリモートのアドレスとポートを持っていません。
A new Group Security Policy Database (GSPD) attribute is introduced: GSPD entry directionality. The following text is added to the bullet list of SPD fields described in Section 4.4.1.2 of RFC 4301.
新しいグループセキュリティポリシーデータベース（GSPD）属性が導入されていますGSPDエントリー指向性を。次のテキストは、RFC 4301のセクション4.4.1.2で説明したSPDフィールドの箇条書きリストに追加されます。
o Directionality -- can be one of three types: "symmetric",
"sender only", or "receiver only". "Symmetric" indicates
that a pair of SAs are to be created (one in each direction,
as specified by RFC 4301). GSPD entries marked as "sender
only" indicate that one SA is to be created in the outbound
direction. GSPD entries marked as "receiver only" indicate
that one SA is to be created in the inbound direction. GSPD
entries marked as "sender only" or "receiver only" SHOULD
support multicast IP addresses in their destination address
selectors. If the processing requested is BYPASS or DISCARD
and a "sender only" type is configured, the entry MUST be put
in GSPD-O only. Reciprocally, if the type is "receiver
only", the entry MUST go to GSPD-I only.
GSPD entries created by a GCKS may be assigned identical Security Parameter Indexes (SPIs) to SAD entries created by IKEv2 [RFC4306]. This is not a problem for the inbound traffic as the appropriate SAs can be matched using the algorithm described in Section 4.1 of RFC 4301. However, the outbound traffic needs to be matched against the GSPD selectors so that the appropriate SA can be created.
GCKSによって作成GSPDエントリはのIKEv2 [RFC4306]によって作成されたSADのエントリに同じセキュリティパラメータインデックス（SPIの）割り当てられてもよいです。適切なSAが適切なSAを作成することができるように、しかし、アウトバウンドトラフィックはGSPDセレクタと照合する必要がRFC 4301のセクション4.1で説明したアルゴリズムを使用して一致させることができるので、これは着信トラフィックのための問題ではありません。
To facilitate dynamic group keying, the outbound GSPD MUST implement a policy action capability that triggers a GKM protocol registration exchange (as per Section 5.1 of [RFC4301]). For example, the Group Sender GSPD policy might trigger on a match with a specified multicast application packet that is entering the implementation via the protected interface or that is emitted by the implementation on the protected side of the boundary and directed toward the unprotected interface. The ensuing Group Sender registration exchange would set up the Group Sender's outbound SAD entry that encrypts the multicast application's data stream. In the inverse direction, group policy may also set up an inbound IPsec SA.
動的グループキーを容易にするために、アウトバウンドGSPDは（[RFC4301]のセクション5.1による）GKMプロトコル登録交換をトリガするポリシーアクションの機能を実装しなければなりません。例えば、グループ送信者GSPDポリシーは、保護されたインタフェースを介して実装に入っている指定されたマルチキャストアプリケーションパケットとの一致でトリガ可能性があるか、その境界の保護された側の実装によって放出され、保護されていないインタフェースに向けられます。その後のグループ送信者の登録交換は、マルチキャストアプリケーションのデータ・ストリームを暗号化し、グループの送信者のアウトバウンドSADエントリを設定します。逆方向では、グループポリシーはまた、インバウンドのIPsec SAを設定することもできます。
At the Group Receiver endpoint(s), the IPsec subsystem MAY use GSPD policy mechanisms that initiate a GKM protocol registration exchange. One such policy mechanism might be on the detection of a device in the protected network joining a multicast group matching GSPD policy (e.g., by receiving a IGMP/MLD (Multicast Listener Discovery) join group message on a protected interface). The ensuing Group Receiver registration exchange would set up the Group Receiver's inbound SAD entry that decrypts the multicast application's data stream. In the inverse direction, the group policy may also set up an outbound IPsec SA (e.g., when supporting an ASM service model).
グループレシーバーエンドポイント（複数可）で、IPsecのサブシステムは、GKMプロトコル登録交換を開始GSPD方針メカニズムを使用するかもしれません。そのようなポリシーの機構（例えば、IGMP / MLD（マルチキャストリスナ発見）保護されたインターフェイス上でグループメッセージを加入を受信することによって）マルチキャストグループマッチングGSPDポリシーを結合保護されたネットワーク内のデバイスの検出であるかもしれません。その後のグループレシーバ登録交換は、マルチキャストアプリケーションのデータ・ストリームを復号化し、グループReceiverのインバウンドSADエントリを設定します。逆方向では、グループポリシーはまた、アウトバウンドのIPsec SAを設定してもよい（例えば、ASMサービスモデルをサポートする場合）。
Note: A security gateway triggering on the receipt of unauthenticated messages arriving on a protected interface may result in early Group Receiver registration if the message is not the result of a device on the protected network actually wishing to join a multicast group. The unauthenticated messages will only cause the Group Receiver to register once; subsequent messages will have no effect on the Group Receiver.
注：メッセージは、実際にマルチキャストグループへの参加を希望する保護されたネットワーク上のデバイスの結果ではない場合、保護インターフェイスに到着し、認証されていないメッセージの受信時にトリガするセキュリティゲートウェイは、初期のグループレシーバ登録をもたらすことができます。認証されていないメッセージは、唯一のグループレシーバは一度登録するようになります。後続のメッセージは、グループのレシーバーには影響しません。
The IPsec subsystem MAY provide GSPD policy mechanisms that automatically initiate a GKM protocol de-registration exchange. De-registration allows a GCKS to minimize exposure of the group's secret key by re-keying a group on a group membership change event. It also minimizes cost on a GCKS for those groups that maintain member state. One such policy mechanism could be the detection of IGMP/MLD leave group exchange. However, a security gateway Group Member would not initiate a GKM protocol de-registration exchange until it detects that there are no more receivers behind a protected interface.
IPsecのサブシステムは自動的にGKMプロトコル登録解除交換を開始GSPDポリシーメカニズムを提供してもよいです。デ登録はGCKSがグループメンバーシップの変更イベントにグループを再キーイングにより、グループの秘密鍵の暴露を最小限に抑えることができます。また、メンバーの状態を維持し、それらのグループのためにGCKSにコストを最小限に抑えます。そのような政策メカニズムは、IGMP / MLD休業グループ交換の検出である可能性があります。それが保護されたインターフェイスの背後にはより多くの受信機が存在しないことを検出するまでただし、セキュリティゲートウェイグループメンバーはGKMプロトコル登録解除交換を開始しません。
Additionally, the GKM subsystem MAY set up the GSPD/SAD state information independent of the multicast application's state. In this scenario, the Group Owner issues management directives that tell the GKM subsystem when it should start GKM registration and de-registration protocol exchanges. Typically, the registration policy strives to make sure that the group's IPsec subsystem state is "always ready" in anticipation of the multicast application starting its execution.
また、GKMサブシステムは、マルチキャストアプリケーションの状態とは無関係にGSPD / SADの状態情報を設定することもできます。このシナリオでは、GKMサブシステムを伝えるグループ所有者の問題管理ディレクティブは、それがGKM登録と登録解除のプロトコル交換を開始すべきとき。一般的に、登録ポリシーは、グループのIPsecのサブシステムの状態は、その実行を開始するマルチキャストアプリケーションを見越して「常に準備」であることを確認するために努力しています。
The SAD contains an item describing whether tunnel or transport mode is applied to traffic on this SA. The text in RFC 4301 Section 4.4.2.1 is amended to describe address preservation.
SADは、トンネル又はトランスポートモードがこのSA上のトラフィックに適用されているかどうかを記述する項目を含みます。 RFC 4301のセクション4.4.2.1内のテキストは、アドレス保存を記述するために修正されます。
o IPsec protocol mode: tunnel or transport. Indicates which
mode of AH or ESP is applied to traffic on this SA. When
tunnel mode is specified, the data item also indicates
whether or not address preservation is applied to the outer
IP header. Address preservation MUST NOT be specified when
the IP version of the encapsulating header and IP version of
the inner header do not match. The local address, remote
address, or both addresses MAY be marked as being preserved
during tunnel encapsulation.
The multicast IPsec extensions introduce a new data structure called the Group Peer Authorization Database (GPAD). The GPAD is analogous to the PAD defined in RFC 4301. It provides a link between the GSPD and a Group Key Management (GKM) Subsystem. The GPAD embodies the following critical functions:
マルチキャストのIPsecの拡張機能は、グループピア認証データベース（GPAD）と呼ばれる新しいデータ構造を紹介します。 GPADは、それはGSPDとグループ鍵管理（GKM）サブシステムとの間のリンクを提供してRFC 4301で定義されたパッドに似ています。 GPADは、以下の重要な機能を具現します：
o identifies a GCKS (or group of GCKS devices) that is
authorized to communicate with this IPsec entity
o specifies the protocol and method used to authenticate each GCKS
oは各GCKSを認証するために使用されるプロトコルと方法を指定します
o provides the authentication data for each GKCS
oはそれぞれGKCSの認証データを提供します
o constrains the traffic selectors that can be asserted by a GCKS with regard to SA creation
oはSAの作成に関してGCKSによってアサートすることができますトラフィックセレクタを制限します
o constrains the types and values of Group Identifiers for which a GCKS is authorized to provide group policy
oはGCKSがグループポリシーを提供する許可されたグループ識別子のタイプと値を制約します
The GPAD provides these functions for a Group Key Management subsystem. The GPAD is not consulted by IKE or other authentication protocols that do not act as GKM protocols.
GPADは、グループ鍵管理サブシステムのため、これらの機能を提供します。 GPADはIKEまたはGKMプロトコルとして機能していない他の認証プロトコルによって相談されていません。
To provide these functions, the GPAD contains an entry for each GCKS that the IPsec entity is configured to contact. An entry contains one or more GCKS Identifiers, the authentication protocol (e.g., Group Domain of Interpretation (GDOI) or Group Secure Association Key Management Protocol (GSAKMP)), the authentication method used (e.g., certificates or pre-shared secrets), and the authentication data (e.g., the pre-shared secret or trust anchor relative to which the peer's certificate will be validated). For certificate-based authentication, the entry also may provide information to assist in verifying the revocation status of the peer, e.g., a pointer to a Certificate Revocation List (CRL) repository or the name of an Online Certificate Status Protocol (OCSP) server associated with either the peer or the trust anchor associated with the peer. The entry also contains constraints a Group Member applies to the policy received from the GKCS.
これらの機能を提供するために、GPADは、IPsecエンティティが接触するように構成されている各GCKSためのエントリを含みます。エントリが1つまたは複数のGCKS識別子、認証プロトコルが含まれている（例えば、グループ解釈ドメイン（GDOI）またはグループセキュア協会鍵管理プロトコル（GSAKMP））、認証方法は、（例えば、証明書または事前共有秘密）を使用して、認証データ（例えば、ピアの証明書が検証されると事前共有秘密またはトラストアンカー相対）。証明書ベースの認証の場合、エントリは、ピアの失効状態を確認するのに役立つ情報を提供することができる、例えば、証明書失効リスト（CRL）のリポジトリへのポインタまたはオンライン証明書状態プロトコルの名前が（OCSP）は、サーバに関連しますピアまたはピアに関連付けられているトラストアンカーのいずれかで。エントリはまた、グループメンバーがGKCSから受信したポリシーに適用される制約が含まれています。
GCKS Identifiers are used to identify one or more devices that are authorized to act as a GCKS for this group. GCKS Identifiers are specified as PAD entry IDs in Section 4.4.3.1 of RFC 4301 and follow the matching rules described therein.
GCKS識別子は、このグループのGCKSとして作用することが許可されている1つ以上のデバイスを識別するために使用されます。 GCKS識別子は、RFC 4301のセクション4.4.3.1にPADエントリIDとして指定され、そこに記載されたマッチングルールに従っています。
Once a GPAD entry is located, it is necessary to verify the asserted identity, i.e., to authenticate the asserted GCKS Identifier. PAD authentication data types and semantics specified in Section 4.4.3.2 of RFC 4301 are used to authenticate a GCKS.
GPADエントリが配置されると、アサートされたGCKS識別子を認証するために、すなわち、アサートされたアイデンティティを検証する必要があります。 RFC 4301のセクション4.4.3.2で指定されたPADの認証データの種類と意味はGCKSを認証するために使用されています。
See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM protocol performs peer authentication using certificates and pre-shared secrets.
GKMプロトコルは、証明書と事前共有秘密を使用してピア認証を実行する方法の詳細についてGDOI [RFC3547]とGSAKMP [RFC4535]を参照。
A Group Identifier is used by a GKM protocol to identify a particular group to a GCKS. A GPAD entry includes a Group Identifier to indicate that the GKCS Identifiers in the GPAD entry are authorized to act as a GCKS for the group.
グループ識別子はGCKSに特定のグループを識別するためにGKMプロトコルによって使用されます。 GPADエントリはGPADエントリのGKCS識別子は、グループのためにGCKSとして作用することが許可されていることを示すために、グループ識別子を含みます。
The Group Identifier is an opaque byte string of IKE ID type Key ID that identifies a secure multicast group. The Group Identifier byte string MUST be at least four bytes long and less than 256 bytes long.
グループ識別子は、安全なマルチキャストグループを特定するIKE IDタイプキーIDの不透明なバイト列です。グループ識別子のバイト列は、少なくとも4バイト長未満256バイト長でなければなりません。
IKE ID types other than Key ID MAY be supported.
キーID以外のIKE IDタイプはサポートされるかもしれません。
Once a GCKS is authenticated, the GCKS delivers IPsec SA policy to the Group Member. Before the Group Member accepts the IPsec SA Policy, the source and destination traffic selectors of the SA are compared to a set of authorized data flows. Each data flow includes a set of authorized source traffic selectors and a set of authorized destination traffic selectors. Traffic selectors are represented as a set of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both v4 and v6 address ranges.)
GCKSが認証されると、GCKSは、グループメンバーへのIPsec SAのポリシーを提供します。グループメンバーは、IPsec SAのポリシーを受け入れる前に、SAの送信元と送信先トラフィックセレクタは、認可データフローのセットと比較されています。各データフローは、承認ソーストラフィックセレクタのセットと認可宛先トラフィックセレクタのセットを含みます。トラフィックセレクタは、IPv4および/またはIPv6アドレス範囲の組として表されます。 （ピアは、両方のアドレスタイプのために認可されてもよいので、V4およびV6アドレス範囲の両方のために規定がなければなりません。）
When a GKM protocol registration exchange is triggered, the Group Member and GCKS each assert their identity as a part of the exchange. Each GKM protocol registration exchange MUST use the asserted ID to locate an identity in the GPAD. The GPAD entry specifies the authentication method to be employed for the identified GCKS. The entry also specifies the authentication data that will be used to verify the asserted identity. This data is employed in conjunction with the specified method to authenticate the GCKS before accepting any group policy from the GCKS.
GKMプロトコル登録交換がトリガされると、グループメンバーとGCKSそれぞれが交流の一環として、自分のアイデンティティを主張します。各GKMプロトコル登録交換はGPADでIDを検索するためにアサートIDを使用しなければなりません。 GPADエントリーは識別GCKSのために使用される認証方式を指定します。エントリもアサート身元を確認するために使用される認証データを指定します。このデータは、GCKSから任意のグループポリシーを受け入れる前にGCKSを認証するために指定された方法と組み合わせて使用されます。
During the GKM protocol registration, a Group Member includes a Group Identifier. Before presenting that Group Identifier to the GCKS, a Group Member verifies that the GPAD entry for authenticated GCKS GPAD entry includes the Group Identifier. This ensures that the GCKS is authorized to provide policy for the Group.
GKMプロトコル登録時に、グループメンバーは、グループ識別子を含んでいます。 GCKSにそのグループ識別子を提示する前に、グループメンバーは、認証されたGCKS GPADエントリーのためのGPADエントリーがグループ識別子が含まれていることを確認します。これはGCKSがグループのポリシーを提供するために許可されていることを保証します。
When IPsec SA policy is received, each data flow is compared to the data flows in the GPAD entry. The Group Member accepts policy matching a data flow. Policy not matching a data flow is discarded, and the reason SHOULD be recorded in the audit log.
IPsec SAのポリシーが受信されると、各データフローはGPADエントリのデータフローと比較されます。グループメンバーは、データフローに一致するポリシーを受け入れます。データフローと一致しないポリシーが廃棄され、その理由は、監査ログに記録されるべきです。
A GKM protocol may distribute IPsec SA policy to IPsec devices that have previously registered with it. The method of distribution is part of the GKM protocol and is outside the scope of this memo. When the IPsec device receives this new policy, it compares the policy to the data flows in the GPAD entry as described above.
GKMプロトコルは以前にそれに登録されているIPSecデバイスへのIPsec SAのポリシーを配布することができます。配布方法は、GKMプロトコルの一部であり、このメモの範囲外です。 IPsecのデバイスがこの新しいポリシーを受信すると、上述したように、GPADエントリのデータフローにポリシーを比較します。
An IPsec implementation supporting these extensions will support a number of Security Associations: one or more IPsec SAs plus one or more GKM SAs used to download the parameters that are used to create IPsec SAs. These SAs are collectively referred to as a Group Security Association (GSA) [RFC3740].
これらの拡張機能をサポートするIPsec実装は、セキュリティアソシエーションの数をサポートします。一の以上のIPsec SAのプラス一つ以上のGKMのSAは、IPsec SAを作成するために使用されるパラメータをダウンロードするために使用しました。これらのSAは、まとめてグループセキュリティ協会（GSA）[RFC3740]と呼ばれています。
During a secure multicast group's lifetime, multiple IPsec Group Security Associations can exist concurrently. This occurs principally due to two reasons:
安全なマルチキャストグループの存続期間中に、複数のIPsecセキュリティアソシエーショングループが同時に存在することができます。これは、二つの理由に主に発生します。
- There are multiple Group Senders authorized in the group, each with its own IPsec SA, which maintains anti-replay state. A group that does not rely on IP security anti-replay services can share one IPsec SA for all of its Group Senders.
- アンチリプレイ状態を維持し、独自のIPsec SA、とのグループで承認複数のグループ送信者、それぞれがあります。 IPセキュリティアンチリプレイサービスに依存していないグループは、そのグループの送信者のすべてに1のIPsec SAを共有することができます。
- The life spans of a Group Sender's two (or more) IPsec SAs are allowed to overlap in time so that there is continuity in the multicast data stream across group re-key events. This capability is referred to as "re-key rollover continuity".
- グループ送信者の2つ（またはそれ以上）のIPsec SAの寿命は、グループ再キーイベント間でマルチキャストデータストリームにおける連続性があるように、時間的に重複することが許可されています。この機能は「再キーロールオーバーの継続性」と呼ばれています。
The re-key continuity rollover algorithm depends on an IPsec SA management interface between the GKM subsystem and the IPsec subsystem. The IPsec subsystem MUST provide management interface mechanisms for the GKM subsystem to add IPsec SAs and to delete IPsec SAs. For illustrative purposes, this text defines the re-key rollover continuity algorithm in terms of two timer parameters that govern IPsec SA life spans relative to the start of a group re-key event. However, it should be emphasized that the GKM subsystem interprets the group's security policy to direct the correct timing of IPsec SA activation and deactivation. A given group policy may choose timer values that differ from those recommended by this text. The two re-key rollover continuity timer parameters are:
再キーの連続ロールオーバーアルゴリズムは、GKMサブシステムとIPsecサブシステム間のIPsec SA管理インタフェースに依存します。 IPsecのサブシステムは、IPsec SAを追加するとIPsec SAを削除するには、GKMサブシステムの管理インターフェース機構を提供しなければなりません。例示的な目的のために、このテキストは、IPsec SAの寿命は、グループ再キーイベントの開始からの相対またがる支配2つのタイマーパラメータに関して再キーロールオーバー連続アルゴリズムを定義します。しかし、GKMサブシステムは、IPsec SAの活性化および非アクティブ化の正しいタイミングを指示するために、グループのセキュリティポリシーを解釈することが強調されるべきです。与えられたグループポリシーは、このテキストが推奨するものとは異なるタイマー値を選択することができます。 2つの再キーロールオーバーの継続タイマーパラメータは次のとおりです。
1. Activation Time Delay (ATD) - The ATD defines how long after the start of a re-key event to activate new IPsec SAs. The ATD parameter is expressed in units of seconds. Typically, the ATD parameter is set to the maximum time it takes to deliver a multicast message from the GCKS to all of the group's members. For a GCKS that relies on a Reliable Multicast Transport Protocol (RMTP), the ATD parameter could be set equal to the RTMP's maximum error recovery time. When an RMTP is not present, the ATD parameter might be set equal to the network's maximum multicast message delivery latency across all of the group's endpoints. The ATD is a GKM group policy parameter. This value SHOULD be configurable at the Group Owner management interface on a per group basis.
1.起動時間の遅延（ATD） - ATDはどのくらい新しいIPSec SAを活性化するための再キーイベントの開始後に定義します。 ATDパラメータは秒単位で表されます。一般的に、ATDパラメータは、それがグループのメンバー全員にGCKSからマルチキャストメッセージを配信するのにかかる最大時間に設定されています。信頼性の高いマルチキャストトランスポートプロトコル（RMTP）に依存しているGCKSに関しては、ATDパラメータは、RTMPの最大エラーリカバリ時間に等しくなるように設定することができます。 RMTPが存在しない場合、ATDパラメータは、グループのすべてのエンドポイントを介してネットワークの最大マルチキャストメッセージ配信待ち時間と等しくなるように設定されるかもしれません。 ATDは、GKMグループポリシーのパラメータです。この値は、グループごとにグループ所有者の管理インタフェースで設定可能であるべきです。
2. Deactivation Time Delay (DTD) - The DTD defines how long after the start of a re-key event to deactivate those IPsec SAs that are destroyed by the re-key event. The purpose of the DTD parameter is to minimize the residual exposure of a group's keying material after a re-key event has retired that keying material. The DTD is independent of, and should not to be confused with, the IPsec SA soft lifetime attribute. The DTD parameter is expressed in units of seconds. Typically, the DTD parameter would be set to the ADT plus the maximum time it takes to deliver a multicast message from the Group Sender to all of the group's members. For a Group Sender that relies on an RMTP, the DTD parameter could be set equal to ADT plus the RMTP's maximum error recovery time. When an RMTP is not present, the DTD parameter might be set equal to ADT plus the network's maximum multicast message delivery latency across all of the group's endpoints. A GKM subsystem MAY implement the DTD as a group security policy parameter. If a GKM subsystem does not implement the DTD parameter, then other group security policy mechanisms MUST determine when to deactivate an IPsec SA.
2.無効化時間遅延（DTD）は - DTDは、どのくらいの再キーイベントによって破壊されたもののIPsec SAを無効にするには再キーイベントの開始後に定義します。 DTDパラメータの目的は、再キーイベントが材料をキーイングすることを引退した後、グループの鍵素材の残留露出を最小限に抑えることです。 DTDは独立しており、そして、IPsec SAのソフト生涯属性と混同してはなりません。 DTDパラメータは秒単位で表されます。一般的に、DTDパラメータは、ADTプラス、それはグループのメンバー全員にグループの送信者からのマルチキャストメッセージを配信するのにかかる最大時間に設定されます。 RMTPに依存しているグループの送信者の場合は、DTDパラメータは、ADTプラスRMTPの最大エラーリカバリ時間に等しくなるように設定することができます。 RMTPが存在しない場合、DTDパラメータはADTプラスグループのエンドポイントのすべてにわたってネットワークの最大マルチキャストメッセージ配信待ち時間と等しくなるように設定されるかもしれません。 GKMサブシステムは、グループのセキュリティポリシーのパラメータとしてDTDを実施することができます。 GKMサブシステムはDTDパラメータを実装していない場合は、他のグループのセキュリティポリシーメカニズムは、IPsec SAを無効にするかを決定しなければなりません。
Each group re-key multicast message sent by a GCKS signals the start of a new Group Sender IPsec SA time epoch, with each such epoch having an associated set of two IPsec SAs. Note that this document refers to re-key mechanisms as being multicast because of the inherent scalability of IP multicast distribution. However, there is no particular reason that re-keying mechanisms must be multicast. For example, [ZLLY03] describes a method of re-key employing both unicast and multicast messages.
GCKSによって送信された各グループの再キーマルチキャストメッセージは、2つのIPSec SAの関連するセットを有するこのような各エポックで、新しいグループの送信者のIPsec SA時間エポックの開始を知らせます。この文書が原因でIPマルチキャスト配信の固有のスケーラビリティのマルチキャストであるように再キーメカニズムをいいます。しかし、再キーイングメカニズムは、マルチキャストでなければならない特別な理由はありません。例えば、[ZLLY03]ユニキャストとマルチキャストの両方のメッセージを用いる再キーの方法が記載されています。
The group membership interacts with these IPsec SAs as follows:
次のようにグループのメンバーシップは、これらのIPsecのSAと相互作用します。
- As a precursor to the Group Sender beginning its re-key rollover continuity processing, the GCKS periodically multicasts a Re-Key Event (RKE) message to the group. The RKE multicast MAY contain group policy directives, new IPsec SA policy, and group keying material. In the absence of an RMTP, the GCKS may re-transmit the RKE a policy-defined number of times to improve the availability of re-key information. The GKM subsystem starts the ATD and DTD timers after it receives the last RKE re-transmission.
- その再キーロールオーバーの連続処理を開始するグループの送信者への前駆体として、GCKSは、定期的にグループに再キーイベント（RKE）メッセージをマルチキャスト。 RKEマルチキャストは、グループポリシーディレクティブ、新しいIPsec SAのポリシー、およびグループ鍵材料を含むかもしれません。時間のRMTPの非存在下で、GCKSはRKEを再送信することができるポリシーに定義された数の再鍵情報の可用性を向上させることができます。それが最後のRKEの再送信を受信した後、GKMサブシステムは、ATDとDTDタイマーを開始します。
- The GKM subsystem interprets the RKE multicast to configure the group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that replaces an existing SA is called a "leading edge" IPsec SA. The leading edge IPsec SA has a new Security Parameter Index (SPI) and its associated keying material, which keys it. For a time period of ATD seconds after the GCKS multicasts the RKE, a Group Sender does not yet transmit data using the leading edge IPsec SA. Meanwhile, other Group Members prepare to use this IPsec SA by installing the leading edge IPsec SAs to their respective GSPD/SAD.
- GKMサブシステムは、新しいIPsecのSAを持つグループのGSPD / SADを設定するには、RKEマルチキャストを解釈します。既存のSAを置き換える各IPsecのSAは、「リーディングエッジ」のIPsec SAと呼ばれています。リーディングエッジのIPsec SAは、新しいセキュリティパラメータインデックス（SPI）とキーそれをそれに関連するキーイング材料を、持っています。 GCKSマルチキャストRKE後のATD秒の期間については、グループの送信者はまだ最先端のIPsec SAを使用してデータを送信しません。一方、他のグループメンバーは、それぞれGSPD / SADに先端のIPsec SAをインストールすることによって、このIPsecのSAを使用するための準備します。
- After waiting for the ATD period, such that all of the Group Members have received and processed the RKE message, the GKM subsystem directs the Group Sender to begin to transmit using the leading edge IPsec SA with its data encrypted by the new keying material. Only authorized Group Members can decrypt these IPsec SA multicast transmissions.
- ATD期間待った後、このようにグループメンバーのすべてが受信され、RKEメッセージを処理していることを、GKMサブシステムは、新しい鍵素材によって暗号化され、そのデータと最先端のIPsec SAを使用して送信を開始するために、グループの送信者に指示します。のみ許可グループメンバーは、これらのIPsec SAのマルチキャスト伝送を復号化することができます。
- The Group Sender's "trailing edge" SA is the oldest Security Association in use by the group for that sender. All authorized Group Members can receive and decrypt data for this SA, but the Group Sender does not transmit new data using the trailing edge IPsec SA after it has transitioned to the leading edge IPsec SA. The trailing edge IPsec SA is deleted by the group's GKM subsystems after the DTD time period has elapsed since the RKE transmission.
- グループの送信者の「トレーリングエッジ」SAは、その送信者のグループによって使用されている最古のセキュリティアソシエーションです。すべての許可グループメンバーは、受信および復号化データを、このSAのために、それはリーディングエッジのIPsec SAに遷移した後にグループの送信者は、後縁のIPsec SAを使用して、新しいデータを送信しないことができます。 DTDの時間がRKE送信経過後に後縁のIPsec SAは、グループのGKM・サブシステムによって削除されます。
This re-key rollover strategy allows the group to drain its in-transit datagrams from the network while transitioning to the leading edge IPsec SA. Staggering the roles of each respective IPsec SA as described above improves the group's synchronization even when there are high network propagation delays. Note that due to group membership joins and leaves, each Group Sender IPsec SA time epoch may have a different group membership set.
この再キーロールオーバ戦略は、前縁のIPsec SAに移行しながら、グループ、ネットワークから、そのイントランジットデータグラムを排出することを可能にします。上記のようにそれぞれのIPsec SAの役割をずらすことは、高いネットワーク伝播遅延があっても、グループの同期化を改善します。グループメンバーシップに参加と離脱、各グループの送信者のIPsec SA時間エポックは、異なるグループ・メンバーシップが設定されていることに注意してください。
It is a group policy decision whether the re-key event transition between epochs provides forward and backward secrecy. The group's re-key protocol keying material and algorithm (e.g., Logical Key Hierarchy; refer to [RFC2627] and Appendix A of [RFC4535]) enforces this policy. Implementations MAY offer a Group Owner management interface option to enable/disable re-key rollover continuity for a particular group. This specification requires that a GKM/IPsec implementation MUST support at least two concurrent IPsec SAs per Group Sender as well as this re-key rollover continuity algorithm.
エポック間の再キーイベント遷移が前方と後方の秘密保持を提供するかどうか、グループポリシーの決定です。材料及びアルゴリズム（例えば、論理鍵階層構造; [RFC2627]及び[RFC4535]の付録Aを参照）をキーインググループの再鍵プロトコルは、このポリシーを施行します。実装は、特定のグループのために/無効の再キーロールオーバーの継続を可能にするために、グループの所有者の管理インターフェイスオプションを提供することがあります。この仕様は、GKM / IPsecの実装は、少なくとも2つの同時のIPsecのSAあたりのグループの送信者だけでなく、この再キーロールオーバー連続アルゴリズムをサポートしなければならないことが必要です。
As defined in [RFC4301], data origin authentication is a security service that verifies the identity of the claimed source of data. A Message Authentication Code (MAC) is often used to achieve data origin authentication for connections shared between two parties. However, typical MAC authentication methods using a single shared secret are not sufficient to provide data origin authentication for groups with more than two parties. With a MAC algorithm, every Group Member can use the MAC key to create a valid MAC tag, whether or not they are the authentic originator of the group application's data.
[RFC4301]で定義されるように、データ発信元認証は、データの主張ソースのアイデンティティを検証するセキュリティサービスです。メッセージ認証コード（MAC）は、多くの場合、2者間で共有接続のためのデータ発信元認証を達成するために使用されます。しかし、単一の共有秘密を使用する典型的なMAC認証方法は、二つ以上のパーティーでのグループのためのデータ発信元認証を提供するのに十分ではありません。 MACアルゴリズムでは、すべてのグループメンバーは、彼らがグループのアプリケーションのデータの本物の創始ているかどうかにかかわらず、有効なMACタグを作成するために、MACキーを使用することができます。
When the property of data origin authentication is required for an IPsec SA shared by more than two parties, an authentication transform where the receiver is assured that the sender generated that message should be used. Two possible algorithms are Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] or RSA digital signature [RFC4359].
データ発信元認証のプロパティは、二つ以上の当事者、受信機は、送信者がメッセージを使用することを発生することを保証された認証変換によって共有のIPsec SAのために必要とされる場合。二つの可能なアルゴリズムは、効率的なストリーム損失トレラント認証（テスラ）[RFC4082]またはRSAデジタル署名[RFC4359]時限れます。
In some cases (e.g., digital signature authentication transforms), the processing cost of the algorithm is significantly greater than a Hashed Message Authentication Code (HMAC) authentication method. To protect against denial-of-service attacks from a device that is not authorized to join the group, the IPsec SA using this algorithm may be encapsulated with an IPsec SA using a MAC authentication algorithm. However, doing so requires the packet to be sent across the IPsec boundary a second time for additional outbound processing on the Group Sender (see Section 5.1 of [RFC4301]) and a second time for inbound processing on Group Receivers (see Section 5.2 of [RFC4301]). This use of AH or ESP encapsulated within AH or ESP accommodates the constraint that AH and ESP define an Integrity Check Value (ICV) for only a single authenticator transform.
いくつかの場合（例えば、デジタル署名認証は変換）において、アルゴリズムの処理コストは、ハッシュメッセージ認証コード（HMAC）認証方式よりも著しく大きいです。グループへの参加を許可されていないデバイスからのサービス拒否攻撃から保護するために、このアルゴリズムを用いたIPsec SAは、IPSec SAがMAC認証アルゴリズムを用いてカプセル化することができます。しかし、そうすることにIPsecを介して送信されるパケットを必要とするグループの送信者の追加アウトバウンド処理のための第二の時間（[RFC4301]のセクション5.1を参照）とグループレシーバの受信処理のための第二の時間を境界（[の5.2節を参照してくださいRFC4301]）。このAHの使用またはESP AHまたはESP内にカプセル化は、AHとESPトランスフォームのみ、単一のオーセンティケータの値（ICV）をチェック整合性を定義する制約に対応します。
Often, the GKM subsystem will be introduced to an existent IPsec subsystem as a companion key management protocol to IKEv2 [RFC4306]. A fundamental GKM protocol IP security subsystem requirement is that both the GKM protocol and IKEv2 can simultaneously share access to a common Group Security Policy Database and Security Association Database. The mechanisms that provide mutually exclusive access to the common GSPD/SAD data structures are a local matter. This includes the GSPD-O cache and the GSPD-I cache. However, implementers should note that IKEv2 SPI allocation is entirely independent from GKM SPI allocation because Group Security Associations are qualified by a destination multicast IP address and may optionally have a source IP address qualifier. See Section 2.1 of [RFC4303] for further explanation.
多くの場合、GKMサブシステムは、IKEv2のに相手の鍵管理プロトコル[RFC4306]として既存のIPsecサブシステムに導入されます。基本GKMプロトコルIPセキュリティサブシステム要件はGKMプロトコルとIKEv2の両方が同時に共通のグループセキュリティポリシーデータベースとセキュリティアソシエーションデータベースへのアクセスを共有できることです。共通GSPD / SADデータ構造への相互排他的なアクセスを提供するメカニズムは、ローカルの問題です。これはGSPD-OキャッシュとGSPD-Iキャッシュが含まれています。しかし、実装者は、グループセキュリティアソシエーションが宛先マルチキャストIPアドレスによって修飾されており、必要に応じて元のIPアドレス修飾子を持つ可能性があるため、IKEv2のSPIの割り当てはGKM SPIの割り当てから完全に独立であることに注意してください。さらに説明については、[RFC4303]のセクション2.1を参照してください。
The Peer Authorization Database does require explicit coordination between the GKM protocol and IKEv2. Section 4.1.3 describes these interactions.
ピア認証データベースはGKMプロトコルとIKEv2の間の明示的な調整を必要としません。 4.1.3項では、これらの相互作用を記述する。
Processing of traffic follows Section 5 of [RFC4301], with the additions described below when these IP multicast extensions are supported.
トラフィックの処理は、これらのIPマルチキャストの拡張機能がサポートされている場合は、以下に説明の追加で、[RFC4301]のセクション5に従います。
If an IPsec SA is marked as supporting tunnel mode with address preservation (as described in Section 3.1), either or both of the outer header source or destination addresses are marked as being preserved.
IPsec SAは（セクション3.1で説明したように）アドレス保存とトンネルモードをサポートするようにマークされている場合、外部ヘッダのソースまたは宛先アドレスのいずれかまたは両方が保持されているものとしてマークされています。
Header construction for tunnel mode is described in Section 5.1.2 of RFC 4301. The first bullet of that section is amended as follows:
トンネルモードのヘッダ構造は、以下のようにそのセクションの第一弾が修正されるRFC 4301のセクション5.1.2に記載されています。
o If address preservation is not marked in the SAD entry for
either the outer IP header Source Address or Destination
Address, the outer IP header Source Address and Destination
Address identify the "endpoints" of the tunnel (the
encapsulator and decapsulator). If address preservation is
marked for the IP header Source Address, it is copied from
the inner IP header Source Address. If address preservation
is marked for the IP header Destination Address, it is copied
from the inner IP header Destination Address. The inner IP
header Source Address and Destination Addresses identify the
original sender and recipient of the datagram (from the
perspective of this tunnel), respectively. Address
preservation MUST NOT be marked when the IP version of the
encapsulating header and IP version of the inner header do
not match.
Note (3), regarding construction of tunnel addresses in Section 5.1.2.1 of RFC 4301, is amended as follows. (Note: for brevity, Note (3) of RFC 4301 is not reproduced in its entirety.)
次のように注（3）、RFC 4301のセクション5.1.2.1にトンネルアドレスの構成について、修正されます。 （注：簡潔に、RFC 4301の注（3）のためにその全体が再生されません。）
(3) Unless marked for address preservation, Local and Remote
addresses depend on the SA, which is used to determine the
Remote address, which in turn determines which Local
address (net interface) is used to forward the packet. If
address preservation is marked for the Local address, it is
copied from the inner IP header. If address preservation
is marked for the Remote address, that address is copied
from the inner IP header.
IPsec-protected packets generated by an IPsec device supporting these multicast extensions may (depending on its GSPD policy) populate an outer tunnel header with a destination address such that it is not addressed to an IPsec device. This requires an IPsec device supporting these multicast extensions to accept and process IP traffic that is not addressed to the IPsec device itself. The following additions to IPsec inbound IP traffic processing are necessary.
それはIPsecの装置宛てないように宛先アドレスを有する外側トンネルヘッダを移入（そのGSPDポリシーに応じて）ことができるこれらのマルチキャスト拡張機能をサポートするのIPsecデバイスによって生成されたパケットをIPsecで保護されました。これは、IPsecデバイス自体に対処されていないIPトラフィックを受け入れて処理するには、これらのマルチキャストの拡張機能をサポートするIPsecのデバイスが必要です。 IPsecのインバウンドIPトラフィックの処理に以下の追加が必要です。
For compatibility with RFC 4301, the phrase "addressed to this device" is taken to mean packets with a unicast destination address belonging to the system itself, and also multicast packets that are received by the system itself. However, multicast packets not received by the IPsec device are not considered addressed to this device.
RFC 4301との互換性のために、語句「このデバイス宛」は、システム自体に属するユニキャスト宛先アドレスを持つパケットを意味するとともに、システム自体によって受信されるマルチキャストパケットれます。しかし、IPsecのデバイスによって受信されないマルチキャストパケットは、このデバイスに宛てとはみなされません。
The discussion of processing inbound IP Traffic described in Section 5.2 of RFC 4301 is amended as follows.
インバウンドIPトラフィックを処理する議論は、次のように改正されたRFC 4301のセクション5.2で説明しました。
The first dash in item 2 is amended as follows:
次のように項目2の最初のダッシュが改正されています。
- If the packet appears to be IPsec protected and it is
addressed to this device, or appears to be IPsec protected
and is addressed to a multicast group, an attempt is made to
map it to an active SA via the SAD. Note that the device may
have multiple IP addresses that may be used in the SAD
lookup, e.g., in the case of protocols such as SCTP.
A new item is added to the list between items 3a and 3b to describe processing of IPsec packets with destination address preservation applied:
新しいアイテムが適用宛先アドレス保存とIPsecパケットの処理を記述するためにアイテム3aと3bとのリストに追加されます。
3aa. If the packet is addressed to a multicast group and AH or
ESP is specified as the protocol, the packet is looked up
in the SAD. Use the SPI plus the destination or SPI plus
destination and source addresses, as specified in Section
4.1. If there is no match, the packet is directed to
SPD-I lookup. Note that if the IPsec device is a security
gateway, and the SPD-I policy is to BYPASS the packet, a
subsequent security gateway along the routed path of the
multicast packet may decrypt the packet.
Figure 3 in RFC 4301 is updated to show the new processing path defined in item 3aa.
RFC 4301の図3は、アイテム3AAで定義された新たな処理経路を示すように更新されます。
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|--------------------+
| +-----+ |
| | |
| Not IPsec | |
| | IPsec protected, not |
| V addressed to device, |
| +-------+ +---------+ and not in SAD |
| |DISCARD|<---|SPD-I (*)|<------------+ |
| +-------+ +---------+ | |
| | | |
| |-----+ | |
| | | | |
| | V | |
| | +------+ | |
| | | ICMP | | |
| | +------+ | |
| | | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | Boundary
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
nested SAs +----------+ | (***) | +----+
| +---------+
V
Protected Interface
Figure 1. Processing Model for Inbound Traffic
(amending Figure 3 of RFC 4301)
The discussion of processing inbound IP traffic in Section 5.2 of RFC 4301 is amended to insert a new item 6 as follows.
RFC 4301のセクション5.2で着信IPトラフィックを処理する議論は次のように新しいアイテム6を挿入するように修正されます。
6. If an IPsec SA is marked as supporting tunnel mode with
address preservation (as described in Section 3.1), the
marked address(es) (i.e., source and/or destination
address(es)) in the outer IP header MUST be verified to be
the same value(s) as in the inner IP header. If the
addresses are not consistent, the IPsec system MUST discard
the packet and treat the inconsistency as an auditable
event.
The IP security multicast extensions defined by this specification build on the unicast-oriented IP security architecture [RFC4301]. Consequently, this specification inherits many of RFC 4301's security considerations, and the reader is advised to review it as companion guidance.
ユニキャスト向けIPセキュリティアーキテクチャ[RFC4301]でこの仕様のビルドによって定義されたIPセキュリティマルチキャスト拡張。したがって、この仕様はRFC 4301のセキュリティ上の考慮事項の多くを継承し、読者はコンパニオンガイダンスとして、それを確認することをお勧めします。
The IP security multicast extension service provides the following network layer mechanisms for secure group communications:
IPセキュリティマルチキャスト拡張サービスは、安全なグループ通信のための次のネットワーク層メカニズムを提供します。
- Confidentiality using a group shared encryption key.
- グループ共有の暗号化キーを使用して機密性。
- Group source authentication and integrity protection using a group shared authentication key.
- グループ共有認証キーを使用して、グループの元認証と完全性保護。
- Group Sender data origin authentication using a digital signature, TESLA, or other mechanism.
- デジタル署名、TESLA、または他の機構を使用して、グループ送信者データ発信元認証。
- Anti-replay protection for a limited number of Group Senders using the ESP (or AH) sequence number facility.
- ESP（またはAH）のシーケンス番号機能を使用してグループの送信者の限られた数のためのアンチリプレイ保護。
- Filtering of multicast transmissions identified with a source address of systems that are not authorized by group policy to be Group Senders. This feature leverages the IPsec stateless firewall service (i.e., SPD-I and/or SDP-O entries with a packet disposition specified as DISCARD).
- グループの送信者であることをグループポリシーで許可されていないシステムの送信元アドレスで識別されるマルチキャスト伝送のフィルタリング。この機能は、IPsecステートレスファイアウォールサービス（すなわち、SPD-Iおよび/またはDISCARDとして指定されたパケットの配置とSDP-Oエントリ）を活用します。
In support of the above services, this specification enhances the definition of the SPD, PAD, and SAD databases to facilitate the automated group key management of large-scale cryptographic groups.
上記サービスのサポートでは、この仕様はSPD、パッド、および大規模暗号化グループの自動化されたグループ鍵管理を容易にするために、SADのデータベースの定義を強化します。
As noted in Section 2.2. of RFC 4301, it is out of the scope of this architecture to defend the group's keys or its application data against attacks targeting vulnerabilities of the operating environment in which the IPsec implementation executes. However, it should be noted that the risk of attacks originating by an adversary in the network is magnified to the extent that the group keys are shared across a large number of systems.
2.2節で述べたように。 RFC 4301のために、それは、IPsec実装が実行される動作環境の脆弱性を狙った攻撃に対して、グループのキーまたはそのアプリケーションデータを守るために、このアーキテクチャの範囲外です。しかし、ネットワーク内の敵によって発信攻撃のリスクは、グループキーが多数のシステム間で共有されている程度に拡大されることに留意すべきです。
The security issues that are left unsolved by the IPsec multicast extension service divide into two broad categories: outsider attacks and insider attacks.
部外者攻撃やインサイダー攻撃：2つのカテゴリにIPsecのマルチキャスト拡張サービス除算によって未解決のままにされているセキュリティ問題。
The IPsec multicast extension service does not defend against an adversary outside of the group who has:
IPsecのマルチキャスト拡張サービスは、あるグループの外の敵を防御しません。
- the capability to launch a multicast, flooding denial-of-service attack against the group, originating from a system whose IPsec subsystem does not filter the unauthorized multicast transmissions.
- マルチキャストグループに対する洪水DoS攻撃、IPsecのサブシステムの不正なマルチキャスト送信をフィルタリングしていないシステムからの発信を起動する機能。
- compromised a multicast router, allowing the adversary to corrupt or delete all multicast packets destined for the group endpoints downstream from that router.
- 破損またはそのルータから下流のグループエンドポイント宛てのすべてのマルチキャストパケットを削除するために敵を可能にする、マルチキャストルータを損なわ。
- captured a copy of an earlier multicast packet transmission and then replayed it to a group that does not have the anti-replay service enabled. Note that for a large-scale, any-source multicast group, it is impractical for the Group Receivers to maintain an anti-replay state for every potential Group Sender. Group policies that require anti-replay protection for a large-scale, any-source multicast group should consider an application layer multicast protocol that can detect and reject replays.
- 以前のマルチキャストパケットの送信のコピーをキャプチャして、アンチリプレイサービスが有効になっていないグループにそれを再生。グループ受信機は、すべての潜在的なグループの送信者のためのアンチリプレイ状態を維持するために大規模な、任意のソースのマルチキャスト・グループのために、それは非現実的であることに留意されたいです。大規模のためのアンチリプレイ保護を必要とするグループポリシーは、任意のソースのマルチキャストグループを検出し、リプレイを拒否することができ、アプリケーション層マルチキャストプロトコルを検討すべきです。
For large-scale groups, the IP security multicast extensions are dependent on an automated Group Key Management protocol to correctly authenticate and authorize trustworthy members in compliance to the group's policies. Inherent in the concept of a cryptographic group is a set of one or more shared secrets entrusted to all of the Group Members. Consequently, the service's security guarantees are no stronger than the weakest member admitted to the group by the GKM system. The GKM system is responsible for responding to compromised Group Member detection by executing a re-key procedure. The GKM re-keying protocol will expel the compromised Group Members and distribute new group keying material to the trusted members. Alternatively, the group policy may require the GKM system to terminate the group.
大規模なグループの場合、IPセキュリティマルチキャスト拡張が正しく認証し、グループの方針に準拠した信頼できるメンバーを承認する自動化されたグループ鍵管理プロトコルに依存しています。暗号のグループの概念に固有のグループメンバーのすべてに委託一つ以上の共有秘密のセットです。その結果、サービスのセキュリティ保証はGKMシステムによってグループに入院最も弱いメンバーよりも強いん。 GKMシステムが再キーの手順を実行することで妥協グループメンバーの検出に応答する責任があります。 GKM再キーイングプロトコルは妥協グループメンバーを追放し、信頼できるメンバーに新しいグループ鍵材料を配布します。代替的に、グループポリシーは、グループを終了するGKMシステムを必要とし得ます。
In the event that an adversary has been admitted into the group by the GKM system, the following attacks are possible and can not be solved by the IPsec multicast extension service:
敵がGKMシステムによってグループ内に導入された場合において、次の攻撃が可能であり、IPsecのマルチキャスト拡張サービスでは解決できません。
- The adversary can disclose the secret group key or group data to an unauthorized party outside of the group. After a group key or data compromise, cryptographic methods such as traitor tracing or watermarking can assist in the forensics process. However, these methods are outside the scope of this specification.
- 敵はグループの外の不正者に秘密グループキーまたはグループデータを開示することができます。グループキー又はデータ妥協した後、そのような反逆者追跡又は透かしなどの暗号方法は、フォレンジックプロセスを支援することができます。しかしながら、これらの方法は、本明細書の範囲外です。
- The insider adversary can forge packet transmissions that appear to be from a peer Group Member. To defend against this attack, for those Group Sender transmissions that merit the overhead, the group policy can require the Group Sender to multicast packets using the data origin authentication service.
- インサイダー敵は、ピアグループメンバーからのように見えるパケット伝送を偽造することができます。この攻撃を防御するには、オーバーヘッドに値するこれらのグループの送信者の送信のために、グループポリシーは、データ発信元認証サービスを使用して、マルチキャストパケットのグループの送信者を必要とすることができます。
- If the group's data origin authentication service uses digital signatures, then the insider adversary can launch a computational resource denial-of-service attack by multicasting bogus signed packets.
- グループのデータ発信元認証サービスは、デジタル署名を使用する場合、インサイダー敵は偽の署名パケットをマルチキャストにより、計算資源、サービス拒否攻撃を仕掛けることができます。
The IP security multicast extensions service can not defend against a poorly considered group security policy that allows a weaker cryptographic algorithm simply because all of the group's endpoints are known to support it. Unfortunately, large-scale groups can be difficult to upgrade to the current best-in-class cryptographic algorithms. One possible approach to solving many of these problems is the deployment of composite groups that can straddle heterogeneous groups [COMPGRP]. A standard solution for heterogeneous groups is an activity for future standardization. In the interim, synchronization of a group's cryptographic capabilities could be achieved using a secure and scalable software distribution management tool.
IPセキュリティマルチキャスト拡張サービスは、グループのすべてのエンドポイントは、それをサポートすることが知られているという理由だけで、弱い暗号化アルゴリズムを可能に不十分と考え、グループのセキュリティポリシーを防御することはできません。残念ながら、大規模なグループは、現在、クラス最高の暗号化アルゴリズムにアップグレードすることは困難です。これらの問題の多くを解決するための1つの可能なアプローチは、異種のグループ[COMPGRP]をまたぐことができ、複合グループの展開です。異種のグループのための標準的なソリューションは、将来の標準化のための活動です。その間、グループの暗号化機能の同期は、セキュアでスケーラブルなソフトウェア配布管理ツールを使用して達成することができました。
Large-scale groups may span multiple legal jurisdictions (e.g., countries) that enforce limits on cryptographic algorithms or key strengths. As currently defined, the IPsec multicast extension service requires a single group policy per group. As noted above, this problem remains an area for future standardization.
大規模なグループは、暗号アルゴリズムや鍵の強度に制限を強制する複数の法的管轄区域（例えば、国）に及ぶことができます。現在定義されているように、IPsecのマルチキャスト拡張サービスは、グループごとに単一のグループポリシーが必要です。上述したように、この問題は、将来の標準化のための領域のまま。
A Source Specific Multicast (SSM) Group Sender's source IP address can dynamically change during a secure multicast group's lifetime. Examples of the events that can cause the Group Sender's source address to change include but are not limited to NAT, a mobility-induced change in the care-of-address, and a multi-homed host using a new IP interface. The change in the Group Sender's source IP address will cause GSPD entries related to that multicast group to become out of date with respect to the group's multicast routing state. In the worst case, there is a risk that the Group Sender's data originating from a new source address will be BYPASS processed by a security gateway. If this scenario was not anticipated, then it could leak the group's data. Consequently, it is recommended that SSM secure multicast groups have a default DISCARD policy for all unauthorized Group Sender source IP addresses for the SSM group's destination IP address.
ソース固有マルチキャスト（SSM）グループの送信者の送信元IPアドレスが動的にセキュアなマルチキャストグループの存続期間中に変更することができます。変更するには、グループの送信者の送信元アドレスを引き起こす可能性のイベントの例としては、NAT、気付アドレスの移動度誘発性の変化、および新しいIPインタフェースを使用して、マルチホームホストに限定されるものではありません。グループの送信者の送信元IPアドレスの変更は、そのマルチキャストグループに関連するGSPDエントリーはグループのマルチキャストルーティング状態に関して時代遅れになってしまいます。最悪の場合には、新しい送信元アドレスから発信グループの送信者のデータは、セキュリティゲートウェイによって処理BYPASSとなるおそれがあります。このシナリオが予想されていなかった場合、それは、グループのデータを漏らすことができます。したがって、SSMは、マルチキャストグループがSSMグループの宛先IPアドレスに対するすべての権限のないグループの送信者の送信元IPアドレスのデフォルトの廃棄ポリシーを持って確保することをお勧めします。
The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, and Tero Kivinen for their helpful comments.
作者は彼らの役に立つコメントをスティーブン・ケント、ラスHousley、パシEronen、およびTERO Kivinenに感謝したいです。
The "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] was consulted to develop the Security Considerations section of this memo.
「セキュリティの考慮事項の書き方RFCテキストのためのガイドライン」[RFC3552]はこのメモのSecurity Considerations部を開発するために調べました。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security Composite Cryptographic Groups", Work in Progress, February 2007.
[COMPGRP]グロスG.およびH.クルックシャンク、「マルチキャストIPセキュリティコンポジット暗号化グループ」、進歩、2007年2月での作業。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、RFC 2526、1999年3月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627]ウォルナー、D.、ハーダー、E.、およびR.アゲ、 "マルチキャストのためのキー管理：問題とアーキテクチャ"、RFC 2627、1999年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171] Albanna、Z.、Almeroth、K.、マイヤー、D.、およびM.シッパー、 "IPv4マルチキャストアドレス割り当てのためのIANAガイドライン"、BCP 51、RFC 3171、2001年8月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[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月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、S.、エド。、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]ビダ、R.、エド。、およびL.コスタ、エド。、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "否定応答（NACK）配向高信頼マルチキャスト（NORM）プロトコル"、RFC 3940、2004年11月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、 "マルチキャストセキュリティ（MSEC）グループ鍵管理アーキテクチャ"、RFC 4046、2005年4月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換"、RFC 4082、 2005年6月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[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グループは、協会の鍵管理プロトコルをセキュア"。
[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月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and Reliable Group Rekeying", IEEE/ACM Transactions on Networking (TON), Volume 11, Issue 6, December 2003.
[ZLLY03]チャン、X.ら、 "スケーラブルで信頼性の高いグループ鍵の再生成のためのプロトコル設計"、ネットワーク（TON）、11巻、6号、2003年12月にIEEE / ACM取引。
Appendix A. Multicast Application Service Models
付録A.マルチキャストアプリケーション・サービス・モデル
The vast majority of secure multicast applications can be catalogued by their service model and accompanying intra-group communication patterns. Both the Group Key Management (GKM) subsystem and the IPsec subsystem MUST be able to configure the GSPD/SAD security policies to match these dominant usage scenarios. The GSPD/SAD policies MUST include the ability to configure both Any-Source Multicast groups and Source-Specific Multicast groups for each of these service models. The GKM subsystem management interface MAY include mechanisms to configure the security policies for service models not identified by this standard.
安全なマルチキャストアプリケーションの大半は、彼らのサービスモデルおよび付随するグループ内の通信パターンによってカタログ化することができます。グループ鍵管理（GKM）サブシステムとIPsecサブシステムの両方がこれらの支配的な使用シナリオに一致するようにGSPD / SADのセキュリティポリシーを設定できなければなりません。 GSPD / SADポリシーは、これらのサービスモデルごとにどれ-ソースのマルチキャストグループ及びソース固有のマルチキャストグループの両方を設定する機能を含まなければなりません。 GKMサブシステムの管理インターフェイスは、この規格によって識別されていないサービスモデルのためのセキュリティポリシーを設定するためのメカニズムを含むかもしれません。
A.1. Unidirectional Multicast Applications
A.1。単方向マルチキャストアプリケーション
Multimedia content-delivery multicast applications that do not have congestion notification or re-transmission error-recovery mechanisms are inherently unidirectional. RFC 4301 only defines bi-directional unicast traffic selectors (as per RFC 4301, Sections 4.4.1 and 5.1 with respect to traffic selector directionality). The GKM subsystem requires that the IPsec subsystem MUST support unidirectional SPD entries, which cause a Group Security Association (GSA) to be installed in only one direction. Multicast applications that have only one Group Member authorized to transmit can use this type of Group Security Association to enforce that group policy. In the inverse direction, the GSA does not have an SAD entry, and the GSPD configuration is optionally set up to discard unauthorized attempts to transmit unicast or multicast packets to the group.
輻輳通知または再送信エラー回復メカニズムを持っていないマルチメディアコンテンツ配信マルチキャストアプリケーションは、本質的に単方向です。 RFC 4301は、（トラフィックセレクタ方向に対してRFC 4301の通り、セクション4.4.1および5.1）双方向のユニキャストトラフィックセレクタを画定します。 GKMサブシステムは、IPsecサブシステムが一方向にのみインストールされるように、グループセキュリティ協会（GSA）を引き起こす一方向のSPDエントリを、サポートしなければならないことが必要です。唯一のグループメンバーを送信することを許可しているマルチキャストアプリケーションは、そのグループポリシーを適用するために、グループセキュリティアソシエーションのこのタイプを使用することができます。逆方向では、GSAは、SADエントリを持たない、とGSPD構成は、必要に応じてグループにユニキャストまたはマルチキャストパケットを送信する不正な試みを破棄するように設定されています。
The GKM subsystem's management interface MUST have the ability to set up a GKM subsystem group having a unidirectional GSA security policy.
GKMサブシステムの管理インターフェイスは、単方向GSAのセキュリティポリシーを持つGKMサブシステムグループを設定する機能を持たなければなりません。
A.2. Bi-Directional Reliable Multicast Applications
A.2。双方向の信頼できるマルチキャストアプリケーション
Some secure multicast applications are characterized as one Group Sender to many receivers but have inverse data flows required by a reliable multicast transport protocol (e.g., NORM). In such applications, the data flow from the sender is multicast and the inverse flow from the Group's Receivers is unicast to the sender. Typically, the inverse data flows carry error repair requests and congestion control status.
いくつかのセキュアなマルチキャストアプリケーションは、多くの受信機に1つのグループ送信者として特徴付けられるが、逆のデータは、信頼性の高いマルチキャストトランスポートプロトコル（例えば、NORM）によって必要なフローました。このようなアプリケーションでは、送信者からのデータの流れは、マルチキャストであると当社グループのレシーバからの逆の流れは、送信者へのユニキャストです。一般的に、逆のデータ・フローは、エラーの修理依頼や輻輳制御状態を運びます。
For such applications, it is advantageous to use the same IPsec SA for protection of both unicast and multicast data flows. This does introduce one risk: the IKEv2 application may choose the same SPI for receiving unicast traffic as the GCKS chooses for a group IPsec SA covering unicast traffic. If both SAs are installed in the SAD, the SA lookup may return the wrong SPI as the result of an SA lookup. To avoid this problem, IPsec SAs installed by the GKM SHOULD use the 2- tuple {destination IP address, SPI} to identify each IPsec SA. In addition, the GKM SHOULD use a unicast destination IP address that does not match any destination IP address in use by an IKEv2 unicast IPsec SA. For example, suppose a Group Member is using both IKEv2 and a GKM protocol, and the group security policy requires protecting the NORM inverse data flows as described above. In this case, group policy SHOULD allocate and use a unique unicast destination IP address representing the NORM Group Sender. This address would be configured in parallel to the Group Sender's existing IP addresses. The GKM subsystems at both the NORM Group Sender and Group Receiver endpoints would install the IPsec SA, protecting the NORM unicast messages such that the SA lookup uses the unicast destination address as well as the SPI.
そのような用途では、ユニキャストとマルチキャストの両方のデータフローの保護のために同じのIPsec SAを使用することが有利です。これは、1つのリスクを紹介します：IKEv2のアプリケーションは、GCKSは、ユニキャストトラフィックをカバーするグループのIPsec SAのために選択したとして、ユニキャストトラフィックを受信するための同じSPIを選択することができます。両方のSAがSADにインストールされている場合は、SAルックアップはSA検索の結果として間違ったSPIを返すことがあります。この問題を回避するために、GKMによってインストールされたIPsec SAがそれぞれのIPsec SAを識別するために、2-タプル{宛先IPアドレス、SPI}を使用すべきです。また、GKMは、IKEv2のユニキャストのIPsec SAが使用している任意の宛先IPアドレスと一致しないユニキャスト宛先IPアドレスを使用すべきです。例えば、グループメンバーは、IKEv2のとGKMプロトコル、およびグループセキュリティポリシーの両方を使用していると仮定すると、上記のように流れるNORM逆のデータを保護する必要があります。この場合、グループポリシーは、NORMグループの送信者を表す一意のユニキャスト宛先IPアドレスを割り当てて使用すべきです。このアドレスは、グループの送信者の既存のIPアドレスに並列に構成されるだろう。 NORMグループの送信者とグループのレシーバーエンドポイントの両方でGKMサブシステムは、SA検索がSPIと同様のユニキャスト宛先アドレスを使用するように、NORMユニキャストメッセージを保護し、IPsecのSAをインストールします。
The GSA SHOULD use IPsec anti-replay protection service for the sender's multicast data flow to the group's Receivers. Because of the scalability problem described in the next section, it is not practical to use the IPsec anti-replay service for the unicast inverse flows. Consequently, in the inverse direction, the IPsec anti-replay protection MUST be disabled. However, the unicast inverse flows can use the group's IPsec group authentication mechanism. The Group Receiver's GSPD entry for this GSA SHOULD be configured to only allow a unicast transmission to the sender node rather than a multicast transmission to the whole group.
GSAは、グループのレシーバに送信者のマルチキャストデータフローのためのIPSecアンチリプレイ保護サービスを使用すべきです。次のセクションで説明した拡張性の問題のため、ユニキャスト逆フローのためのIPSecアンチリプレイサービスを使用することは実用的ではありません。その結果、逆方向に、IPsecのリプレイ保護を無効にする必要があります。しかし、ユニキャスト逆フローは、グループのIPSecグループの認証メカニズムを使用することができます。このGSAのグループReceiverのGSPDエントリーは送信ノードではなく、グループ全体へのマルチキャスト伝送にユニキャスト送信を許可するように設定する必要があります。
If an ESP digital signature authentication is available (e.g., RFC 4359), source authentication MAY be used to authenticate a receiver node's transmission to the sender. The GKM protocol MUST define a key management mechanism for the Group Sender to validate the asserted signature public key of any receiver node without requiring that the sender maintain state about every Group Receiver.
ESPデジタル署名認証が利用可能である場合（例えば、RFC 4359）、ソースの認証は、送信者に受信ノードの送信を認証するために使用されるかもしれません。 GKMプロトコルは、送信者がグループ毎レシーバに関する状態を維持することを必要とすることなく、任意の受信ノードのアサート署名公開鍵を検証するグループ送信者の鍵管理メカニズムを定義しなければなりません。
This multicast application service model is RECOMMENDED because it includes congestion control feedback capabilities. Refer to [RFC2914] for additional background information.
それは輻輳制御フィードバック機能が含まれているため、このマルチキャストアプリケーションサービスモデルをお勧めします。追加の背景情報については、[RFC2914]を参照してください。
The GKM subsystem's Group Owner management interface MUST have the ability to set up a symmetric GSPD entry and one Group Sender. The management interface SHOULD be able to configure a group to have at least 16 concurrent authorized senders, each with their own GSA anti-replay state.
GKMサブシステムのグループ所有者の管理インターフェイスは、対称GSPDエントリーと1グループの送信者を設定する機能を持たなければなりません。管理インターフェイスは、少なくとも16個の同時認可送信者、自分のGSAアンチリプレイ状態にそれぞれを持っているグループを構成します。
A.3. Any-To-Many Multicast Applications
A.3。任意の対多マルチキャストアプリケーション
Another family of secure multicast applications exhibits an "any-to-many" communications pattern. A representative example of such an application is a videoconference combined with an electronic whiteboard.
安全なマルチキャストアプリケーションのもう一つの家族「は、任意の対多」の通信パターンを示します。このような用途の代表例は、電子ホワイトボードと組み合わせてビデオ会議です。
For such applications, all (or a large subset) of the Group Members are authorized multicast senders. In such service models, creating a distinct IPsec SA with anti-replay state for every potential sender does not scale to large groups. The group SHOULD share one IPsec SA for all of its senders. The IPsec SA SHOULD NOT use the IPsec anti-replay protection service for the sender's multicast data flow to the Group Receivers.
このような用途のために、グループメンバーのすべて（または大規模なサブセット）は、マルチキャスト送信者を許可されています。このようなサービスモデルでは、すべての潜在的な送信者のためのアンチリプレイ状態での個別のIPsec SAを作成すると、大きなグループに拡張できません。グループは、その送信者のすべてのための1のIPsec SAを共有する必要があります。 IPsecのSAは、グループのレシーバに送信者のマルチキャストデータフローのためのIPSecアンチリプレイ保護サービスを使用しないでください。
The GKM subsystem's management interface MUST have the ability to set up a group having an Any-To-Many Multicast GSA security policy.
GKMサブシステムの管理インターフェイスは、任意の対多マルチキャストGSAのセキュリティポリシーを持つグループを設定する機能を持たなければなりません。
Appendix B. ASN.1 for a GSPD Entry
GSPDエントリー付録B. ASN.1
This appendix describes an additional way to describe GSPD entries, as defined in Section 4.1.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The GSPD description in Section 4.1.1 is normative. As shown in Section 4.1.1, the GSPD updates the SPD and thus this appendix updates the SPD object identifier.
この付録では、4.1.1項で定義されるように、GSPDエントリーを記述するために、追加の方法を説明します。これは、正常にコンパイルされたASN.1構文を使用しています。この構文は、単なる例示であり、コンプライアンスを達成するために、実装に採用する必要はありません。 4.1.1項でGSPDの記述は規範的です。セクション4.1.1に示すように、GSPDはSPDを更新し、したがって、この付録では、SPDオブジェクト識別子を更新します。
B.1. Fields Specific to a GSPD Entry
B.1。 GSPDエントリーに固有のフィールド
The following fields summarize the fields of the GSPD that are not present in the SPD.
次のフィールドは、SPDには存在しないGSPDのフィールドをまとめます。
- direction (in IPsecEntry) - DirectionFlags - noswap (in SelectorList) - ap-l, ap-r (in TunnelOptions)
- 方向（IPsecEntryにおける） - DirectionFlags - （SelectorListで）NOSWAP - AP-L、AP-R（TunnelOptionsで）
B.2. SPDModule
B.2。 SPDModule
SPDModule
SPDModule
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) }
{ISO（1）ORG（3）DOD（6）インターネット（1）セキュリティ（5）機構（5）のIPSec（8）ASN1-モジュール（3）SPD-モジュール（1）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
IMPORTS RDNSequence FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ;
PKIX1Explicit88からの輸入RDNSequence {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（18）} ;
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
direction DirectionFlags, -- SA directionality
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
FQDN ::= IA5String
RFC822Name ::= IA5String
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
DirectionFlags ::= BIT STRING {
-- if set, install SA in the specified
-- direction. symmetric policy is
-- represented by setting both bits
inbound (0),
outbound (1) }
SelectorLists ::= SET OF SelectorList
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice,
noswap BOOLEAN } -- Do not swap local and remote
-- addresses and ports on incoming
-- SPD-S and SPD-I checks
- SPD-SとSPD-Iをチェック
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
KeyIDs ::= SEQUENCE OF OCTET STRING
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm -- }
-- defined outside
-- of this document for AES modes.
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
ap-l BOOLEAN, -- TRUE Copy inner IP header
-- source address to outer
-- IP header source address
ap-r BOOLEAN, -- TRUE Copy inner IP header
-- destination address to outer
-- IP header destination address
df DF,
addresses TunnelAddresses }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
END
終わり
Authors' Addresses
著者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706 USA
ブライアン・ワイスシスコシステムズ170 W.タスマン・ドライブ、サンノゼ、CA 95134-1706 USA
Phone: +1-408-526-4796 EMail: bew@cisco.com
電話：+ 1-408-526-4796 Eメール：bew@cisco.com
George Gross Secure Multicast Networks LLC 977 Bates Road Shoreham, VT 05770 USA
ジョージ・グロスセキュアマルチキャストネットワークスLLC 977ベイツ道路ショーハム、VT 05770 USA
Phone: +1-802-897-5339 EMail: gmgross@securemulticast.net
電話：+ 1-802-897-5339 Eメール：gmgross@securemulticast.net
Dragan Ignjatic Polycom Suite 200 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
ドラガンIgnjaticポリコムスイート200 3605ギルモア・ウェイバーナビー、BC V5G 4×5カナダ
Phone: +1-604-453-9424 EMail: dignjatic@polycom.com
電話：+ 1-604-453-9424 Eメール：dignjatic@polycom.com