[要約] RFC 5374は、インターネットプロトコルのセキュリティアーキテクチャに対するマルチキャスト拡張の要約です。このRFCの目的は、マルチキャスト通信におけるセキュリティの強化と、IPsecプロトコルの拡張を提供することです。
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.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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セキュリティ協会（SAS）のサービスとセマンティクスを説明しています。通常、これには、IP宛先フィールドにユニキャストアドレスを含むトラフィックセレクターを備えたSASが含まれ、IP宛先フィールドにユニキャストアドレスを備えたIPSECパケットになります。RFC 4301で定義されているセキュリティサービスは、IPマルチキャストパケットのトンネルにも使用できます。トンネルは、2つのIPSECデバイス間のペアワイズ関連です。RFC 4301は、IP宛先アドレスフィールドにマルチキャストアドレスを持つIPパケットの手動でキー付き輸送モードIPSEC SAサポートを定義しました。ただし、RFC 4301は、IPSECサブシステムとグループキー管理プロトコルまたは外部IPヘッダーにIPマルチキャストアドレスを持つトンネルモードIPSEC SAのセマンティクスとの相互作用を定義しませんでした。
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.
このドキュメントでは、IPSECデバイスのグループがSASを共有するために、IPSECセキュリティアーキテクチャをさらに定義するRFC 4301へのオプションの拡張機能について説明します。特に、IP宛先フィールドにマルチキャストアドレスを含むトラフィックセレクターを使用してSASをサポートし、IP宛先フィールドにIPマルチキャストアドレスを備えたIPSECパケットになります。また、IPSEC Group Key Management（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.
このドキュメントで説明されているIPSEC拡張機能は、宛先アドレスとしてIPv4またはIPv6マルチキャストグループアドレスを備えた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 AnycastパケットをもたらすIPv6 Anycastアドレス[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デバイスが均一であることが必要です。彼らは、共通の暗号化変換およびプロトコル処理機能のセットを共有する必要があります。2つ以上のサブグループの結合から形成された不均一なIPSEC暗号グループである「IPSEC Composite Group」[Compgrp]のセマンティクスは、将来の標準化の領域です。
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）マルチキャストサービスモデル。このモデルでは、1つ以上の送信者が単一のIPマルチキャストアドレスにパケットをソースします。受信機がグループに参加すると、そのIPマルチキャストアドレスに送信されるすべてのパケットを受け取ります。これは（*、g）グループとして知られています。
Group A set of devices that work together to protect group communications.
グループコミュニケーションを保護するために協力するデバイスのセット。
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.
Group Key Management（GKM）プロトコルGCKSがIPSECセキュリティ協会のポリシーとキーイング資料を配布するために使用する主要な管理プロトコル。IPSECデバイスのグループが同じSASを必要とする場合、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 SASを提供します。追加情報については、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.
Group Security Association（GSA）IPSECセキュリティ協会（SAS）およびGKMサブシステムSASのコレクションは、グループメンバーがキーアップデートを受信するために必要です。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.
グループセキュリティポリシーデータベース（GSPD）GSPDは、RFC 3740およびセクション4.4.1.1で述べたように、マルチキャスト対応セキュリティポリシーデータベースです。RFC4301のセマンティクスは、RFC 4301のセクション4.4.1で定義されたユニキャストセキュリティポリシーデータベース（SPD）のスーパーセットです。ポイントツーポイントトラフィックセレクターが本質的に双方向であるユニキャストSPD-Sとは異なり、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.
グループレシーバーグループ送信者からグループに送信されたパケットを受け取ることが許可されているグループメンバー。
Group Sender A Group Member that is authorized to send packets to a group.
グループ送信者グループにパケットを送信する権限があるグループメンバー。
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マルチキャストパケットは、「Best-Efforts」信頼性[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]で定義されています。パケットの潜在的な受信機は、ネットワークルーティングデバイス（[RFC3376]、[RFC3810]）に登録することにより、IPマルチキャストグループに「結合」し、特定の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.
[RFC4301]のセクション4.1で説明されている理由により、IPSECのセキュリティゲートウェイ実装では、トンネルモード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.
Tunnel Modeを使用して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セキュリティゲートウェイがIPマルチキャストパケット（RFC 4301で求められている独自のIPアドレスを含む）の（外側）ソースアドレスに穴を開ける場合、結果のIPSEC保護パケットは、他の人が実行した逆パス転送（RPF）チェックに失敗する可能性があります。ルーター。失敗したRPFチェックにより、パケットがドロップされる場合があります。ルーティングプロトコルRPFチェックに対応するには、IPSECマルチキャスト拡張機能を実装するセキュリティゲートウェイは、元のPacket IPソースアドレスから外側のIPアドレスを入力する必要があります。ただし、ソースアドレスの保存を実行するセキュリティゲートウェイは、ICMPパスMTU（PMTU）またはセキュリティゲートウェイ用のその他のメッセージを受け取らないことに注意してください（外側のIPソースアドレスが内側のヘッダーに設定されたパケットでトリガーされます。）。セキュリティゲートウェイアプリケーションは、ソースアドレスの保存を必要としないため、ICMP PMTUメッセージを受信し、RFC 4301のセクション6.1で説明されているようにそれらを処理できます。
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 SASにのみ適用できます。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ソースアドレスと宛先アドレスの両方を外側（トンネル）ヘッダーに伝播すると、IPマルチキャストルーティングプロトコルがIPSECによって保護されているときにパケットを適切にルーティングできます。この結果は、マルチキャスト拡張機能が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 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.
グループセキュリティポリシーデータベースは、RFC 4301で定義されているユニキャストセキュリティ協会と、この仕様で定義されたマルチキャスト拡張機能の両方をサポートできるセキュリティポリシーデータベースです。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フラグには、ローカルトンネルアドレスの処理で使用されるAP-Lと、リモートトンネルプロセスの処理で使用されるAP-Rの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.
o 情報の処理 - どのアクションが必要か - 保護、バイパス、または破棄。すべてのセレクターセットに合わせて1つのアクションがあり、各セットの個別のアクションではありません。必要な処理が保護されている場合、エントリには次の情報が含まれています。-IPSECモード - トンネルまたは輸送 - （トンネルモードの場合）ローカルトンネルアドレス - 非モバイルホストの場合、インターフェイスが1つしかない場合、これは簡単です。複数のインターフェイスがある場合、これは静的に構成する必要があります。モバイルホストの場合、ローカルアドレスの仕様はIPSECの外部で処理されます。ローカルトンネルアドレスにアドレス保存を備えたトンネルモードが指定されている場合、AP-L属性はローカルトンネルアドレスにTRUEに設定され、ローカルトンネルアドレスは不特定です。AP-L属性の存在は、トンネルモードのIPヘッダー構造中に、内側のIPヘッダーソースアドレスが外側のIPヘッダーソースアドレスにコピーされることを示しています。 - （トンネルモードの場合）リモートトンネルアドレス - これを決定する標準的な方法はありません。RFC 4301のセクション4.5.3、「セキュリティゲートウェイの位置」を参照してください。リモートトンネルアドレスにアドレス保存を備えたトンネルモードが指定されている場合、AP-R属性はリモートトンネルアドレスにTRUEに設定され、リモートトンネルアドレスは不特定です。AP-R属性の存在は、インナーIPヘッダー宛先アドレスが、トンネルモードのIPヘッダー構造中に外側のIPヘッダー宛先アドレスにコピーされることを示しています。
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.
IPSECによって保護されているトラフィックの場合、SPDエントリのローカルおよびリモートアドレスとポートは、IKE規則と一致する方向性を表すように交換されます。一般に、IPSECが扱うプロトコルには、ローカル/リモートIPアドレスが反転した対称SASが必要な特性があります。ただし、リモート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.
o 方向性 - 「対称」、「送信者のみ」、または「受信機のみ」の3つのタイプのいずれかになります。「対称」は、SAのペアが作成されることを示しています（RFC 4301で指定されているように、各方向に1つ）。「送信者のみ」としてマークされたGSPDエントリは、1つのSAがアウトバウンド方向に作成されることを示しています。「受信機のみ」としてマークされたGSPDエントリは、1つのSAがインバウンド方向に作成されることを示しています。「送信者のみ」または「受信機のみ」としてマークされたGSPDエントリは、宛先アドレスセレクターのマルチキャストIPアドレスをサポートする必要があります。要求された処理がバイパスまたは破棄であり、「送信者のみ」タイプが構成されている場合、エントリはGSPD-Oのみに配置する必要があります。相互に、タイプが「受信機のみ」の場合、エントリはGSPD-Iのみに移動する必要があります。
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）を割り当てられる場合があります。適切なSASはRFC 4301のセクション4.1で説明されているアルゴリズムを使用して一致させることができるため、これはインバウンドトラフィックにとって問題ではありません。ただし、適切なSAを作成できるように、アウトバウンドトラフィックをGSPDセレクターと一致させる必要があります。
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は、GKMプロトコル登録交換をトリガーするポリシーアクション能力を実装する必要があります（[RFC4301]のセクション5.1に従って）。たとえば、Group Sender GSPDポリシーは、保護されたインターフェイスを介して実装を入力している、または境界の保護された側の実装によって放出され、保護されていないインターフェイスに向けられた指定されたマルチキャストアプリケーションパケットとの一致でトリガーされる場合があります。次のグループ送信者登録交換は、マルチキャストアプリケーションのデータストリームを暗号化するグループ送信者のアウトバウンドの悲しいエントリを設定します。逆方向に、グループポリシーはインバウンド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ポリシーメカニズムを使用する場合があります。そのようなポリシーメカニズムの1つは、GSPDポリシーを一致させるマルチキャストグループに参加する保護されたネットワーク内のデバイスの検出にある可能性があります（たとえば、IGMP/MLD（マルチキャストリスナーディスカバリー）を受信することにより、保護されたインターフェイスでグループメッセージを結合します）。その後のグループレシーバー登録交換は、マルチキャストアプリケーションのデータストリームを復号化するグループレシーバーのインバウンドの悲しいエントリを設定します。逆方向に、グループポリシーは、アウトバウンド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.
注：保護されたインターフェイスに到着する認可されていないメッセージの受領をトリガーするセキュリティゲートウェイは、メッセージが実際にマルチキャストグループに参加したい保護ネットワーク上のデバイスの結果ではない場合、早期のグループ受信機登録につながる可能性があります。認定されていないメッセージは、グループレシーバーが1回登録するだけです。後続のメッセージは、グループレシーバーに影響を与えません。
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は、グループメンバーシップ変更イベントでグループを再キアすることにより、グループの秘密鍵の露出を最小限に抑えることができます。また、加盟国を維持しているグループのGCKのコストを最小限に抑えます。そのような政策メカニズムの1つは、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登録と登録解除プロトコル交換を開始する場合に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.
o IPSECプロトコルモード：トンネルまたは輸送。AHまたはESPのモードがこのSAのトラフィックに適用されるかを示します。トンネルモードが指定されている場合、データ項目は、アドレス保存が外側のIPヘッダーに適用されるかどうかも示します。アドレス保存は、カプセル化ヘッダーのIPバージョンと内側ヘッダーのIPバージョンが一致しない場合に指定しないでください。ローカルアドレス、リモートアドレス、または両方のアドレスは、トンネルのカプセル化中に保存されているとマークされる場合があります。
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拡張機能には、Group Peer Authorization Database（GPAD）と呼ばれる新しいデータ構造が導入されています。GPADは、RFC 4301で定義されているパッドに類似しています。GSPDとGroup Key Management（GKM）サブシステムの間のリンクを提供します。GPADは、次の重要な機能を具体化します。
o identifies a GCKS (or group of GCKS devices) that is authorized to communicate with this IPsec entity
o このIPSECエンティティとの通信が許可されているGCK（またはGCKSデバイスのグループ）を識別します
o specifies the protocol and method used to authenticate each GCKS
o 各GCKを認証するために使用されるプロトコルと方法を指定します
o provides the authentication data for each GKCS
o 各GKCの認証データを提供します
o constrains the traffic selectors that can be asserted by a GCKS with regard to SA creation
o SA作成に関してGCKによって主張できるトラフィックセレクターを制約します
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は、GKMプロトコルとして機能しないIKEまたはその他の認証プロトコルとは相談されません。
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エンティティが接触するように構成されている各GCKのエントリが含まれています。エントリには、1つ以上のGCKS識別子、認証プロトコル（たとえば、グループセキュアーアソシエーションキー管理プロトコル（GSAKMP））、使用された認証方法（証明書や事前共有秘密）、および認証メソッド、およびグループセキュアーアソシエーションの主要な管理プロトコル（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識別子は、このグループのGCKとして機能することが許可されている1つ以上のデバイスを識別するために使用されます。GCKS識別子は、RFC 4301のセクション4.4.3.1のパッド入力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エントリが配置されたら、主張されたIDを確認する必要があります。つまり、ASTERED GCKS識別子を認証する必要があります。RFC 4301のセクション4.4.3.2で指定されているパッド認証データ型とセマンティクスは、GCKの認証に使用されます。
See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM protocol performs peer authentication using certificates and pre-shared secrets.
GDOI [RFC3547]およびGSAKMP [RFC4535]を参照して、GKMプロトコルが証明書と事前に共有された秘密を使用してピア認証を実行する方法の詳細については、参照してください。
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.
グループ識別子は、GKMプロトコルで特定のグループをGCKに識別するために使用されます。GPADエントリには、GPADエントリのGKCS識別子がグループのGCKとして機能することが許可されていることを示すグループ識別子が含まれています。
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.)
GCKが認証されると、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プロトコル登録交換がトリガーされると、グループメンバーとGCKはそれぞれ、取引所の一部としてのアイデンティティを主張します。各GKMプロトコル登録交換は、ASSERTED IDを使用してGPADにIDを見つける必要があります。GPADエントリは、特定されたGCKに使用される認証方法を指定します。エントリは、主張されたIDの検証に使用される認証データも指定します。このデータは、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実装は、多くのセキュリティ協会をサポートします。1つ以上のIPSEC SASと、IPSEC SASの作成に使用されるパラメーターをダウンロードするために使用される1つ以上のGKM SASです。これらのSASは、集合的にグループセキュリティ協会（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グループセキュリティ協会が同時に存在する可能性があります。これは、主に2つの理由により発生します。
- 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 SASの寿命は、グループレクイイベント全体でマルチキャストデータストリームに連続性があるように、時間内に重複することができます。この機能は、「再キーロールオーバー連続性」と呼ばれます。
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サブシステムは、GKMサブシステムに管理インターフェイスメカニズムを提供して、IPSEC SASを追加し、IPSEC SASを削除する必要があります。実例のために、このテキストは、グループレレキーイベントの開始と比較して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 SASをアクティブにするために、再キーイベントの開始後までの期間を定義します。ATDパラメーターは、秒単位で表されます。通常、ATDパラメーターは、GCKSからすべてのグループのメンバーにマルチキャストメッセージを配信するのにかかる最大時間に設定されます。信頼性の高いマルチキャスト輸送プロトコル（RMTP）に依存するGCKの場合、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 SASを無効にします。DTDパラメーターの目的は、再キーイベントがそのキーイングを廃止した後、グループのキーイング素材の残留曝露を最小限に抑えることです。DTDは、IPSEC SAソフトライフタイム属性から独立しており、混同されるべきではありません。DTDパラメーターは、秒単位で表されます。通常、DTDパラメーターは、グループ送信者からグループのすべてのメンバーにマルチキャストメッセージを配信するのにかかる最大時間に加えて設定されます。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によって送信されたマルチキャストメッセージを再キーリケートします。新しいグループセンダーIPSEC SA Time Epochの開始を示し、各エポックには2つのIPSEC SASの関連セットがあります。このドキュメントは、IPマルチキャスト分布の固有のスケーラビリティのため、メカニズムをマルチキャストであると呼んでいることに注意してください。ただし、メカニズムを再閉鎖することはマルチキャストでなければならないという特別な理由はありません。たとえば、[Zlly03]は、ユニキャストメッセージとマルチキャストメッセージの両方を使用する方法を説明しています。
The group membership interacts with these IPsec SAs as follows:
グループメンバーシップは、次のようにこれらのIPSEC SASと対話します。
- 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にポリシー定義の回数を再送信して、再キー情報の可用性を改善する場合があります。GKMサブシステムは、最後のRKEの再送信を受信した後、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サブシステムは、RKEマルチキャストを解釈して、新しいIPSEC SASでグループのGSPD/SADを構成します。既存のSAを置き換える各IPSEC SAは、「リーディングエッジ」IPSEC SAと呼ばれます。リーディングエッジIPSEC SAには、新しいセキュリティパラメーターインデックス（SPI）とそれに関連するキーイング材料があります。GCKSがRKEをマルチキャストしてからATD秒の期間の間、グループ送信者はリーディングエッジIPSEC SAを使用してまだデータを送信していません。一方、他のグループメンバーは、リーディングエッジIPSEC SASをそれぞれのGSPD/SADにインストールすることにより、この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.
- すべてのグループメンバーがRKEメッセージを受信して処理するようにATD期間を待った後、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を使用して新しいデータを送信しません。Trailing Edge Ipsec SAは、DTD期間がRKE透過以来経過した後、グループの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 Time Epochには異なるグループメンバーシップセットがある場合があることに注意してください。
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 SASと、この再キーロールオーバー連続性アルゴリズムをサポートする必要があります。
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]で定義されているように、データオリジン認証は、請求されたデータソースのIDを検証するセキュリティサービスです。メッセージ認証コード（MAC）は、2つの関係者間で共有される接続のデータ起源認証を達成するためによく使用されます。ただし、単一の共有秘密を使用した典型的なMac認証方法は、2つ以上のパーティーを持つグループにデータ起源認証を提供するのに十分ではありません。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].
データオリジット認証のプロパティが2つ以上の当事者が共有するIPSEC SAに必要な場合、送信者がメッセージを使用する必要があることを受信者が保証する認証変換。2つの可能なアルゴリズムは、タイミングの効率的なストリーム損失耐性認証（TESLA）[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は、MAC認証アルゴリズムを使用してIPSEC SAでカプセル化される場合があります。ただし、そのためには、グループ送信者の追加のアウトバウンド処理のために2回目にパケットをIPSEC境界全体に送信する必要があります（[RFC4301]のセクション5.1を参照）。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キャッシュが含まれます。ただし、実装者は、IKEV2 SPI割り当てはGKM SPI割り当てから完全に独立していることに注意する必要があります。これは、グループセキュリティアソシエーションが宛先マルチキャストIPアドレスによって資格があり、オプションでソースIPアドレス予選を持つ場合があるためです。詳細については、[RFC4303]のセクション2.1を参照してください。
The Peer Authorization Database does require explicit coordination between the GKM protocol and IKEv2. Section 4.1.3 describes these interactions.
Peer Authorizationデータベースには、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.
トラフィックの処理は[RFC4301]のセクション5に従って、これらのIPマルチキャスト拡張機能がサポートされている場合に以下に説明されています。
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:
トンネルモードのヘッダー構造は、RFC4301のセクション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.
o アドレスの保存が、外側のIPヘッダーソースアドレスまたは宛先アドレスのいずれかのSADエントリにマークされていない場合、外側のIPヘッダーソースアドレスと宛先アドレスがトンネル（エンコペーターと脱カプセレータ）の「エンドポイント」を識別します。IPヘッダーソースアドレスにアドレスの保存がマークされている場合、内側のIPヘッダーソースアドレスからコピーされます。IPヘッダー宛先アドレスにアドレス保存がマークされている場合、内側のIPヘッダー宛先アドレスからコピーされます。内側のIPヘッダーソースアドレスと宛先アドレスは、それぞれ（このトンネルの観点から）データグラムの元の送信者と受信者を識別します。アドレス保存は、カプセル化ヘッダーのIPバージョンと内側ヘッダーのIPバージョンが一致しない場合にマークしないでください。
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のトンネルアドレスの構築に関するもので、次のように修正されます。（注：Brevityの場合、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.
(3) アドレスの保存にマークされていない限り、ローカルおよびリモートアドレスは、リモートアドレスを決定するために使用されるSAに依存します。これは、パケットを転送するためにどのローカルアドレス（ネットインターフェイス）が使用されるかを決定します。アドレスの保存がローカルアドレスにマークされている場合、内側のIPヘッダーからコピーされます。アドレスの保存がリモートアドレスにマークされている場合、そのアドレスは内側のIPヘッダーからコピーされます。
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デバイスによって生成されたIPSECの保護パケット（GSPDポリシーに応じて）は、IPSECデバイスにアドレス指定されないように、宛先アドレスに外側のトンネルヘッダーに設定する場合があります。これには、これらのマルチキャスト拡張機能をサポートするIPSECデバイスがIPSECデバイス自体に宛てられていないIPトラフィックを受け入れて処理する必要があります。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.
RFC 4301のセクション5.2で説明されているインバウンドIPトラフィックの処理に関する説明は、次のように修正されます。
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.
- パケットがIPSECの保護されているように見え、このデバイスに宛てられた場合、またはIPSECが保護されているように見える場合、マルチキャストグループに宛てられている場合、SADを介してアクティブなSAにマッピングする試みが行われます。デバイスには、SCTPなどのプロトコルの場合、SADルックアップで使用される可能性のある複数のIPアドレスがある場合があることに注意してください。
A new item is added to the list between items 3a and 3b to describe processing of IPsec packets with destination address preservation applied:
新しいアイテムが項目3Aと3Bの間にリストに追加され、宛先アドレスの保存を適用したIPSECパケットの処理を説明します。
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.
3AA。パケットがマルチキャストグループに宛てられ、AHまたはESPがプロトコルとして指定されている場合、パケットはSADで検索されます。セクション4.1で指定されているように、SPIプラス宛先またはSPIプラス宛先およびソースアドレスを使用します。一致していない場合、パケットはSPD-Iルックアップに向けられます。IPSECデバイスがセキュリティゲートウェイであり、SPD-Iポリシーがパケットをバイパスすることである場合、マルチキャストパケットのルーティングされたパスに沿った後続のセキュリティゲートウェイがパケットを復号化する可能性があることに注意してください。
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)
図1.インバウンドトラフィックの処理モデル（RFC 4301の図3の修正）
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.
6. IPSEC SAがアドレス保存（セクション3.1で説明されている）を備えたサポートトンネルモードとしてマークされている場合、外側IPヘッダーのマークされたアドレス（ES）（つまり、ソースおよび/または宛先アドレス（ES））を確認する必要があります。内側のIPヘッダーと同じ値。アドレスが一貫していない場合、IPSECシステムはパケットを破棄し、矛盾を監査可能なイベントとして扱う必要があります。
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セキュリティマルチキャスト拡張機能は、ユニキャスト指向のIPセキュリティアーキテクチャ[RFC4301]に基づいて構築されています。その結果、この仕様は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.
- グループ送信者データ起源認証デジタル署名、テスラ、またはその他のメカニズムを使用します。
- 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および/または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、PAD、および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.
IPSECマルチキャスト拡張サービスによって解決されたままになっているセキュリティの問題は、アウトサイダー攻撃とインサイダー攻撃という2つの広範なカテゴリに分けられます。
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.
- 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セキュリティマルチキャスト拡張機能は、グループのポリシーに準拠して信頼できるメンバーを正しく認証および承認するための自動グループキー管理プロトコルに依存しています。暗号化グループの概念に固有のものは、すべてのグループメンバーに委託された1つ以上の共有秘密のセットです。その結果、サービスのセキュリティ保証は、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.
- グループのData Origin Authentication Serviceがデジタル署名を使用している場合、インサイダーの敵は、マルチリキャスト偽の署名パケットによる計算リソース拒否攻撃を開始できます。
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アドレスの変更により、そのマルチキャストグループに関連するGSPDエントリは、グループのマルチキャストルーティング状態に関して古くなります。最悪の場合、新しいソースアドレスに由来するグループ送信者のデータが、セキュリティゲートウェイによって処理されるリスクがあります。このシナリオが予想されていない場合、グループのデータを漏らす可能性があります。したがって、SSMセキュアマルチキャストグループには、SSMグループの宛先IPアドレスのすべての不正なグループ送信者ソースIPアドレスに対してデフォルトの破棄ポリシーを持つことが推奨されます。
The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, and Tero Kivinen for their helpful comments.
著者は、彼らの有益なコメントをしてくれたSteven Kent、Russ Housley、Pasi 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]に相談して、このメモのセキュリティに関する考慮事項セクションを開発しました。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security Composite Cryptographic Groups", Work in Progress, February 2007.
[compgrp] Gross G.およびH. Cruickshank、「マルチキャストIPセキュリティコンポジット暗号グループ」、2007年2月、Work in Progress。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、RFC 2526、1999年3月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627] Wallner、D.、Harder、E。、およびR. Agee、「マルチキャストの重要な管理：問題とアーキテクチャ」、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.、Meyer、D。、およびM. Schipper、「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] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307] Haberman、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S.、ed。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R.、ed。、およびL. Costa、ed。、「Multicast Riesder Discoveryバージョン2（MLDV2）のIPv6」、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] Adamson、B.、Bormann、C.、Handley、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.、Canetti、R.、Dondeti、L。、およびF. Lindholm、「マルチキャストセキュリティ（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.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換紹介」、RFC 4082、2005年6月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年1月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年6月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[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.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「IPSECを使用してIPv6-in-IPV4トンネルを保護する」、RFC 4891、2007年5月。
[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] Zhang、X.、et al。、「スケーラブルで信頼できるグループの再キーイングのためのプロトコル設計」、ネットワーキングに関するIEEE/ACMトランザクション（TON）、第11巻、第6号、2003年12月。
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.
安全なマルチキャストアプリケーションの大部分は、サービスモデルとそれに伴うグループ内通信パターンによってカタログ化できます。Group Key Management（GKM）サブシステムとIPSECサブシステムの両方が、これらの支配的な使用シナリオに一致するようにGSPD/SADセキュリティポリシーを構成できる必要があります。GSPD/SADポリシーには、これらの各サービスモデルに対して、任意のソースマルチキャストグループとソース固有のマルチキャストグループの両方を構成する機能を含める必要があります。GKMサブシステム管理インターフェイスには、この標準で特定されていないサービスモデルのセキュリティポリシーを構成するメカニズムが含まれる場合があります。
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サブシステムが単方向SPDエントリをサポートする必要があります。送信を許可されたグループメンバーが1人しかないマルチキャストアプリケーションは、このタイプのグループセキュリティ協会を使用して、そのグループポリシーを実施できます。逆方向には、GSAには悲しいエントリがなく、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サブシステムグループを設定する機能が必要です。
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 SASは、各IPSEC SAを識別するために2 Tuple {destination IPアドレス、SPI}を使用する必要があります。さらに、GKMは、IKEV2ユニキャストIPSEC SAが使用している宛先IPアドレスと一致しないユニキャスト宛先IPアドレスを使用する必要があります。たとえば、グループメンバーがIKEV2とGKMプロトコルの両方を使用していると仮定し、グループセキュリティポリシーでは、上記のように通常の逆データフローを保護する必要があります。この場合、グループポリシーは、NORMグループ送信者を表す一意のユニキャスト宛先IPアドレスを割り当てて使用する必要があります。このアドレスは、グループ送信者の既存のIPアドレスと並行して構成されます。Norm Group SenderとGroup Receiverの両方のエンドポイントのGKMサブシステムは、IPSEC SAをインストールし、SAルックアップがユニキャスト宛先アドレスとSPIを使用するようなNORMユニキャストメッセージを保護します。
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のグループレシーバーの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つのグループ送信者を設定する機能が必要です。管理インターフェイスは、それぞれが独自のGSAアンチレプレイ状態を備えた少なくとも16の同時認定送信者を持つようにグループを構成できる必要があります。
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セキュリティポリシーを持つグループを設定する機能が必要です。
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オブジェクト識別子を更新します。
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 -noswap（in selectorList）-ap -l、ap -r（Tunneloptions）
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-modules（3）SPD-Module（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) } ;
-- 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
George Gross Secure Multicast Networks LLC 977 Bates Road Shoreham, VT 05770 USA
George Gross Secure Multicast Networks LLC 977 Bates Road Shoreham、VT 05770 USA
Phone: +1-802-897-5339
EMail: gmgross@securemulticast.net
Dragan Ignjatic Polycom Suite 200 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
ドラガン・イグナジャティック・ポリコム・スイート200 3605ギルモア・ウェイ・バーナビー、BC V5G 4x5カナダ
Phone: +1-604-453-9424
EMail: dignjatic@polycom.com