RFC5374 日本語訳
5374 Multicast Extensions to the Security Architecture for theInternet Protocol. B. Weis, G. Gross, D. Ignjatic. November 2008. (Format: TXT=87729 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.ウィス要求をネットワークでつないでください: 5374年のシスコシステムズカテゴリ: 総計の安全な標準化過程のマルチキャストネットワークLLC D.Ignjatic Polycom G.2008年11月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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.
インターネットプロトコルのためのSecurity ArchitectureはIP層のトラフィックのためのセキュリティー・サービスについて説明します。 そのアーキテクチャは主としてインターネットプロトコル(IP)ユニキャストパケットのためのサービスを定義します。 このドキュメントはIPsecセキュリティー・サービスがどう適用されるかをIPマルチキャストパケットに説明します。 マルチキャストをサポートするIPsec実装だけにおいて、これらの拡大は関連しています。
Weis, et al. Standards Track [Page 1] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[1ページ]。
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
1. 序論…3 1.1. 範囲…3 1.2. 用語…4 2. IPマルチキャスト操作の概要…6 3. セキュリティ協会モード…7 3.1. アドレス保存でモードにトンネルを堀ってください…7 4. セキュリティ協会…8 4.1. 主要なIPsecデータベース…8 4.1.1. 安全保障政策データベース(GSPD)を分類してください…8 4.1.2. セキュリティ協会データベース(悲しい)…12 4.1.3. 同輩承認データベース(GPAD)を分類してください…12 4.2. セキュリティ協会(GSA)を分類してください…14 4.2.1. 同時発生のIPsec SA寿命と再主要なロールオーバー.15 4.3。 データ発生源認証…17 4.4. SAとKey Managementを分類してください…18 4.4.1. 複数のKey Managementプロトコルの共存。18 5. IPトラフィック処理…18 5.1. 外国行きのIPトラフィック処理…18 5.2. 本国行きのIPトラフィック処理…19 6. セキュリティ問題…22 6.1. IPsecマルチキャスト拡張子で解決されたセキュリティ問題…22 6.2. IPsecマルチキャスト拡張子で解決されなかった安全保障問題。23 6.2.1. 部外者は攻撃します…23 6.2.2. インサイダーは攻撃します…23 6.3. 実装かDeployment Issues、そのImpact Security。24 6.3.1. 同質的な集団暗号アルゴリズム能力…24 6.3.2. グループのそのSpan TwoかMore Security Policy Domains…24 6.3.3. ソース特有のマルチキャストグループ送付者一時的なロケータ…25 7. 承認…25 8. 参照…25 8.1. 標準の参照…25 8.2. 有益な参照…26 付録A--マルチキャストアプリケーション・サービスはモデル化されます…28 A.1単方向のマルチキャストアプリケーション…28 A.2の双方向の高信頼のマルチキャストアプリケーション…28 A.3マルチキャストのいずれへのいずれもアプリケーション…30 付録B--GSPDエントリーへのASN.1…30 GSPDエントリーに特定のB.1分野…30B.2 SPDModule…31
Weis, et al. Standards Track [Page 2] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[2ページ]。
1. Introduction
1. 序論
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]のためのSecurity ArchitectureはIP層のトラフィックのためのセキュリティー・サービスを提供します。 それはIPsec対応することのシステムのためのアーキテクチャとIP層のためのセキュリティー・サービスのセットについて説明します。 これらのセキュリティー・サービスは主としてサービスについて説明します、そして、IPsec Security Associations(SAs)のための意味論は2台のIPsecデバイスを平等に割り当てました。 ユニキャストアドレスがIPあて先フィールドにある状態で、通常、これはトラフィックセレクタがあるIPあて先フィールドにユニキャストアドレスを含んでいて、IPsecパケットに結果を含んでいるSAsを含んでいます。 また、トンネルIPマルチキャストパケットにRFC4301で定義されたセキュリティー・サービスは使用できます、トンネルが2台のIPsecデバイスの間の対合であるところで。 マルチキャストアドレスが受信者IPアドレス分野にある状態で、手動で定義されたRFC4301はIPパケットの交通機関IPsec SAサポートを合わせました。 しかしながら、RFC4301はIPマルチキャストアドレスで外側のIPヘッダーでGroup Key ManagementプロトコルとのIPsecサブシステムの相互作用かトンネルモード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セキュリティー体系を定義するRFC4301にOPTIONAL拡張子について説明します。 IPマルチキャストアドレスがIPあて先フィールドにある状態で、特に、それは、IPsecパケットでトラフィックがあるSAsがIPあて先フィールドにマルチキャストアドレスを含んでいるセレクタとその結果であるとサポートします。 また、それは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.
このドキュメント中では、明確にそれと反対に注意されない場合、4301年のRFC意味論はこれらのマルチキャスト拡大の存在で変わりがありません。
1.1. Scope
1.1. 範囲
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
本書では説明されたIPsec拡張子は、送付先アドレスとしてIPsecパケットでIPv4かIPv6マルチキャストグループアドレスでIPsec Security Associationsがその結果であるとサポートします。 Any-ソースMulticast(ASM)とSource特有のMulticast(SSM)[RFC3569]グループアドレスの両方がサポートされます。 経営政策が、IPsecによって保護されたIPマルチキャストパケットがIPマルチキャストパケットのままで残っているのを必要とするとき、これらの拡大は使用されています。 経営政策です。
Weis, et al. Standards Track [Page 3] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[3ページ]。
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.
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リンク・レベルBroadcastパケットでIPv4 BroadcastアドレスがあるSecurity Associationsがその結果であるとサポートします、そして、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に参加するためにマルチキャストで可能にされたネットワークで中間システムを必要としません。 特に、要件は全くマルチキャストルーティング・プロトコル(例えば、プロトコル無党派Multicast--まばらなMode(PIM-SM)[RFC4601])かマルチキャスト入場プロトコル(例えば、インターネットGroup Managementプロトコル(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ファイル拡張仕様書のこのバージョンは、Security Associationに参加するすべてのIPsecデバイスが均質であることを必要とします。 彼らは一般的な暗号の変換とプロトコル取り扱い能力を共有しなければなりません。 「IPsec合成群」[COMPGRP]の意味論(2つ以上のサブグループの組合から結成される種々雑多なIPsec暗号のグループ)は今後の標準化のための領域です。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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.
いくらか、-、ソース、RFC1112[RFC1112]で定義されるインターネットプロトコル(IP)マルチキャストサービスモデルのMulticast(ASM)。 このモデル、ただ一つのIPマルチキャストアドレスへの1つ以上の送付者ソースパケットで。 受信機がグループに加わるとき、彼らはそのIPマルチキャストアドレスに送られたすべてのパケットを受けます。 これは(*、G)グループとして知られています。
Weis, et al. Standards Track [Page 4] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[4ページ]。
Group
A set of devices that work together to protect group
communications.
保護するために一緒に動作するデバイスのグループAセットはコミュニケーションから構成されています。
Group Controller Key Server (GCKS)
A Group Key Management (GKM) protocol server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GKM Group Members.
グループのためにIPsec状態を経営するController Key Server(GCKS)A Group Key Management(GKM)プロトコルサーバを分類してください。 GCKSはIPsec SA方針と合わせることの材料をGKM Groupメンバーに認証して、供給します。
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.
グループKey Management(GKM)はIPsec Security Association方針を分配するのにGCKSによって使用されて、材料を合わせるA主要な管理プロトコルについて議定書の中で述べます。 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.
Group Key Managementプロトコルを実装して、IPsecデバイスでKey Management Subsystem Aサブシステムを分類してください。 GKMサブシステムはIPsecデバイスの上のIPsecサブシステムにIPsec SAsを提供します。 追加情報についてRFC3547[RFC3547]とRFC4535[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.
グループのものメンバーAn IPsecデバイスを分類してください。 GroupメンバーはGroup Sender、そして/または、Group Receiverであるのに権限を与えられます。
Group Owner
An administrative entity that chooses the policy for a group.
グループのために方針を選ぶOwner Anの管理実体を分類してください。
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メンバーが主要なアップデートを受け取るのに必要なIPsec Security Associations(SAs)とGKMサブシステムSAsのSecurity Association(GSA)A収集を分類してください。 GSAはグループのために働く方針を説明します。 追加情報についてRFC4046[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.
グループSecurity Policy Database(GSPD)GSPDはマルチキャストできる安全保障政策データベースです、RFC4301についてRFC3740とセクション4.4.1で.1に言及されるように。 意味論は.1セクション4.4RFC4301によって定義されたユニキャストSecurity Policy Database(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 Group Security Policy Database(安全なトラフィック) .1セクション4.4RFC4301を見てください。
Weis, et al. Standards Track [Page 5] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[5ページ]。
Group Receiver
A Group Member that is authorized to receive packets sent to a
group by a Group Sender.
パケットを受けるのに権限を与えられるグループのReceiver A GroupメンバーはGroup Senderによるグループに発信しました。
Group Sender
A Group Member that is authorized to send packets to a group.
パケットをグループに送るのに権限を与えられるSender 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.
RFC3569[RFC3569]で定義されるインターネットプロトコル(IP)マルチキャストサービスモデルのソース特有のMulticast(SSM)。 このモデルでは、送付者の各組み合わせと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がマルチキャストパケットであるとカプセル化するときにはIPsecトンネルモードのAddress Preservation Aタイプがセキュリティゲートウェイ実装によって使用されている状態で、IPマルチキャストパケットのままで残るようにModeにトンネルを堀ってください。 IPマルチキャストルーティングが正しくIPsecによって保護されたIPマルチキャストパケットを発送するのにこのモードが必要です。
2. Overview of IP Multicast Operation
2. IPマルチキャスト操作の概要
IP multicasting is a means of sending a single packet to a "host group", a set of zero or more hosts identified by a single IP destination address. IP multicast packets are delivered to all members of the group either with "best-efforts" reliability [RFC1112] or as part of a reliable stream (e.g., NACK-Oriented Reliable Multicast (NORM) [RFC3940]).
IPマルチキャスティングは「ホストグループ」に単一のパケットを送る手段であり、ゼロか以上のセットはただ一つの受信者IPアドレスによって特定されたホストです。 IPマルチキャストパケットは「最善の努力」の信頼性[RFC1112]か信頼できるストリームの一部としてグループのすべてのメンバーに提供されます(例えば、ナックはReliable Multicast(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]とともに記名することによって、IPマルチキャストグループを「接合します」、[RFC3810)、特定のIPマルチキャストグループに送られたパケットを受ける意図に合図して。
Network routing devices configured to pass IP multicast packets participate in multicast routing protocols (e.g., PIM-SM) [RFC4601]. Multicast routing protocols maintain state regarding which devices have registered to receive packets for a particular IP multicast group. When a router receives an IP multicast packet, it forwards a copy of the packet out of each interface for which there are known receivers.
IPマルチキャストパケットを通過するために構成されたネットワークルーティングデバイスはマルチキャストルーティング・プロトコル(例えば、PIM-SM)[RFC4601]に参加します。 マルチキャストルーティング・プロトコルはデバイスが特定のIPマルチキャストグループのためにパケットを受けるために登録された状態を維持します。 ルータがIPマルチキャストパケットを受けるとき、それは受信機が知られている各インタフェースからパケットのコピーを進めます。
Weis, et al. Standards Track [Page 6] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[6ページ]。
3. Security Association Modes
3. セキュリティ協会モード
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 Authentication Header(AH)[RFC4302]とIP Encapsulating Security有効搭載量(超能力)[RFC4303]は主として次の層のプロトコルのための保護を提供します。 トンネルモードで、AHと超能力はトンネルを堀られたIPパケットに適用されます。
A host implementation of IPsec using the multicast extensions MAY use either transport mode or tunnel mode to encapsulate an IP multicast packet. These processing rules are identical to the rules described in Section 4.1 of [RFC4301]. However, the destination address for the IPsec packet is an IP multicast address, rather than a unicast host address.
マルチキャスト拡張子を使用するIPsecのホスト導入は、IPマルチキャストパケットをカプセルに入れるのに交通機関かトンネルモードのどちらかを使用するかもしれません。 これらの処理規則は[RFC4301]のセクション4.1で説明された規則と同じです。 しかしながら、IPsecパケットのための送付先アドレスはユニキャストホスト・アドレスよりむしろIPマルチキャストアドレスです。
A security gateway implementation of IPsec MUST use a tunnel mode SA, for the reasons described in Section 4.1 of [RFC4301]. In particular, the security gateway needs to use tunnel mode to encapsulate incoming fragments, since IPsec cannot directly operate on fragments.
IPsecのセキュリティゲートウェイ実装は[RFC4301]のセクション4.1のSAであって、理由で説明されたトンネルモードを使用しなければなりません。 特に、セキュリティゲートウェイは、入って来る断片をカプセルに入れるのにトンネルモードを使用する必要があります、IPsecが断片を直接作動させることができないので。
3.1. Tunnel Mode with Address Preservation
3.1. アドレス保存があるトンネル・モード
New (tunnel) header construction semantics are required when tunnel mode is used to encapsulate IP multicast packets that are to remain IP multicast packets. These semantics are due to the following unique requirements of IP multicast routing protocols (e.g., PIM-SM [RFC4601]). This document describes these new header construction semantics as "tunnel mode with address preservation", which is described as follows.
トンネルモードがIPがIPマルチキャストパケットのままで残ることになっているマルチキャストパケットであるとカプセル化するのに使用されるとき、新しい(トンネル)ヘッダー工事意味論が必要です。 これらの意味論はIPマルチキャストルーティング・プロトコル(例えば、PIM-SM[RFC4601])の以下のユニークな要件のためです。 このドキュメントは「アドレス保存があるトンネルモード」としてこれらの新しいヘッダー工事意味論を記述します。(それは、以下の通り説明されます)。
- When an IP multicast packet is received by a host or router, the
destination address of the packet is compared to the local IP
multicast state. If the (outer) destination IP address of an IP
multicast packet is set to another IP address, the host or router
receiving the IP multicast packet will not process it properly.
Therefore, an IPsec security gateway needs to populate the
multicast IP destination address in the outer header using the
destination address from the inner header after IPsec tunnel
encapsulation.
- ホストかルータでIPマルチキャストパケットを受け取るとき、パケットの送付先アドレスをローカルアイピーマルチキャスト状態にたとえます。 IPマルチキャストパケットの(外側)の送付先IPアドレスが別のIPアドレスに設定されると、IPマルチキャストパケットを受けるホストかルータが適切にそれを処理しないでしょう。 したがって、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
- IPマルチキャストルーティング・プロトコルはグループアドレスと同様にソースアドレスに基づくマルチキャスト分配木を通常作成します。 IPsecセキュリティゲートウェイがIPマルチキャストパケットの(外側)のソースアドレスに居住するなら(それ自身のIPアドレスRFC4301で求められるように)、結果として起こるIPsecによって保護されたパケットは他のルータによって実行されたReverse Path Forwarding(RPF)チェックに失敗するかもしれません。 パケットの結果があって、失敗したRPFチェックはそうするかもしれません。
Weis, et al. Standards Track [Page 7] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[7ページ]。
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.
下げられる。 ルーティングに対応するには、RPFチェック(オリジナルのパケットIPソースアドレスからの外側のIPアドレスを拡大SHOULDが居住するIPsecマルチキャストに実装するセキュリティゲートウェイ)について議定書の中で述べてください。 しかしながら、ソースアドレス保存を実行するセキュリティゲートウェイがセキュリティゲートウェイ(内側のヘッダーのものに外側のIPソースアドレスを設定したパケットで、引き起こされる)に意図するICMP Path MTU(PMTU)か他のメッセージを受け取らないことに注意されるべきです。 ソースアドレス保存を必要としないセキュリティゲートウェイアプリケーションは、RFC4301のセクション6.1で説明されるようにICMP PMTUメッセージを受け取って、それらを処理できるでしょう。
Because some applications of address preservation may require that only the destination address be preserved, specification of destination address preservation and source address preservation are separated in the above description. Destination address preservation and source address preservation attributes are described in the Group Security Policy Database (GSPD) (defined later in this document), and are copied into corresponding Security Association Database (SAD) entries.
アドレス保存のいくつかの応用が、送付先アドレスだけが保存されるのを必要とするかもしれないので、目的地アドレス保存とソースアドレス保存の仕様は上の記述で切り離されます。 目的地アドレス保存とソースアドレス保存属性は、Group Security Policy Database(GSPD)(後で本書では定義される)で説明されて、対応するSecurity Association Database(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".
パケットがIPsecによって保護されるとき、概要では、IPソースと内側のIPヘッダーの送付先アドレスの両方を外側の(トンネル)ヘッダーに伝播するのに、IPマルチキャストルーティング・プロトコルは適切にパケットを発送できます。 ホストかセキュリティゲートウェイがマルチキャスト拡大からIPマルチキャストパケットのためのサービスをIPsecに供給できるように、この結果が必要です。 RFC4301トンネルモードのこのメソッドは「アドレス保存があるトンネルモード」として知られています。
4. Security Association
4. セキュリティ協会
4.1. Major IPsec Databases
4.1. 主要なIPsecデータベース
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は、マルチキャストを完全にサポートするために意味論を広げました。
4.1.1. Group Security Policy Database (GSPD)
4.1.1. グループ安全保障政策データベース(GSPD)
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
Group Security Policy Databaseは両方がRFC4301によって定義されるユニキャストSecurity Associationsとこれによって定義されたマルチキャスト拡大であるとサポートすることができる安全保障政策データベースです。
Weis, et al. Standards Track [Page 8] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[8ページ]。
specification. The GSPD is considered to be the SPD, with the addition of the semantics relating to the multicast extensions described in this section. Appendix B provides an example of an ASN.1 definition of a GSPD entry.
仕様。 GSPDはSPDであると考えられます、意味論の追加がこのセクションで説明されたマルチキャスト拡大に関連する状態で。 付録BはGSPDエントリーのASN.1定義に関する例を提供します。
This document describes a new "address preservation" (AP) flag indicating that tunnel mode with address preservation is to be applied to a GSPD entry. The AP flag has two attributes: AP-L, used in the processing of the local tunnel address, and AP-R, used in the processing of the remote tunnel process. This flag is added to the GSPD "Processing info" field of the GSPD. The following text reproduced from Section 4.4.1.2 of RFC 4301 is amended to include this additional processing. (Note: for brevity, only the "Processing info" text related to tunnel processing has been reproduced.)
このドキュメントはアドレス保存があるトンネルモードがGSPDエントリーに適用されることであることを示す新しい「アドレス保存」(AP)旗について説明します。 AP旗には、2つの属性があります: ローカルのトンネルアドレスの処理に使用されるAP-L、およびリモートトンネルプロセスの処理に使用されるAP-R。 この旗はGSPDのGSPD「処理インフォメーション」分野に加えられます。 .2RFC4301が修正されるセクション4.4.1から複製された以下のテキストはこの追加処理を含んでいます。 (注意: 簡潔さにおいて、トンネル処理に関連する「処理インフォメーション」テキストだけが複製されました。)
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 処理インフォメーション(それの動作はある)が必要です--PROTECT、BYPASS、またはDISCARD。 各セットのために別行動ではなく、すべてのセレクタセットを伴うちょうど1つの動作があります。 必要な処理がPROTECTであるなら、エントリーは以下の情報を含んでいます。 - IPsecモード--トンネルか輸送--(トンネルモードであるなら) 非モバイルホストのためのローカルのトンネルアドレス、ちょうど1つのインタフェースがあれば、これは簡単です。 複数のインタフェースがあれば、静的にこれを構成しなければなりません。 モバイルホストに関しては、ローカルアドレスの仕様は外部的にIPsecに扱われます。 アドレス保存があるトンネルモードがローカルのトンネルアドレスに指定されるなら、AP-L属性はローカルのトンネルアドレスのためにTRUEに設定されます、そして、ローカルのトンネルアドレスは不特定です。 AP-L属性の存在は、内側のIPヘッダーソースアドレスがトンネルモードのためのIPヘッダー工事の間外側のIPヘッダーソースアドレスにコピーされるのを示します。 - (トンネルモードであるなら) リモートトンネルアドレス--これを決定するどんな標準の方法もありません。 「セキュリティゲートウェイの場所を見つけ」て、.3セクション4.5RFC4301を見てください。 アドレス保存があるトンネルモードがリモートトンネルアドレスに指定されるなら、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マルチキャストアドレスを送ってはいけないので
Weis, et al. Standards Track [Page 9] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[9ページ]。
[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]、Local、Remoteアドレス、およびポートの方向性が入って来るSPD-Sの間、維持されて、SPD-Iは交換されるよりむしろチェックします。 .1セクション4.4RFC4301が以下の通り修正されます:
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エントリーにおけるLocal、Remoteアドレス、およびポートは方向性を表すために交換されます、IKEコンベンションと一致しています。 一般に、IPsecが対処するプロトコルははじき出されたLocal/リモートなIPアドレスがある左右対称のSAsを必要とする特性を持っています。 しかしながら、リモートIPマルチキャストアドレスによるSPDエントリーはSPDエントリーにおけるアドレスとポートが入って来るSPD-Sの間に交換したそれらのLocalとRemoteを持っていません、そして、SPD-Iはチェックします。
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.
新しいGroup Security Policy Database(GSPD)属性を導入します: GSPDエントリーの方向性。 以下のテキストはSPDの弾丸リストに追加されて、分野がセクション4.4.1で.2RFC4301について説明したということです。
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つのタイプのひとりであることができます: 「左右対称である」か、「送付者専用」、または「受信機専用。」 「左右対称」が、1組のSAsが作成されることになっているのを示す、(あるコネ、RFC4301)によって指定されるような各方向。 「送付者専用」として示されるGSPDエントリーは、1SAが外国行きの方向に作成されることになっているのを示します。 「受信機専用」として示されるGSPDエントリーは、1SAが本国行きの方向に作成されることになっているのを示します。 GSPDエントリーは、「送付者専用」か「受信機専用」としてそれらの目的地アドレスセレクタでSHOULDサポートがマルチキャストIPアドレスであるとマークしました。 要求された処理がBYPASSかDISCARDであり、「送付者専用」タイプが構成されるなら、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エントリーは同じSecurity Parameter Indexes(SPIs)をIKEv2[RFC4306]によって作成されたSADエントリーに割り当てられるかもしれません。 RFC4301のセクション4.1で説明されたアルゴリズムを使用することで適切なSAsを合わせることができるので、これはインバウンドトラフィックのための問題ではありません。 しかしながら、アウトバウンドトラフィックは、適切な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
ダイナミックなグループの合わせることを容易にするために、外国行きのGSPD MUSTは、政策的措置がGKMプロトコル登録交換([RFC4301]のセクション5.1に従って)の引き金となる能力であると実装します。 例えば、それは、Group Sender GSPD方針が保護されたインタフェースを通して実装に入っている指定されたマルチキャストアプリケーションパケットとのマッチの上に引き金となるかもしれませんか、境界保護側の上の実装によって放たれていて、または指示されます。
Weis, et al. Standards Track [Page 10] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[10ページ]。
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.
保護のないインタフェース。 登録交換がマルチキャストアプリケーションのデータを暗号化するGroup Senderの外国行きのSADエントリーに設定する続いているGroup Senderは流れます。 また、逆さの方向に、グループ方針は本国行きの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).
Group Receiver終点では、IPsecサブシステムがGKMプロトコル登録交換を起こすGSPD方針メカニズムを使用するかもしれません。 マルチキャストグループマッチングGSPD方針に合流する保護されたネットワークにおける、デバイスの検出にはそのようなメカニズムの方針1つがあるかもしれません(例えば、IGMP/MLD(マルチキャストListenerディスカバリー)を受けることによって、保護されたインタフェースに関するグループメッセージを接合してください)。 登録交換がマルチキャストがアプリケーションのデータであると解読するGroup Receiverの本国行きのSADエントリーに設定する続いているGroup Receiverは流れます。 また、逆さの方向に、グループ方針は外国行きの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.
以下に注意してください。 保護されたインタフェースで到着しながら非認証されることの領収書の上でメッセージの引き金となるセキュリティゲートウェイはメッセージが保護されたネットワークのデバイスが実際にマルチキャストグループに加わりたがっているという結果でないなら早めのGroup Receiver登録をもたらすかもしれません。 非認証されたメッセージで、Group Receiverは一度登録するだけでしょう。 その後のメッセージはGroup Receiverで効き目がないでしょう。
The IPsec subsystem MAY provide GSPD policy mechanisms that automatically initiate a GKM protocol de-registration exchange. De-registration allows a GCKS to minimize exposure of the group's secret key by re-keying a group on a group membership change event. It also minimizes cost on a GCKS for those groups that maintain member state. One such policy mechanism could be the detection of IGMP/MLD leave group exchange. However, a security gateway Group Member would not initiate a GKM protocol de-registration exchange until it detects that there are no more receivers behind a protected interface.
IPsecサブシステムは自動的にGKMプロトコル反-登録を開始するGSPD方針メカニズムに交換を供給するかもしれません。 反-登録で、GCKSは、グループ会員資格変化イベントにグループを再合わせることによって、グループの秘密鍵の展示を最小にすることができます。 また、それは加盟国を維持するそれらのグループのためにGCKSで費用を最小にします。 そのようなメカニズムの方針1つはグループが交換するIGMP/MLD休暇の検出であるかもしれません。 しかしながら、セキュリティゲートウェイGroupメンバーはそれまでの交換が検出する保護されたインタフェースの後ろにそれ以上の受信機が全くない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州の情報をセットアップするかもしれません。 このシナリオでは、Group OwnerはそれがいつGKM登録と反-登録を始めるべきであるかをGKMサブシステムに言う管理指示にプロトコル交換を発行します。 グループのIPsecサブシステム状態が実行を始めるマルチキャストアプリケーションを予測して「いつも準備ができていること」を確実にする通常登録方針不和。
Weis, et al. Standards Track [Page 11] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[11ページ]。
4.1.2. Security Association Database (SAD)
4.1.2. セキュリティ協会データベース(悲しい)です。
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でトラフィックに適用されるかどうか説明する項目を含んでいます。 .1が説明するために修正されるRFC4301セクション4.4.2におけるテキストは保存を扱います。
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か超能力のどのモードがこのSAでトラフィックに適用されるかを示します。 また、トンネルモードが指定されるとき、データ項目は、アドレス保存が外側のIPヘッダーに適用されるかどうかを示します。 IPバージョンであるなら指定されていなくて、保存がそうしなければならない要約のヘッダーのアドレスと内側のヘッダーのIPバージョンは合っていません。 ローカルアドレス、リモートアドレス、またはアドレスの両方がトンネルカプセル化の間、保存されるとしてマークされるかもしれません。
4.1.3. Group Peer Authorization Database (GPAD)
4.1.3. グループ同輩承認データベース(GPAD)
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はRFC4301で定義されたPADに類似しています。 それは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実体で交信するのが認可されるGCKS(または、GCKSデバイスのグループ)を特定します。
o specifies the protocol and method used to authenticate each
GCKS
o 各GCKSを認証するのに使用されるプロトコルとメソッドを指定します。
o provides the authentication data for each GKCS
o 各GKCSのための認証データを提供します。
o constrains the traffic selectors that can be asserted by a
GCKS with regard to SA creation
o GCKSがSA作成に関して断言できるトラフィックセレクタを抑制します。
o constrains the types and values of Group Identifiers for
which a GCKS is authorized to provide group policy
o GCKSがグループ方針を提供するのが認可されるGroup Identifiersのタイプと値を抑制します。
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はGroup Key Managementサブシステムにこれらの機能を提供します。 GPADはIKEかGKMプロトコルとして作動しない他の認証プロトコルによって相談されません。
To provide these functions, the GPAD contains an entry for each GCKS that the IPsec entity is configured to contact. An entry contains one or more GCKS Identifiers, the authentication protocol (e.g., Group Domain of Interpretation (GDOI) or Group Secure Association Key Management Protocol (GSAKMP)), the authentication method used (e.g., certificates or pre-shared secrets), and the authentication data
これらの機能を提供するために、GPADはIPsec実体が連絡するために構成される各GCKSのためのエントリーを含んでいます。 エントリーは1GCKS Identifiers、認証プロトコル(例えば、Interpretation(GDOI)かGroup Secure Association Key Managementプロトコル(GSAKMP)のGroup Domain)、メソッドが使用した認証(例えば、証明書かプレ共有秘密キー)、および認証データを含んでいます。
Weis, et al. Standards Track [Page 12] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[12ページ]。
(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.
(例えば、プレ共有秘密キーか信頼アンカーに比例して同輩の証明書が有効にされる。) また、エントリーは、同輩の取消し状態について確かめるのを助けるために証明書ベースの認証のために例えば、Certificate Revocation List(CRL)倉庫への指針かOnline Certificate Statusプロトコル(OCSP)サーバの名前が同輩をどちらかに関連づけたか、または信頼アンカーが同輩と交際したのを情報を前提とするかもしれません。 また、エントリーはGroupメンバーがGKCSから受け取られた方針に適用する規制を含んでいます。
4.1.3.1. GCKS Identifiers
4.1.3.1. GCKS識別子
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 Identifiersは、このグループのためのGCKSとして機能するのが認可される1台以上のデバイスを特定するのに使用されます。 GCKS Identifiersは.1PADエントリーIDコネセクション4.4.3RFC4301として指定されて、そこに説明された合っている規則に従います。
4.1.3.2. GCKS Peer Authentication Data
4.1.3.2. GCKS同輩認証データ
Once a GPAD entry is located, it is necessary to verify the asserted identity, i.e., to authenticate the asserted GCKS Identifier. PAD authentication data types and semantics specified in Section 4.4.3.2 of RFC 4301 are used to authenticate a GCKS.
GPADエントリーがいったん見つけられていると、すなわち、断言されたGCKS Identifierを認証するために断言されたアイデンティティについて確かめるのが必要です。 PAD認証データ型と意味論は、GCKSを認証するためにセクション4.4.3で使用される.2RFC4301を指定しました。
See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM protocol performs peer authentication using certificates and pre-shared secrets.
GKMプロトコルが証明書とプレ共有秘密キーを使用することでどう同輩認証を実行するかに関する詳細に関してGDOI[RFC3547]とGSAKMP[RFC4535]を見てください。
4.1.3.3. Group Identifier Authorization Data
4.1.3.3. グループ識別子承認データ
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.
Group IdentifierはGKMプロトコルによって使用されて、特定のグループをGCKSに特定します。 GPADエントリーは、GPADエントリーにおけるGKCS IdentifiersがグループのためのGCKSとして機能するのが認可されるのを示すためにGroup Identifierを含んでいます。
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.
Group Identifierは安全なマルチキャストグループを特定するIKE IDタイプKey IDの不透明なバイトストリングです。 Group Identifierバイトストリングは、少なくとも4バイト長と256未満バイト長であるに違いありません。
IKE ID types other than Key ID MAY be supported.
Key ID以外のIKE IDタイプはサポートされるかもしれません。
4.1.3.4. IPsec SA Traffic Selector Authorization Data
4.1.3.4. IPsec SAトラフィックセレクタ承認データ
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
GCKSがいったん認証されると、GCKSはIPsec SA方針をGroupメンバーに提供します。 GroupメンバーがIPsec SA Policyを受け入れる前に、SAのソースと目的地トラフィックセレクタは1セットの認可されたデータフローにたとえられます。 認可されて、流れが認可されたソーストラフィックセレクタと1セットの1セットを含む各データ
Weis, et al. Standards Track [Page 13] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[13ページ]。
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.)
目的地トラフィックセレクタ。 1セットのIPv4、そして/または、IPv6アドレスが及ぶとき、トラフィックセレクタは表されます。 (同輩が両方のアドレスタイプのために権限を与えられるかもしれないので、v4とv6アドレスの範囲の両方への支給があるに違いありません。)
4.1.3.5. How the GPAD Is Used
4.1.3.5. GPADはどう使用されているか。
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プロトコル登録交換が引き起こされるとき、GroupメンバーとそれぞれGCKSは交換の一部として彼らのアイデンティティについて断言します。 それぞれのGKMプロトコル登録交換は、GPADでアイデンティティの場所を見つけるのに断言されたIDを使用しなければなりません。 GPADエントリーは特定されたGCKSに使われるべき認証方法を指定します。 また、エントリーは断言されたアイデンティティについて確かめるのに使用される認証データを指定します。 このデータはGCKSからどんなグループ方針も受け入れる前にGCKSを認証する指定されたメソッドに関連して使われます。
During the GKM protocol registration, a Group Member includes a Group Identifier. Before presenting that Group Identifier to the GCKS, a Group Member verifies that the GPAD entry for authenticated GCKS GPAD entry includes the Group Identifier. This ensures that the GCKS is authorized to provide policy for the Group.
GKMプロトコル登録の間、GroupメンバーはGroup Identifierを入れます。 そのGroup IdentifierをGCKSに寄贈する前に、Groupメンバーは、認証されたGCKS GPADエントリーのためのGPADエントリーがGroup Identifierを含んでいることを確かめます。 これは、GCKSが方針をGroupに供給するのが認可されるのを確実にします。
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エントリーでデータフローにたとえられます。 Groupメンバーはデータフローに合っている方針を受け入れます。 記録されたコネが監査ログであったなら捨てられたデータフロー、および理由SHOULDに合っていない方針。
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エントリーで方針をデータフローにたとえます。
4.2. Group Security Association (GSA)
4.2. グループセキュリティ協会(GSA)
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実装は多くのSecurity Associationsをサポートするでしょう: 1IPsec SAsと1GKM SAsが以前はよくIPsec SAsを作成するのに使用されるパラメタをダウンロードしていました。 これらのSAsはGroup Security Association(GSA)[RFC3740]とまとめて呼ばれます。
4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover
4.2.1. 同時発生のIPsec SA寿命と再主要なロールオーバー
During a secure multicast group's lifetime, multiple IPsec Group Security Associations can exist concurrently. This occurs principally due to two reasons:
安全なマルチキャストグループの生涯、複数のIPsec Group Security Associationsが同時に存在できます。 これは主に2つの理由のため起こります:
Weis, et al. Standards Track [Page 14] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[14ページ]。
- 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と共にグループで認可された複数のGroup Sendersがいます。 IPセキュリティ反再生サービスに依存しないグループはGroup Sendersのすべてのために1IPsec 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".
- Group Senderの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. 起動Time Delay(ATD)--ATDは、再主要なイベントの始まりのずっと後に新しいIPsec SAsを動かすためにその方法を定義します。 ATDパラメタはユニットの秒に言い表されます。 通常、それがかかる最大の時間にATDパラメタがGCKSからグループのメンバーのすべてまでマルチキャストメッセージを提供するように設定されます。 Reliable Multicast Transportプロトコル(RMTP)を当てにするGCKSに関しては、ATDパラメタはRTMPの最大のエラー回復時間と等しいセットであるかもしれません。 RMTPが存在していないとき、ATDパラメタはグループの終点のすべての向こう側にネットワークの最大のマルチキャストメッセージ配送潜在と等しいセットであるかもしれません。 ATDはGKMグループ方針パラメタです。 これはSHOULDを評価します。グループ基礎あたりのaでGroup Owner管理インタフェースで構成可能であってください。
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
2. 非活性化Time Delay(DTD)--DTDは、再主要なイベントの始まりのずっと後に再主要なイベントによって破壊されるそれらのIPsec SAsを非活性化するためにその方法を定義します。 DTDパラメタの目的は再主要なイベントが材料を合わせながらそれを引退させた後に材料を合わせるグループの残りの暴露を最小にすることです。 DTDが独立している、混乱しないようにIPsec SAの柔らかい生涯属性であるべきです。 DTDパラメタはユニットの秒に言い表されます。 通常、DTDパラメタはADTとわざわざそれがGroup Senderからグループのメンバーのすべてまでマルチキャストメッセージを提供する最大の設定されるでしょう。 RMTPを当てにするGroup Senderにおいて、DTDパラメタは設定されるかもしれません。
Weis, et al. Standards Track [Page 15] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[15ページ]。
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.
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によって送られたそれぞれのグループ再重要マルチキャストメッセージは新しいGroup Sender IPsec SA時間時代の始まりを示します、2IPsec 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を始めるGroup Senderへの先駆として、マルチキャストa Re-キーEvent(RKE)はグループへ通信します。 RKEマルチキャストはグループ方針指示、新しいIPsec SA方針、および材料を合わせるグループを含むかもしれません。 RMTPが不在のときGCKSはRKEを再送するかもしれません。再主要な情報の有用性を改良する方針で定義された数の回。 最後のRKE再トランスミッションを受けた後にGKMサブシステムはATDとDTDタイマを始動します。
- The GKM subsystem interprets the RKE multicast to configure the
group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that
replaces an existing SA is called a "leading edge" IPsec SA. The
leading edge IPsec SA has a new Security Parameter Index (SPI) and
its associated keying material, which keys it. For a time period
of ATD seconds after the GCKS multicasts the RKE, a Group Sender
does not yet transmit data using the leading edge IPsec SA.
Meanwhile, other Group Members prepare to use this IPsec SA by
installing the leading edge IPsec SAs to their respective GSPD/SAD.
- GKMサブシステムは、新しいIPsec SAsとグループのGSPD/SADを構成するためにRKEマルチキャストを解釈します。 既存のSAを取り替える各IPsec SAは「リーディングエッジ」IPsec SAと呼ばれます。 リーディングエッジIPsec SAは新しいSecurity Parameter Index(SPI)とその関連合わせることを物質的にして、どのキーがそれであるか。 RKE、Group SenderがそうしないGCKSマルチキャストの秒後のATDの期間、しかし、リーディングエッジIPsec SAを使用することでデータを送ってください。 その間、他のGroupメンバーは、彼らのそれぞれのGSPD/SADにリーディングエッジIPsec SAsをインストールすることによってこの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.
- Groupメンバーが皆、RKEメッセージを受け取って、処理したようにATDの期間、待った後に、GKMサブシステムは、新しい合わせることの材料によって暗号化されるデータと共にリーディングエッジIPsec SAを使用することで伝わり始めるようGroup Senderに指示します。 認可されたGroupメンバーだけがこれらのIPsec SAマルチキャスト送信を解読することができます。
Weis, et al. Standards Track [Page 16] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[16ページ]。
- 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.
- Group Senderの「トレーリングエッジ」SAはその送付者にとって、グループで使用中の最も古いSecurity Associationです。 すべての認可されたGroupメンバーが、このSAのためのデータを受け取って、解読することができますが、Group Senderは、リーディングエッジIPsec SAに移行した後にトレーリングエッジIPsec SAを使用することで新しいデータを送りません。 RKEトランスミッション以来DTDの期間が経過している後にトレーリングエッジIPsec SAはグループのGKMサブシステムで削除されます。
This re-key rollover strategy allows the group to drain its in-transit datagrams from the network while transitioning to the leading edge IPsec SA. Staggering the roles of each respective IPsec SA as described above improves the group's synchronization even when there are high network propagation delays. Note that due to group membership joins and leaves, each Group Sender IPsec SA time epoch may have a different group membership set.
この再主要なロールオーバー戦略で、グループはリーディングエッジIPsec SAに移行している間、ネットワークからトランジットにおけるデータグラムから水を抜くことができます。 高いネットワーク伝播遅延さえありさえするときさえ、それぞれのそれぞれのIPsec SAの役割を上で説明されるよろめかせると、グループの同期は改良されます。 会員資格が加わって、出るグループのため、それぞれのGroup Sender IPsec SA時間時代で異なったグループ会員資格を設定するかもしれないことに注意してください。
It is a group policy decision whether the re-key event transition between epochs provides forward and backward secrecy. The group's re-key protocol keying material and algorithm (e.g., Logical Key Hierarchy; refer to [RFC2627] and Appendix A of [RFC4535]) enforces this policy. Implementations MAY offer a Group Owner management interface option to enable/disable re-key rollover continuity for a particular group. This specification requires that a GKM/IPsec implementation MUST support at least two concurrent IPsec SAs per Group Sender as well as this re-key rollover continuity algorithm.
それは時代の間の再主要なイベント変遷が前進の、そして、後方の秘密保持を提供するかどうかというグループ政策決定です。 材料とアルゴリズムを合わせるグループの再主要なプロトコルがこの方針を実施します(例えば、Logical Key Hierarchy; [RFC4535]の[RFC2627]とAppendix Aを参照してください)。 実装は、特定のグループのために再主要なロールオーバーの連続を可能にするか、または無効にするためにGroup Owner管理インタフェースオプションを提供するかもしれません。 この仕様は、GKM/IPsec実装がこの再主要なロールオーバー連続アルゴリズムと同様に1Group Senderあたり少なくとも2同時発生のIPsec SAsをサポートしなければならないのを必要とします。
4.3. Data Origin Authentication
4.3. データ発生源認証
As defined in [RFC4301], data origin authentication is a security service that verifies the identity of the claimed source of data. A Message Authentication Code (MAC) is often used to achieve data origin authentication for connections shared between two parties. However, typical MAC authentication methods using a single shared secret are not sufficient to provide data origin authentication for groups with more than two parties. With a MAC algorithm, every Group Member can use the MAC key to create a valid MAC tag, whether or not they are the authentic originator of the group application's data.
[RFC4301]で定義されるように、データ発生源認証はデータの要求された源のアイデンティティについて確かめるセキュリティー・サービスです。 メッセージ立証コード(MAC)は2回のパーティーの間で共有された接続のためにデータ発生源認証を達成するのにおいてしばしば使用されています。 しかしながら、ただ一つの共有秘密キーを使用する典型的なMAC認証方法は、グループのためのデータ発生源認証に2回以上のパーティーを提供するために十分ではありません。 MACアルゴリズムで、すべてのGroupメンバーが有効な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つの可能なアルゴリズムが、Timed Efficient Stream Loss許容性があるAuthentication(テスラ)[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
いくつかの場合(例えばデジタル署名認証は変形する)、アルゴリズムの加工費はHashedメッセージ立証コード(HMAC)認証方法よりかなり大きいです。 to
Weis, et al. Standards Track [Page 17] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[17ページ]。
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.
グループ(IPsec SAがMAC認証アルゴリズムを使用している状態でこのアルゴリズムを使用するのがカプセル化されるかもしれないIPsec SA)に加わるのは認可されないデバイスからサービス不能攻撃から守ってください。 しかしながら、そうするのは、パケットがもう一度本国行きの処理のためのGroup Sender([RFC4301]のセクション5.1を見る)ともう一度の追加外国行きの処理のためにIPsec境界の向こう側にGroup Receiversに送られるのを必要とします([RFC4301]のセクション5.2を見てください)。 AHか超能力の中でカプセル化されたAHか超能力のこの使用はAHと超能力がただ一つの固有識別文字変換だけのために、Integrity Check Value(ICV)を定義するという規制を収容します。
4.4. Group SA and Key Management
4.4. グループSAとKey Management
4.4.1. Co-Existence of Multiple Key Management Protocols
4.4.1. 複数のKey Managementプロトコルの共存
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.
仲間かぎ管理がIKEv2[RFC4306]に議定書を作るとき、しばしば、GKMサブシステムは目下のIPsecサブシステムに取り入れられるでしょう。 基本的なGKMプロトコルIPセキュリティサブシステム要件はGKMプロトコルとIKEv2の両方が同時に一般的なGroup Security Policy DatabaseとSecurity Association Databaseへのアクセスを共有できるということです。 一般的なGSPD/SADデータ構造への互いに排他的なアクセスを提供するメカニズムは地域にかかわる事柄です。 これはGSPD-OキャッシュとGSPD-Iキャッシュを含んでいます。 しかしながら、implementersは、Group Security Associationsには、送付先マルチキャストIPアドレスによって資格があって、ソースIPアドレス資格を与える人が任意にいるかもしれなくて、IKEv2 SPI配分がGKM SPI配分によって完全に独立していることに注意するはずです。 詳細な説明に関して[RFC4303]のセクション2.1を見てください。
The Peer Authorization Database does require explicit coordination between the GKM protocol and IKEv2. Section 4.1.3 describes these interactions.
Peer Authorization DatabaseはGKMプロトコルとIKEv2の間の明白なコーディネートを必要とします。 セクション4.1 .3 これらの相互作用について説明します。
5. IP Traffic Processing
5. IPトラフィック処理
Processing of traffic follows Section 5 of [RFC4301], with the additions described below when these IP multicast extensions are supported.
トラフィックの処理はこれらのIPマルチキャスト拡大がサポートされるとき以下で説明された追加で[RFC4301]のセクション5に続きます。
5.1. Outbound IP Traffic Processing
5.1. 外国行きの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:
トンネルモードのためのヘッダー工事は.2セクション5.1RFC4301で説明されます。 そのセクションの最初の弾丸は以下の通り修正されます:
Weis, et al. Standards Track [Page 18] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[18ページ]。
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ヘッダーSource AddressかDestination AddressのどちらかのためにSADエントリーでマークされないなら、外側のIPのヘッダーSource AddressとDestination Addressはトンネル(encapsulatorとdecapsulator)の「終点」を特定します。 アドレス保存がIPヘッダーSource Addressのためにマークされるなら、それは内側のIPヘッダーSource Addressからコピーされます。 アドレス保存がIPヘッダーDestination Addressのためにマークされるなら、それは内側のIPヘッダーDestination Addressからコピーされます。 内側のIPのヘッダーSource AddressとDestination Addressesはそれぞれデータグラム(このトンネルの見解からの)の元の送り主と受取人を特定します。 要約のヘッダーの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)がセクション5.1.2で.1RFC4301を扱うというメモは以下の通り修正されます。 (注意: 簡潔さにおいて、RFC4301のNote(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) アドレス保存のためにマークされない場合、LocalとRemoteアドレスはSAによります。(SAは、Remoteアドレスを決定するのに使用されます)。(順番に、アドレスは、どのLocalアドレス(ネットのインタフェース)がパケットを進めるのに使用されるかを決定します)。 アドレス保存がLocalアドレスのためにマークされるなら、それは内側のIPヘッダーからコピーされます。 アドレス保存がRemoteアドレスのためにマークされるなら、そのアドレスは内側のIPヘッダーからコピーされます。
5.2. Inbound IP Traffic Processing
5.2. 本国行きの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.
RFC4301との互換性において、システム自体に属して、また、システム自体によって受け取られるマルチキャストパケットに属すユニキャスト送付先アドレスでパケットを意味するために「このデバイスに扱われた」句を取ります。 しかしながら、IPsecデバイスによって受け取られなかったマルチキャストパケットはこのデバイスに扱われると考えられません。
Weis, et al. Standards Track [Page 19] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[19ページ]。
The discussion of processing inbound IP Traffic described in Section 5.2 of RFC 4301 is amended as follows.
本国行きのIP TrafficがRFC4301のセクション5.2で説明した処理の議論は以下の通り修正されます。
The first dash in item 2 is amended as follows:
項目2における最初のダッシュは以下の通り修正されます:
- If the packet appears to be IPsec protected and it is
addressed to this device, or appears to be IPsec protected
and is addressed to a multicast group, an attempt is made to
map it to an active SA via the SAD. Note that the device may
have multiple IP addresses that may be used in the SAD
lookup, e.g., in the case of protocols such as SCTP.
- パケットが保護されたIPsecであるように見えて、IPsecであることが保護して、マルチキャストグループに扱われるようにこのデバイスに扱われるか、または見えるなら、SADを通してアクティブなSAにそれを写像するのを試みをします。 デバイスにはSADルックアップ、例えば、SCTPなどのプロトコルの場合に使用されるかもしれない複数の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:
新商品は目的地アドレス保存が適用されているIPsecパケットの処理について説明するために項目の3aと3bの間のリストに追加されます:
3aa. If the packet is addressed to a multicast group and AH or
ESP is specified as the protocol, the packet is looked up
in the SAD. Use the SPI plus the destination or SPI plus
destination and source addresses, as specified in Section
4.1. If there is no match, the packet is directed to
SPD-I lookup. Note that if the IPsec device is a security
gateway, and the SPD-I policy is to BYPASS the packet, a
subsequent security gateway along the routed path of the
multicast packet may decrypt the packet.
3aa。 パケットがマルチキャストグループに扱われて、AHか超能力がプロトコルとして指定されるなら、パケットはSADで調べられます。 セクション4.1で指定されるようにSPIと目的地かSPIと、目的地とソースアドレスを使用してください。 マッチが全くなければ、パケットはSPD-Iルックアップに向けられます。 マルチキャストパケットの発送された経路に沿ったその後のセキュリティゲートウェイがIPsecデバイスがセキュリティゲートウェイであり、SPD-I方針がBYPASSへのパケットであるなら、パケットを解読するかもしれないことに注意してください。
Figure 3 in RFC 4301 is updated to show the new processing path defined in item 3aa.
新しいプロセシング・パスが項目で3aaを定義したのを示すためにRFC4301の図3をアップデートします。
Weis, et al. Standards Track [Page 20] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[20ページ]。
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
保護のないインタフェース| +に対して-----+ IPsecは保護しました。------------------->|Demux|--------------------+ | +-----+ | | | | | IPsecでない| | | | IPsecは保護しました。| | デバイスに扱われたV| | +-------+ +---------+、悲しまないで。| | |破棄| <、-、--、|SPD-I(*)| <、-、-、-、-、-、-、-、-、-、-、--+ | | +-------+ +---------+ | | | | | | | |-----+ | | | | | | | | | V| | | | +------+ | | | | | ICMP| | | | | +------+ | | | | | +に対して---------+ | +-----------+ ....|SPD-O(*)|............|...................|(**)を処理してください。|...IPsec+---------+ | | (ああ、/、超能力) | 境界^| +-----------+ | | +---+ | | 迂回| +-->|イケ| | | | | +---+ | | V| V| +----------+ +---------+ +----+ |、-、-、-、-、-、-、--、<、-、-、-、-、--、|推進| <、-、-、-、-、-、-、-、--、|悲しいチェック| -->、|ICMP| 入れ子にされたSAs+----------+ | (***) | +----+ | +---------+ V保護されたインタフェース
Figure 1. Processing Model for Inbound Traffic
(amending Figure 3 of RFC 4301)
図1。 インバウンドトラフィックのための処理モデル(RFC4301の図3を修正します)
Weis, et al. Standards Track [Page 21] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[21ページ]。
The discussion of processing inbound IP traffic in Section 5.2 of RFC 4301 is amended to insert a new item 6 as follows.
RFC4301のセクション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ヘッダーのように同じ値になるように、外側のIPヘッダーの著しいアドレス(es)(すなわち、ソース、そして/または、送付先アドレス(es))について確かめなければなりません。 アドレスが一貫していないなら、IPsecシステムは、パケットを捨てて、監査可能イベントとして矛盾を扱わなければなりません。
6. Security Considerations
6. セキュリティ問題
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]に建てられます。 その結果、この仕様はRFC4301のセキュリティ問題の多くを引き継ぎます、そして、読者が仲間指導としてそれを見直すようにアドバイスされます。
6.1. Security Issues Solved by IPsec Multicast Extensions
6.1. IPsecマルチキャスト拡張子で解決された安全保障問題
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.
- デジタル署名、テスラ、または他のメカニズムを使用して、Senderデータ発生源認証を分類してください。
- Anti-replay protection for a limited number of Group Senders using
the ESP (or AH) sequence number facility.
- 超能力(または、AH)一連番号施設を使用しているGroup Sendersの限られた数のために反反復操作による保護である。
- 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).
- マルチキャスト送信のフィルタリングはGroup Sendersであることはグループ方針で認可されないシステムのソースアドレスを同一視しました。 この特徴は、IPsecの状態がないファイアウォールがサービス(すなわち、SPD-I、そして/または、パケット気質がDISCARDとして指定されているSDP-Oエントリー)であると利用します。
In support of the above services, this specification enhances the definition of the SPD, PAD, and SAD databases to facilitate the automated group key management of large-scale cryptographic groups.
上のサービスを支持して、この仕様は、大規模な暗号のグループの自動化されたグループ重要経営を容易にするためにSPD、PAD、およびSADデータベースの定義を機能アップします。
Weis, et al. Standards Track [Page 22] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[22ページ]。
6.2. Security Issues Not Solved by IPsec Multicast Extensions
6.2. IPsecマルチキャスト拡張子で解決されなかった安全保障問題
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.
RFC4301のセクション2.2に述べられるように、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つの広いカテゴリに分割されます: 部外者は攻撃します、そして、インサイダーは攻撃します。
6.2.1. Outsider Attacks
6.2.1. 部外者攻撃
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.
- 以前のマルチキャストパケット伝送のコピーを得て、次に、反再生サービスを可能にさせないグループにそれを再演しました。 aによって大規模な状態でそれに注意してください、いくらか、-、ソース、マルチキャストグループ、Group Receiversがあらゆる潜在的Group Senderのために反再生状態を維持するのは、非実用的です。 大規模な状態でaのための反反復操作による保護を必要とする方針を分類してください、いくらか、-、ソース、マルチキャストグループは再生を検出して、拒絶できる応用層マルチキャストプロトコルを考えるべきです。
6.2.2. Insider Attacks
6.2.2. インサイダー攻撃
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
大規模なグループのために、IPセキュリティマルチキャスト拡大は、正しく認証する自動化されたGroup Key Managementプロトコルに依存していて、承諾でグループの方針に信頼できるメンバーに権限を与えます。 暗号のグループの概念に固有であるのは、Groupメンバーのすべてに任せられた1つ以上の共有秘密キーのセットです。 その結果、サービスのセキュリティ保証は最も弱いメンバーがGKMシステムでグループに認めたほど強くはありません。 GKMシステムは再主要な手順を実行することによって感染しているGroupメンバー検出に応じるのに原因となります。 そしてGKM再の合わせるプロトコルが感染しているGroupメンバーを追放する。
Weis, et al. Standards Track [Page 23] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[23ページ]。
distribute new group keying material to the trusted members. Alternatively, the group policy may require the GKM system to terminate the group.
信じられたメンバーに材料を合わせる新しいグループを配布してください。 あるいはまた、グループ方針は、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.
- インサイダー敵は同輩Groupメンバーからあるように見えるパケット伝送を作り出すことができます。 オーバーヘッドに値するそれらのGroup Senderトランスミッションのためのこの攻撃に対して防御するために、グループ方針はデータ発生源認証サービスを使用することでマルチキャストパケットにGroup Senderを必要とすることができます。
- 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.
- グループのデータ発生源認証サービスがデジタル署名を使用するなら、インサイダー敵はマルチキャスティングのにせの署名しているパケットでコンピュータのリソースサービス不能攻撃に着手できます。
6.3. Implementation or Deployment Issues that Impact Security
6.3. 実装かDeployment IssuesがそのImpact Securityです。
6.3.1. Homogeneous Group Cryptographic Algorithm Capabilities
6.3.1. 同質的な集団暗号アルゴリズム能力
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]にまたがることができる合成群の展開です。 種々雑多なグループの標準液は今後の標準化のための活動です。 その間、安全でスケーラブルなソフトウェア配布管理ツールを使用することでグループの暗号の能力の同期を達成できるでしょう。
6.3.2. Groups that Span Two or More Security Policy Domains
6.3.2. グループのそのSpan TwoかMore Security Policy Domains
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マルチキャスト館外活動は1グループあたり1つのただ一つのグループ方針を必要とします。 上で述べたように、この問題は今後の標準化のための領域のままで残っています。
Weis, et al. Standards Track [Page 24] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[24ページ]。
6.3.3. Source-Specific Multicast Group Sender Transient Locators
6.3.3. ソース特有のマルチキャストグループ送付者一時的なロケータ
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.
Source Specific Multicast(SSM)グループSenderのソースIPアドレスは安全なマルチキャストグループの生涯ダイナミックに変化できます。 Group Senderのソースを引き起こす場合があるイベントに関する例が変化にインクルードを扱いますが、NAT、アドレスの注意、およびaにおける移動性の誘発された変化に制限されない、マルチ、家へ帰り、新しいIPインタフェースを使用しているホスト。 Group SenderのソースIPアドレスにおける変化によって、そのマルチキャストグループに関連するGSPDエントリーはグループのマルチキャストルーティング状態に関して時代遅れになるでしょう。 最悪の場合には、Group Senderのデータが新しいソースアドレスから発する場合セキュリティゲートウェイによって処理されたBYPASSになるリスクがあります。 このシナリオが予期されないなら、それはグループのデータを漏らすかもしれないでしょうに。 その結果、SSMの安全なマルチキャストグループにはIPがSSMグループの送付先IPアドレスのために演説するすべての権限のないGroup SenderソースへのデフォルトDISCARD方針があるのは、お勧めです。
7. Acknowledgements
7. 承認
The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, and Tero Kivinen for their helpful comments.
作者は彼らの役に立つコメントについてスティーブン・ケント、ラスHousley、パシEronen、およびTero Kivinenに感謝したがっています。
The "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] was consulted to develop the Security Considerations section of this memo.
「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」[RFC3552]は、このメモのSecurity Considerations部を発展させるように相談されました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
Weis, et al. Standards Track [Page 25] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[25ページ]。
8.2. Informative References
8.2. 有益な参照
[COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security
Composite Cryptographic Groups", Work in Progress, February
2007.
[COMPGRP] 「マルチキャストのIPのセキュリティの合成暗号のグループ」というグロスG.とH.クリュックシァンクは進歩、2007年2月に働いています。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[RFC2526] ジョンソンとD.とS.デアリング、「予約されたIPv6サブネットAnycastアドレス」、RFC2526、1999年3月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627] ウォルナー、D.、ハーダー、E.、およびR.エージー、「マルチキャストのための管理を合わせてください」 「問題とアーキテクチャ」、RFC2627、6月1999日
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[RFC3171] Albanna、Z.、Almeroth、K.、マイヤー、D.、およびM.シペール、「IPv4マルチキャストのためのIANAガイドラインは課題を扱います」、BCP51、RFC3171、2001年8月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3306] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3307] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S.、エド、「ソース特有のマルチキャスト(SSM)の概要」、RFC3569、7月2003日
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]ビーダ、R.、エド、L.コスタ、エド、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Protocol", RFC 3940, November 2004.
[RFC3940] アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ.Macker、「否定応答の(ナック)指向の信頼できるマルチキャスト(標準)プロトコル」、RFC3940、2004年11月。
Weis, et al. Standards Track [Page 26] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[26ページ]。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, April 2005.
[RFC4046] Baugher、M.、カネッティ、R.、Dondeti、L.、およびF.リンドホルム、「マルチキャストセキュリティ(msec)はKey Managementアーキテクチャを分類します」、RFC4046、2005年4月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4082] Perrig、A.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、「効率的な状態で調節されて、損失許容性がある認証(テスラ)を流してください」 「マルチキャストソース認証変換序論」、RFC4082、2005年6月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4359] ウィス、B.、「セキュリティが有効搭載量であるとカプセル化する中のRSA/SHA-1署名(超能力)と認証ヘッダー(ああ)の使用」、RFC4359(2006年1月)。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC
4535, June 2006.
[RFC4535] ハーニー、H.、メタンフェタミン、U.、コールグローブ、A.、およびG.グロス、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、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] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007.
[RFC4891]Graveman(R.、パルタサラティ、M.、Savola、P.、およびH.Tschofenig、「IPv4のIPv6にトンネルを固定するのにIPsecを使用する」RFC4891)は2007がそうするかもしれません。
[ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and
Reliable Group Rekeying", IEEE/ACM Transactions on
Networking (TON), Volume 11, Issue 6, December 2003.
[ZLLY03]チャン、X.、他は「スケーラブルで信頼できるグループRekeyingのためにデザインについて議定書の中で述べます」、Networking(TON)の上のIEEE/ACM Transactions、Volume11、Issue6、2003年12月。
Weis, et al. Standards Track [Page 27] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[27ページ]。
Appendix A. Multicast Application Service Models
付録A.マルチキャストアプリケーション・サービスモデル
The vast majority of secure multicast applications can be catalogued by their service model and accompanying intra-group communication patterns. Both the Group Key Management (GKM) subsystem and the IPsec subsystem MUST be able to configure the GSPD/SAD security policies to match these dominant usage scenarios. The GSPD/SAD policies MUST include the ability to configure both Any-Source Multicast groups and Source-Specific Multicast groups for each of these service models. The GKM subsystem management interface MAY include mechanisms to configure the security policies for service models not identified by this standard.
それらのサービスモデルと付随のイントラグループコミュニケーションパターンはかなりの大多数の安全なマルチキャストアプリケーションをカタログに載せることができます。 Group Key Management(GKM)サブシステムとIPsecサブシステムの両方が、これらの優位な用法シナリオを合わせるためにGSPD/SAD安全保障政策を構成できなければなりません。 GSPD/SAD方針はこれらのサービスモデル各人のためにAny-ソースMulticastグループとSource特有のMulticastグループの両方を構成する能力を含まなければなりません。 GKMサブシステム管理インタフェースは、この規格によって特定されなかったサービスモデルのために安全保障政策を構成するためにメカニズムを含むかもしれません。
A.1. Unidirectional Multicast Applications
A.1。 単方向のマルチキャストアプリケーション
Multimedia content-delivery multicast applications that do not have congestion notification or re-transmission error-recovery mechanisms are inherently unidirectional. RFC 4301 only defines bi-directional unicast traffic selectors (as per RFC 4301, Sections 4.4.1 and 5.1 with respect to traffic selector directionality). The GKM subsystem requires that the IPsec subsystem MUST support unidirectional SPD entries, which cause a Group Security Association (GSA) to be installed in only one direction. Multicast applications that have only one Group Member authorized to transmit can use this type of Group Security Association to enforce that group policy. In the inverse direction, the GSA does not have an SAD entry, and the GSPD configuration is optionally set up to discard unauthorized attempts to transmit unicast or multicast packets to the group.
本来混雑通知を持っていないマルチメディアコンテント配送マルチキャストアプリケーションか伝送エラーの再回収機構が単方向です。 RFC4301は双方向のユニキャストトラフィックセレクタ(セクション4.4 トラフィックセレクタの方向性に関するRFC4301、.1、および5.1に従って)を定義するだけです。 GKMサブシステムは、IPsecサブシステムが、単方向がSPDエントリーであるとサポートしなければならないのを必要とします。(エントリーはGroup Security Association(GSA)を一方向だけにインストールします)。 1人のGroupメンバーだけが伝わるのに権限を与えさせるマルチキャストアプリケーションは、そのグループ方針を実施するのにGroup Security Associationのこのタイプを使用できます。 逆さの方向には、GSAがSADエントリーを持っていません、そして、GSPD構成が、ユニキャストかマルチキャストパケットをグループに伝える権限のない試みを捨てるために任意にセットアップされます。
The GKM subsystem's management interface MUST have the ability to set up a GKM subsystem group having a unidirectional GSA security policy.
GKMサブシステムの管理インタフェースには、単方向のGSA安全保障政策を持っているGKMサブシステムグループを設立する能力がなければなりません。
A.2. Bi-Directional Reliable Multicast Applications
A.2。 双方向の高信頼のマルチキャストアプリケーション
Some secure multicast applications are characterized as one Group Sender to many receivers but have inverse data flows required by a reliable multicast transport protocol (e.g., NORM). In such applications, the data flow from the sender is multicast and the inverse flow from the Group's Receivers is unicast to the sender. Typically, the inverse data flows carry error repair requests and congestion control status.
いくつかの安全なマルチキャストアプリケーションで、多くの受信機への1Group Senderとして特徴付けられますが、信頼できるマルチキャストトランスポート・プロトコル(例えば、NORM)は逆さのデータフローを必要とします。 そのようなアプリケーションでは、送付者からのデータフローはマルチキャストです、そして、GroupのReceiversからの逆さの流れは送付者へのユニキャストです。 通常、逆さのデータフローは誤り修理要求と輻輳制御状態を運びます。
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
そのようなアプリケーションに、ユニキャストとマルチキャストデータフローの両方の保護に同じIPsec SAを使用するのは有利です。 これは1つの危険を導入します: IKEv2アプリケーションはGCKSがユニキャストトラフィックをカバーするグループIPsec SAに選ぶようにユニキャストトラフィックを受けるための同じSPIを選ぶかもしれません。 両方のSAsがSADにインストールされるなら、SAルックアップはSAルックアップの結果として間違ったSPIを返すかもしれません。 to
Weis, et al. Standards Track [Page 28] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[28ページ]。
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.
この問題を避けてください、そして、2が送付先IPアドレス、SPIをtupleするGKM SHOULD使用でインストールされたIPsec SAsは各IPsec SAを特定します。 さらに、GKM SHOULDは目的地のいずれもIPがIKEv2ユニキャストでIPsec SAを使用中に扱うマッチではなく、それがするユニキャスト送付先IPアドレスを使用します。 例えば、GroupメンバーがIKEv2とGKMプロトコルの両方を使用していると仮定してください。そうすれば、グループ安全保障政策は、上で説明されるようにNORMの逆さのデータフローを保護するのを必要とします。 この場合、グループ方針SHOULDはNORM Group Senderを表すユニークなユニキャスト送付先IPアドレスを、割り当てて、使用します。 このアドレスは平行でIPが扱うGroup Senderの存在に構成されるでしょう。 NORM Group SenderとGroup Receiver終点の両方のGKMサブシステムはIPsec SAをインストールするでしょう、NORMユニキャストメッセージを保護してSAルックアップはSPIと同様にユニキャスト送付先アドレスを使用します。
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 SHOULDは送付者のマルチキャストデータフローにIPsec反反復操作による保護サービスをグループのReceiversに利用します。 次のセクションで説明されたスケーラビリティ問題のために、ユニキャスト逆さの流れにIPsec反再生サービスを利用するのは実用的ではありません。 その結果、逆さの方向に、IPsec反反復操作による保護を無効にしなければなりません。 しかしながら、ユニキャストの逆さの流れはグループのIPsecグループ認証機構を使用できます。 このGSA SHOULDに関しては、Group ReceiverのGSPDエントリー、構成されて、全体のグループへのマルチキャスト送信よりむしろ送付者ノードにユニキャスト送信を許すだけであってください。
If an ESP digital signature authentication is available (e.g., RFC 4359), source authentication MAY be used to authenticate a receiver node's transmission to the sender. The GKM protocol MUST define a key management mechanism for the Group Sender to validate the asserted signature public key of any receiver node without requiring that the sender maintain state about every Group Receiver.
超能力デジタル署名認証が利用可能であるなら(例えば、RFC4359)、ソース認証は、受信機ノードのトランスミッションを送付者に認証するのに使用されるかもしれません。 送付者があらゆるGroup Receiverに関して状態を維持する必要でないGroup Senderがどんな受信機ノードの断言された署名公開鍵も有効にするように、GKMプロトコルはかぎ管理メカニズムを定義しなければなりません。
This multicast application service model is RECOMMENDED because it includes congestion control feedback capabilities. Refer to [RFC2914] for additional background information.
輻輳制御フィードバック能力を含んでいるので、このマルチキャストアプリケーション・サービスモデルはRECOMMENDEDです。 追加基礎的な情報について[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サブシステムのGroup Owner管理インタフェースには、左右対称のGSPDエントリーと1Group Senderをセットアップする能力がなければなりません。 経営者側はSHOULDを連結します。グループを構成できて、少なくとも16人の同時発生の認可された送付者をいてください、それぞれそれら自身のGSA反再生状態と共に。
Weis, et al. Standards Track [Page 29] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[29ページ]。
A.3. Any-To-Many Multicast Applications
A.3。 マルチキャストの多くへのいずれもアプリケーション
Another family of secure multicast applications exhibits an "any-to- many" communications pattern. A representative example of such an application is a videoconference combined with an electronic whiteboard.
安全なマルチキャストアプリケーションのもう1家族が展示会に出品する、「いくらか、-、-、」 コミュニケーションが型に基づいて作る多く。 そのようなアプリケーションの代表している例は電子ホワイトボードに結合されたビデオ会議です。
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.
そのようなアプリケーションのために、Groupメンバー(または、大きい部分集合)は皆、認可されたマルチキャスト送付者です。 そのようなサービスモデルでは、すべての潜在的送付者のために反再生状態がある異なったIPsec SAを作成するのは大きいグループに比例しません。 グループSHOULDは送付者のすべてのために1IPsec SAを共有します。 IPsec SA SHOULDは送付者のマルチキャストデータフローにIPsec反反復操作による保護サービスをGroup Receiversに利用しません。
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サブシステムの管理インタフェースには、結団する多くへのAny Multicast GSA安全保障政策を持っている能力がなければなりません。
Appendix B. ASN.1 for a GSPD Entry
GSPDエントリーへの付録B.ASN.1
This appendix describes an additional way to describe GSPD entries, as defined in Section 4.1.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The GSPD description in Section 4.1.1 is normative. As shown in Section 4.1.1, the GSPD updates the SPD and thus this appendix updates the SPD object identifier.
この付録はセクション4.1.1で定義されるようにGSPDエントリーについて説明する追加方法を述べます。 それは首尾よくコンパイルされたASN.1構文を使用します。 この構文は、単に説明に役立って、コンプライアンスを達成するのに実現で使われる必要はありません。 セクション4.1.1におけるGSPD記述は規範的です。 セクション4.1.1で示されるように、GSPDはSPDをアップデートします、そして、その結果、この付録はSPD物の識別子をアップデートします。
B.1. Fields Specific to a GSPD Entry
B.1。 GSPDエントリーに特定の分野
The following fields summarize the fields of the GSPD that are not present in the SPD.
以下の分野はSPDに存在していないGSPDの分野をまとめます。
- direction (in IPsecEntry) - DirectionFlags - noswap (in SelectorList) - ap-l, ap-r (in TunnelOptions)
- 指示(IPsecEntryの)--DirectionFlags--noswap(SelectorListの)--ap-l、ap-r(TunnelOptionsの)
Weis, et al. Standards Track [Page 30] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[30ページ]。
B.2. SPDModule
B.2。 SPDModule
SPDModule
SPDModule
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
ipsec (8) asn1-modules (3) spd-module (1) }
iso(1) org(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ipsec(8)asn1-モジュール(3)spd-モジュール(1)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
IMPORTS RDNSequence FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
-- SPDによる減少における方針のリストが好みのSPDについて以下を注文するということです:= SPDEntryの系列
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
SPDEntry:、:= CHOICE、iPsecEntry IPsecEntry、--、PROTECTが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"
}
IPsecEntry:、:= 系列--各エントリーは名前NameSets OPTIONALから成ります、pFPs PacketFlags--、居住、パケットは弛みます--対応のすべて--SelectorLists指示DirectionFlagsへの交通セレクタ--SAの方向性状態SelectorLists--方針「状態」処理Processing--方針「動作」に適用します。
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
BypassOrDiscardEntry:、:= 系列迂回ブール、--TRUE BYPASS、FALSE DISCARDがInOutBoundを条件とさせる
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
InOutBound:、:= 選択外国行きの[0]SelectorLists、本国行きの[1]SelectorLists、bothways[2]BothWays
Weis, et al. Standards Track [Page 31] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[31ページ]。
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
BothWays:、:= 系列本国行きのSelectorLists、外国行きのSelectorLists
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
NameSets:、:= SEQUENCEは応答者地方のSET OF Names-IをSET OF Names-R(IKE IDに合わせられている)に通過しました--IKEで、内用します--、創始者
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
名前R:、:= CHOICE--IKEv2ID 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
名前I:、:= OCTET STRING(IKEによって内部的に使用される)、創始者
FQDN ::= IA5String
FQDN:、:= IA5String
RFC822Name ::= 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) }
PacketFlags:、:= ビット列--設定されるなら、SPDエントリーlocalAddr(0)でパケット--SAを設立します--ほかの使用価値からセレクタ値を取ってください、remoteAddr(1)、プロトコル(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) }
DirectionFlags:、:= ビット列--設定されるなら、SAを指定にインストールしてください--指示左右対称の方針はそうです--両方のビット本国行きの(0)、外国行きの(1)を設定しながら表す
SelectorLists ::= SET OF SelectorList
SelectorLists:、:= SelectorListのセット
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice,
noswap BOOLEAN } -- Do not swap local and remote
-- addresses and ports on incoming
SelectorList:、:= SEQUENCE、localAddr AddrList(remoteAddr AddrList)はProtocolChoiceについて議定書の中で述べます、noswapブールです--地方であってリモートな状態で、スワップしないでください--、入来でのアドレスとポート
Weis, et al. Standards Track [Page 32] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[32ページ]。
-- 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
以下を処理します:= extSeqNumのブール(TRUE64の噛み付いているカウンタ、seqOverflowブールであることで噛み付かれたFALSE32)のTRUE rekey、FALSEが終えて、監査fragCheck--TRUE stateful断片の照合--ブールFALSEノーstatefulが生涯SALifetime、spi ManualSPI、アルゴリズムProcessingAlgs、トンネルTunnelOptions OPTIONALをチェックしながら断片化するSEQUENCE--使用--休むなら、モードを輸送してください。
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
SALifetime:、:= 系列秒[0]INTEGER OPTIONAL、バイト[1]INTEGER OPTIONAL
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
ManualSPI:、:= 系列spi INTEGER、キーKeyIDs
KeyIDs ::= SEQUENCE OF OCTET STRING
KeyIDs:、:= 八重奏ストリングの系列
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ProcessingAlgs:、:= CHOICE、{[0] ああ、IntegrityAlgs--AH esp[1]ESPAlgs}--、超能力
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
ESPAlgs:、:= 選択保全[0]IntegrityAlgs--保全秘密性[1]ConfidentialityAlgsだけ--両方だけの[2]IntegrityConfidentialityAlgsであって、結合した秘密性、[3] CombinedModeAlgs
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
IntegrityConfidentialityAlgs:、:= 系列保全IntegrityAlgs、秘密性ConfidentialityAlgs
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- 減少している好みのIntegrityAlgsによって注文された保全Algorithms:、:= IntegrityAlgの系列
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- 減少している好みのConfidentialityAlgsによって注文された秘密性Algorithms:、:= ConfidentialityAlgの系列
Weis, et al. Standards Track [Page 33] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[33ページ]。
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- 保全アルゴリズムIntegrityAlg:、:= 系列いずれ--DEFINED BYアルゴリズム--アルゴリズムIntegrityAlgType、パラメタ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)
}
IntegrityAlgType:、:= 整数なにも、(0)、auth-HMAC-MD5-96(1)、auth-HMAC-SHA1-96(2)、auth-DES-MAC(3)、auth-KPDK-MD5(4)、tbdな(6 .65535)auth-AES-XCBC-96(5)
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- 秘密性アルゴリズムConfidentialityAlg:、:= 系列いずれ--DEFINED BYアルゴリズム--アルゴリズムConfidentialityAlgType、パラメタ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)
}
ConfidentialityAlgType:、:= 整数encr-DES-IV64(1)、tbdな(14 .65535)encr-DES(2)、encr-3DES(3)、encr-RC5(4)、encr-IDEA(5)、encr-キャスト(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)
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlgs:、:= CombinedModeAlgの系列
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm -- }
-- defined outside
-- of this document for AES modes.
CombinedModeAlg:、:= SEQUENCE、アルゴリズムCombinedModeType、パラメタ、いずれ(DEFINED BYアルゴリズム)、も--外では、AESモードのためのこのドキュメントについて定義されます。
Weis, et al. Standards Track [Page 34] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[34ページ]。
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
CombinedModeType:、:= 整数くし-AES-CCM(1)、tbdな(3 .65535)くし-AES-GCM(2)
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 }
TunnelOptions:、:= 系列{dscp DSCP、ecnのブール(外側への内側のヘッダーap-lブール(TRUE Copyの内側のIPヘッダー)のソースアドレスへのTRUE Copy CE)のIPヘッダーソースはブールでap-rを記述します--TRUE Copyの内側のIPヘッダー--外側への送付先アドレス--IPヘッダー送付先アドレスdf DF、アドレスTunnelAddresses}
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
TunnelAddresses:、:= 選択ipv4 IPv4Pair、ipv6[0]IPv6Pair
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv4Pair:、:= 系列地方のOCTET STRING、(SIZE(4))、リモートOCTET STRING、(SIZE(4))
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
IPv6Pair:、:= 系列地方のOCTET STRING、(SIZE(16))、リモート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
DSCP:、:= コピーのブール(内側のヘッダーからのTRUEコピー)のFALSEがOCTET STRING OPTIONALを写像しながらコピーしないSEQUENCE(見送るポイント)はいいえならコピーします。
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
DF:、:= 整数明確な(0)、セット(1)は(2)をコピーします。
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
ProtocolChoice:、:= CHOICE、どんなプロトコルnoNext[0]NoNextLayerProtocolのためのanyProt AnyProtocolでも、いいえが次の1つが次の層(項目oneNext[1]OneNextLayerProtocol)によるレイヤであるあります--、項目
Weis, et al. Standards Track [Page 35] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[35ページ]。
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
twoNext[2]TwoNextLayerProtocol--次の2層を持っています--、項目はFragmentNoNextを断片化します。 -- すぎ次に、層--インフォメーションを持っています。
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyProtocol:、:= 系列イドINTEGER(0)--少しもnextLayer AnyNextLayersについて議定書の中で述べてください。
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
AnyNextLayers:、:= SEQUENCE、どんな次の--どちらかによる最初のAnyNextLayer--層セレクタもAnyNextLayerを後援します--セレクタは次に少しも層にされます。
NoNextLayerProtocol ::= INTEGER (2..254)
NoNextLayerProtocol:、:= 整数(2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
FragmentNoNext:、:= INTEGER(44)--断片識別子
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
OneNextLayerProtocol:、:= SEQUENCE、イドINTEGER(1 .254)--ICMP、MH、ICMPv6 nextLayer NextLayerChoice、--ICMP Type*256+コード--MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
TwoNextLayerProtocol:、:= SEQUENCE、イドINTEGER(2 .254)--プロトコルの地方のNextLayerChoice--地方の、そして、リモートなNextLayerChoice--、遠く離れたポート
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
NextLayerChoice:、:= 選択どんなAnyNextLayer、不透明なもの[0]OpaqueNextLayer、範囲[1]NextLayerRange
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- 次の層の分野AnyNextLayerのいずれの表現:、:= 系列終わりのINTEGER(65535)、INTEGER(0)を始動してください。
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- 次の層の分野でのOPAQUEの表現。 -- マッチIKEコンベンションOpaqueNextLayer:、:= 系列終わりのINTEGER(0)、INTEGER(65535)を始動してください。
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- 次の層の分野NextLayerRangeには、及んでください:、:= 系列INTEGER(0 .65535)、終わりのINTEGER(0 .65535)を始動してください。
Weis, et al. Standards Track [Page 36] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[36ページ]。
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPアドレスAddrListについて以下を記載してください:= 系列v4List IPv4List任意であって、v6List[0]IPv6List任意です。
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
-- IPv4は表現IPv4Listを記述します:、:= IPv4Rangeの系列
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
IPv4Range:、:= 系列--、かなり右の…ipv4Start OCTET STRINGが閉じてくださいが、閉じない(SIZE(4))、ipv4End OCTET STRING、(SIZE(4))
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
-- IPv6は表現IPv6Listを記述します:、:= IPv6Rangeの系列
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
IPv6Range:、:= 系列--、かなり右の…ipv6Start OCTET STRINGが閉じてくださいが、閉じない(SIZE(16))、ipv6End OCTET STRING、(SIZE(16))
END
終わり
Weis, et al. Standards Track [Page 37] RFC 5374 Multicast Extensions to RFC 4301 November 2008
ウィス、他 規格は2008年11月にRFC5374マルチキャスト拡張子をRFC4301に追跡します[37ページ]。
Authors' Addresses
作者のアドレス
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706 USA
ブライアンウィスシスコシステムズ170w.タスマンDrive、サンノゼ、カリフォルニア95134-1706米国
Phone: +1-408-526-4796 EMail: bew@cisco.com
以下に電話をしてください。 +1-408-526-4796 メールしてください: bew@cisco.com
George Gross Secure Multicast Networks LLC 977 Bates Road Shoreham, VT 05770 USA
ジョージ総計の安全なマルチキャストネットワークLLC977ベイツ道路Shoreham、バーモント05770米国
Phone: +1-802-897-5339 EMail: gmgross@securemulticast.net
以下に電話をしてください。 +1-802-897-5339 メールしてください: gmgross@securemulticast.net
Dragan Ignjatic Polycom Suite 200 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
ドラガンIgnjatic Polycom Suite200 3605ギルモアWay、バーナビー、紀元前のV5G4X5カナダ
Phone: +1-604-453-9424 EMail: dignjatic@polycom.com
以下に電話をしてください。 +1-604-453-9424 メールしてください: dignjatic@polycom.com
Weis, et al. Standards Track [Page 38]
ウィス、他 標準化過程[38ページ]
一覧
スポンサーリンク
