[要約] RFC 2588は、IPマルチキャストとファイアウォールに関するガイドラインを提供するものであり、マルチキャストトラフィックのセキュリティ上の課題と対策に焦点を当てています。その目的は、ネットワーク管理者がファイアウォールを適切に設定し、マルチキャストトラフィックのセキュリティを確保するための指針を提供することです。
Network Working Group R. Finlayson
Request for Comments: 2588 LIVE.COM
Category: Informational May 1999
IP Multicast and Firewalls
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal 'intranet'. In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast.
多くの組織では、公共のインターネットとそのプライベート、内部の「イントラネット」の間のセキュリティゲートウェイとして機能するファイアウォールのコンピュータを使用しています。この文書では、我々は、ファイアウォールを越えてIPマルチキャストトラフィックの横断を取り巻く問題を議論し、ファイアウォールは、このトラバーサルを実装し、制御することができている可能性のある方法を説明します。このようSOCKSなど - - ユニキャストトラフィックのために特別に設計された、マルチキャストにはあまり適切であるいくつかのファイアウォールのメカニズムは、なぜ我々も説明します。
A firewall is a security gateway that controls access between a private adminstrative domain (an 'intranet') and the public Internet. This document discusses how a firewall handles IP multicast [1] traffic.
ファイアウォールは、プライベートの管理用ドメイン（「イントラネット」）と公共のインターネット間のアクセスを制御するセキュリティゲートウェイです。この文書では、ファイアウォールはIPマルチキャスト[1]トラフィックを処理する方法について説明します。
We assume that the external side of the firewall (on the Internet) has access to IP multicast - i.e., is on the public "Multicast Internet" (aka. "MBone"), or perhaps some other multicast network.
、すなわち公共の「マルチキャストインターネット」（別名「あるMBone」。）、または、おそらく他のいくつかのマルチキャストネットワーク上にある - 私たちは、（インターネット上の）ファイアウォールの外部側はIPマルチキャストへのアクセス権を持っていることを前提としています。
We also assume that the *internal* network (i.e., intranet) supports IP multicast routing. This is practical, because intranets tend to be centrally administered. (Also, many corporate intranets already use multicast internally - for training, meetings, or corporate announcements.) In contrast, some previously proposed firewall mechanisms for multicast (e.g., [2]) have worked by sending *unicast* packets within the intranet. Such mechanisms are usually inappropriate, because they scale poorly and can cause excessive network traffic within the intranet. Instead, it is better to rely upon the existing IP multicast routing/delivery mechanism, rather than trying to replace it with unicast.
また、*内部*ネットワーク（すなわち、イントラネット）は、IPマルチキャストルーティングをサポートしていることを前提としています。イントラネットは、集中管理される傾向があるので、これは、実用的です。 （また、多くの企業のイントラネットが既に内部でマルチキャストを使用 - 。研修、会合、または企業アナウンスなど）は対照的に、マルチキャストのためのいくつかの以前に提案されたファイアウォールのメカニズム（例えば、[2]）イントラネット内*ユニキャスト・パケットを送信してきました。彼らは不十分なスケールとイントラネット内の過剰なネットワークトラフィックを引き起こす可能性があるので、このようなメカニズムは、通常は不適切です。代わりに、むしろ、ユニキャストと交換しようとするよりも、既存のIPマルチキャストルーティング/配信メカニズムに依拠することをお勧めします。
This document addresses scenarios where a multicast session is carried - via multicast - on both sides of the firewall. For instance, (i) a particular public MBone session may be relayed onto the intranet (e.g., for the benefit of employees), or (ii) a special internal communication (e.g., announcing a new product) may be relayed onto the public MBone. In contrast, we do not address the case of a roaming user - outside the firewall - who wishes to access a private internal multicast session, using a virtual private network. (Such "road warrior" scenarios are outside the scope of this document.)
マルチキャスト経由 - - ファイアウォールの両側にこの文書では、マルチキャストセッションが行われているシナリオに対応しています。例えば、（ⅰ）特定公共あるMBoneセッションが（例えば、新製品の発表は）公共のあるMBone上に中継することができる、または（ⅱ）特別な内部通信（従業員の利益のために、例えば）、イントラネット上に中継することができます。これとは対照的に、我々は、ローミングユーザの場合に対応していない - ファイアウォールの外側 - プライベート内部マルチキャストセッションにアクセスしたい、仮想プライベートネットワークを使用しました。 （例えば、「道路戦士」シナリオは、この文書の範囲外です。）
As noted by Freed and Carosso [3], a firewall can act in two different ways:
フリードとCarossoによって示されるように、[3]、ファイアウォールは2つの異なる方法で作用することができます。
1/ As a "protocol end point". In this case, no internal node (other than the firewall) is directly accessible from the external Internet, and no external node (other than the firewall) is directly accessible from within the intranet. Such firewalls are also known as "application-level gateways". 2/ As a "packet filter". In this case, internal and external nodes are visible to each other at the IP level, but the firewall filters out (i.e., blocks passage of) certain packets, based on their header or contents.
1 /「プロトコルエンドポイント」として。この場合には、（ファイアウォールを除く）は内部ノードが外部のインターネットから直接アクセスせず、（ファイアウォール以外の）外部ノードがイントラネット内から直接アクセスされません。このようなファイアウォールは、「アプリケーションレベルゲートウェイ」として知られています。 2 /「パケットフィルタ」として。この場合には、内部および外部のノードはIPレベルで相互に可視であるが、ファイアウォールは、それらのヘッダまたは内容に基づいて、（すなわち、ブロックの通路）特定のパケットをフィルタリングします。
In the remainder of this document, we assume the first type of firewall, as it is the most restrictive, and generally provides the most security. For multicast, this means that:
それは最も制限され、一般的にほとんどのセキュリティを提供し、この文書の残りの部分では、我々は、ファイアウォールの最初のタイプを想定しています。マルチキャストの場合、これはそれを意味します。
(i) A multicast packet that's sent over the Internet will never be seen on the intranet (and vice versa), unless such packets are explicitly relayed by the firewall, and (ii) The IP source address of a relayed multicast packet will be that of the firewall, not that of the packet's original sender. To work correctly, the applications and protocols being used must take this into account. (Fortunately, most modern multicast-based protocols - for instance, RTP [4] - are designed with such relaying in mind.)
このようなパケットが明示的にファイアウォールによって中継されない限り、（I）は、インターネット経由で送信されますマルチキャストパケットは、イントラネット（またはその逆）で見られることはありません、および（ii）中継マルチキャストパケットのIP送信元アドレスは、ということになりますファイアウォールのではなく、パケットの元の送信者のこと。正しく動作するには、使用中のアプリケーションおよびプロトコルは、これを考慮に入れなければなりません。 （幸いなことに、ほとんどの近代的なマルチキャストベースのプロトコル - 例えば、RTP [4] - 念頭に置いて、このような中継を用いて設計されています。）
When considering the security implications of IP multicast, it is important to note the fundamental way in which multicast communication differs from unicast.
IPマルチキャストのセキュリティへの影響を考えるとき、マルチキャスト通信はユニキャストと異なっている基本的な方法を注意することが重要です。
Unicast communication consists of a 'conversation' between an explicit pair of participants. It therefore makes sense for the security of unicast communication to be based upon these participants (e.g., by authenticating each participant). Furthermore, 'trust' within unicast communication can be based upon trust in each participant, as well as upon trust in the data.
ユニキャスト通信は、参加者の明示的なペア間の「会話」で構成されています。したがって、これらの参加者（例えば、各参加者を認証することによって）に基づいてされるユニキャスト通信のセキュリティのために理にかなっています。また、ユニキャスト通信中の「信頼」は各参加者に、ならびにデータの信頼時に信頼に基づくことができます。
Multicast communication, on the other hand, involves a arbitrary sized, potentially varying set of participants, whose membership might never be fully known. (This is a feature, not a bug!) Because of this, the security of multicast communication is based not upon its participants, but instead, upon its *data*. In particular, multicast communication is authenticated by authenticating packet data - e.g., using digital signatures - and privacy is obtained by encrypting this data. And 'trust' within multicast communication is based solely upon trust in the data.
マルチキャスト通信は、他の一方で、その会員十分に知られることはありませんかもしれない参加者の任意のサイズの、潜在的に様々なセットを伴います。 （これは機能ではなく、バグです！）このため、マルチキャスト通信のセキュリティはありませんその参加時に、代わりに、*その*データに基づいています。例えば、デジタル署名を使用して、 - - 特に、マルチキャスト通信は、パケットデータを認証によって認証され、プライバシーは、このデータを暗号化することによって得られます。そして、マルチキャスト通信中の信頼は「単にデータの信頼に基づいています。
The primary threat arising from relaying multicast across a firewall is therefore "bad data" - in particular:
ファイアウォールを介してマルチキャスト中継に起因する主要な脅威は、したがって「不良データ」である - 特に：
(i) damaging data flowing from the Internet onto the intranet, or (ii) sensitive data inadvertently flowing from the intranet onto the external Internet.
（I）損傷のデータは、イントラネット上にインターネットから流れる、または（ii）の機密データが誤って外部のインターネット上イントラネットから流れます。
To avert this threat, the intranet's security administrator must establish, in advance, a security policy that decides:
この脅威を回避するには、イントラネットのセキュリティ管理者は、事前に、決定したセキュリティポリシーを確立する必要があります。
(i) Which multicast groups (and corresponding UDP ports) contain data that can safely be relayed from the Internet onto the intranet. For example, the security administrator might choose to permit the relaying of an MBone lecture, knowing that the data consists only of audio/video (& to safe ports). (ii) Which multicast groups (and corresponding UDP ports) will not contain sensitive internal information (that should therefore not be relayed from the intranet onto the Internet). This, of course, requires placing trust in the applications that internal users will use to participate in these groups. For example, if users use an audio/video 'viewer' program to participate in an MBone session, then this program must be trusted not to be a "Trojan Horse". (This requirement for "trusted applications" is by no means specific to multicast, of course.)
（I）のマルチキャストグループ（および対応するUDPポート）が安全にイントラネット上でインターネットから中継できるデータが含まれています。たとえば、セキュリティ管理者は、データのみをオーディオ/ビデオ（＆安全なポートへの）で構成されていることを知って、あるMBone講演の中継を許可することを選択するかもしれません。 （ii）のマルチキャストグループ（および対応するUDPポート）敏感な内部情報（つまり、従って、インターネット上イントラネットから中継されるべきではない）が含まれませんどの。これは、当然のことながら、内部ユーザーがこれらのグループに参加するために使用するアプリケーションに信頼を置くことが必要です。ユーザーがあるMBoneセッションに参加するために、オーディオ/ビデオ「視聴者のプログラムを使用した場合、このプログラムは、「トロイの木馬」ではないと信頼されている必要があります。 （「信頼するアプリケーション」のためのこの要件はもちろん、マルチキャストに特定されるものではありません。）
Once such a security policy has been established, it is then the job of the firewall to implement this policy.
このようなセキュリティポリシーが確立されると、このポリシーを実装するためのファイアウォールの仕事です。
In short, a firewall must do three things in order to handle multicast:
要するに、ファイアウォールはマルチキャストを処理するために3つのことを行う必要があります。
1/ Support the chosen multicast security policy (which establishes particular multicast groups as being candidates to be relayed), 2/ Determine (dynamically) when each candidate group should be relayed, and 3/ Relay each candidate group's data across the firewall (and then re-multicast it at the far end).
1 /（ある候補が中継されるように、特定のマルチキャストグループを確立する）選択されたマルチキャストセキュリティポリシーをサポートし、2 /（動的）を決定し、各候補グループは中継され、3 /ファイアウォールを越え各候補グループのデータを中継しなければならない場合（そして再マルチキャスト遠端のそれ）。
These three tasks are described in more detail in the next three sections.
これらの3つのタスクは、次の3つのセクションで詳しく説明されています。
Note that because a firewall is often a convenient place to centralize the administration of the intranet, some firewalls might also perform additional administrative functions - for example, auditing, accounting, and resource monitoring. These additional functions, however, are outside the scope of this document, because they are not specifically *firewall*-related. They are equally applicable to an administrative domain that is not firewalled.
ファイアウォールは、多くの場合、イントラネットの管理を集中するのに便利な場所であるため、一部のファイアウォールは、追加の管理機能を実行する可能性があることに注意してください - 例えば、監査、会計、およびリソース監視。彼らが具体的に*ファイアウォールは* - 関連していないため、これらの追加機能は、しかし、この文書の範囲外です。彼らは、ファイアウォールではありません管理ドメインにも同様に適用可能です。
As noted above, a multicast security policy consists of specifying the set of allowed multicast groups (& corresponding UDP ports) that are candidates to be relayed across the firewall. There are three basic ways in which a firewall can support such a policy:
上述したように、マルチキャストセキュリティポリシーは、ファイアウォールを越えて中継する候補であるせマルチキャストグループ（および対応するUDPポート）のセットを指定から成ります。ファイアウォールは、このようなポリシーをサポートすることが可能な3つの基本的な方法があります。
1/ Static configuration. The firewall could be configured, in advance, with the set of candidate groups/ports - for example, in a configuration file. 2/ Explicit dynamic configuration. The set of candidate groups/ports could be set (and updated) dynamically, based upon an explicit request from one or more trusted clients (presumably internal). For example, the firewall could contain a 'remote control' mechanism that allows these trusted clients - upon authentication - to update the set of candidate groups/ports. 3/ Implicit dynamic configuration. The set of candidate groups/ports could be determined implicitly, based upon the contents of some pre-authorized multicast group/port, such as a "session directory". Suppose, for example, that the security policy decides that the default MBone SAP/SDP session directory [5] may be relayed, as well as any sessions that are announced in this directory. A 'watcher' process, associated with the firewall, would watch this directory, and use its contents to dynamically update the set of candidates.
1 /静的構成。例えば、構成ファイル内 - ファイアウォールは、候補グループ/ポートのセットと、事前に構成することができます。 2 /明示的な動的構成。候補グループ/ポートのセットは、1つまたは複数の信頼できるクライアント（おそらくは内蔵）から明示的な要求に基づいて、動的に設定（および更新）することができます。認証時 - - 例えば、ファイアウォールは、これらの信頼できるクライアントを可能にする「リモートコントロール」メカニズムが含まれている可能性が候補グループ/ポートのセットを更新します。 3 /暗黙的な動的構成。候補グループ/ポートのセットは、「セッションディレクトリ」として、いくつかの事前許可マルチキャストグループ/ポートの内容に基づいて、暗黙的に決定することができます。セキュリティポリシーは、[5]デフォルトのMBone SAP / SDPセッションディレクトリは、このディレクトリに発表されているすべてのセッションだけでなく、中継されることを決定したことを、例えば、と仮定します。ファイアウォールに関連した「ウォッチャー」プロセスは、このディレクトリを見て、動的に候補の集合を更新するために、その内容を使用します。
Notes:
ノート：
(i) Certain ranges of multicast addresses are defined to be "administratively scoped" [6]. Even though the firewall does not act as a true multicast router, the multicast security policy should set up and respect administrative scope boundaries. (ii) As noted in [2], certain privileged UDP ports may be considered dangerous, even with multicast. The multicast security policy should check that such ports do not become candidates for relaying. (iii) Even if sessions announced in a session directory are considered automatic candidates for relaying (i.e., case 3/ above), the firewall's 'watcher' process should still perform some checks on incoming announcements. In particular, it should ensure that each session's 'group' address really is a multicast address, and (as noted above) it should also check that the port number is within a safe range. Depending on the security policy, it may also wish to prevent any *locally* created session announcements from becoming candidates (or being relayed).
（I）マルチキャストアドレスの特定の範囲は、「管理スコープ」であると定義されている[6]。ファイアウォールが真のマルチキャストルータとして機能していないにもかかわらず、マルチキャストセキュリティポリシーを設定し、管理スコープの境界を尊重すべきです。 （II）で述べたように、[2]、特定の特権UDPポートもマルチキャストと、危険と考えることができます。マルチキャストセキュリティポリシーでは、このようなポートを中継するための候補になっていないことを確認する必要があります。 （iii）のセッションディレクトリに発表されたセッションが（即ち、ケース3 /上）中継の自動候補と考えられる場合でも、ファイアウォールの「ウォッチャー」プロセスはまだ入ってくるアナウンスにいくつかのチェックを実行すべきです。特に、各セッションの「グループ」のアドレスが本当にマルチキャストアドレスであることを保証しなければならない、と（上記のように）それはまた、ポート番号は安全な範囲内にあることを確認する必要があります。セキュリティポリシーに応じて、それはまた、候補になってきて（または中継される）から任意の*ローカル*作成されたセッション告知を防ぐこともできます。
If a multicast group becomes a candidate to be relayed across the firewall, the actual relaying should *not* be done continually, but instead should be done only when there is actual interest in having this group relayed. The reason for this is two-fold. First, relaying a multicast group requires that one or both sides of the firewall join the group; this establishes multicast routing state within the network. This is inefficient if there is no current interest in having the group relayed (especially for Internet->intranet relaying). Second, the act of relaying an unwanted multicast group consumes unnecessary resources in the firewall itself.
マルチキャストグループは、候補者は、ファイアウォールを越えて中継するとなった場合、実際の中継は* *継続的に行われるべきではありませんが、代わりに中継され、この基を有するの実際の関心がある場合にのみ行われるべきです。この理由は二つあります。まず、マルチキャストグループを中継して、ファイアウォールの一方又は双方がグループに参加することを要求します。これは、ネットワーク内のマルチキャストルーティング状態を確立します。 （特にInternet->イントラネット中継のために）中継基を有するには、現在の関心が存在しない場合、これは非効率的です。第二に、不要なマルチキャストグループを中継する行為は、ファイアウォール自体に不要なリソースを消費します。
The best way for the firewall to determine when a candidate group should be relayed is for it to use actual multicast routing information, thereby acting much as if it were a real 'inter-domain' multicast router. If the intranet consists of a single subnet only, then the firewall could listen to IGMP requests to learn when a candidate group has been joined by a node on this subnet. If, however, the intranet consists of more than one subnet, then the firewall can learn about candidate group memberships by listening to "Domain Wide Multicast Group Membership Reports" [7]. Unfortunately, this mechanism has only recently been defined, and is not yet used by most routers.
それは、実際のマルチキャストルーティング情報を使用し、それが本当の「ドメイン間」マルチキャストルータであるかのように、それによって多くを演技するために中継されるべきで候補基である場合、ファイアウォールのための最善の方法は、決定します。イントラネットは、単一のサブネットで構成されている場合のみ、その後、ファイアウォールは候補群は、このサブネット上のノードが参加してきたとき、学ぶためにIGMP要求に耳を傾けることができます。しかし、イントラネットが複数のサブネットで構成されている場合、ファイアウォールは「ドメインワイドマルチキャストグループメンバーシップレポート」を聞くことによって候補グループメンバーシップについて学ぶことができます[7]。残念ながら、このメカニズムは、ごく最近に定義されており、まだほとんどのルータでは使用されません。
Another, albeit less desirable, way for the firewall to learn when candidate multicast groups have been joined is for the firewall to periodically 'probe' each of these groups. Such a probe can be performed by sending an ICMP ECHO request packet to the group, and listening for a response (with some timeout interval). This probing scheme is practical provided that the set of candidate groups is reasonably small, but it should be used only on the intranet, not on the external Internet. One significant drawback of this approach is that some operating systems - most notably Windows 95 - do not respond to multicast ICMP ECHOs. However, this approach has been shown to work on a large, all-Unix network.
もう一つは、あまり望ましいとはいえ、候補マルチキャストグループが参加してきたときにファイアウォールが習得するための方法は、定期的に「プローブ」これらのグループのそれぞれに、ファイアウォールのためです。そのようなプローブは、グループへICMP ECHO要求パケットを送信し、（いくつかのタイムアウト間隔で）応答を待機することによって行うことができます。この探査手法は、候補グループのセットが適度に小さいですが、それが唯一のイントラネット上ではなく、外部のインターネット上で使用されるべきであると実用的に提供されます。最も注目すべきはWindows 95が - - マルチキャストICMPエコーに応答しない、このアプローチの一つの重要な欠点は、一部のオペレーティングシステムであることです。しかし、このアプローチは、大規模な、すべてのUnixネットワーク上で動作することが示されています。
Another possibility - less desirable still - is for each node to explicitly notify the firewall whenever it joins, or leaves, a multicast group. This requires changes to the node's operating system or libraries, or cooperation from the application. Therefore this technique, like the previous one, is applicable only within the intranet, not the external Internet. Note that if multicast applications are always launched from a special "session directory" or "channel guide" application, then this application may be the only one that need be aware of having to contact the firewall.
別の可能性 - まだあまり望ましくは - 各ノードが明示的に参加するたび、ファイアウォール、または葉、マルチキャストグループを通知するためのものです。これは、ノードのオペレーティングシステムへの変更やライブラリ、またはアプリケーションからの協力が必要です。したがって、この技術は、以前のようではなく、外部のインターネット、イントラネット内のみ適用されます。マルチキャストアプリケーションは、常に特別な「セッションディレクトリ」または「チャンネルガイド」アプリケーションから起動している場合、このアプリケーションがファイアウォールに連絡することを意識する必要が唯一のものであってもよいことに注意してください。
What makes the latter two approaches ("probing" and "explicit notification") undesirable is that they duplicate some of the existing functionality of multicast routing, and in a way that scales poorly for large networks. Therefore, if possible, firewalls should attempt to make use of existing multicast routing information: either IGMP (for a single-subnet intranet), or "Domain Wide Multicast Group Membership Reports".
どのような後者の二つのアプローチが（「探査」と「明示的な通知」）、望ましくないなり、彼らがマルチキャストルーティングの既存の機能の一部を複製し、大規模ネットワークのために不十分なスケールの方法であることです。可能であればそのため、ファイアウォールは、既存のマルチキャストルーティング情報を利用することを試みる必要があります。どちらか（単一サブネットのイントラネット用）IGMP、または「ドメインワイドマルチキャストグループメンバーシップレポートを」。
In some circumstances, however, the client cannot avoid contacting the firewall prior to joining a multicast session. In this case, it may make sense for this contact to also act as a 'notification' operation. Consider, for example, an RTSP [8] proxy associated with the firewall. When the proxy receives a request - from an internal user - to open a remote RTSP session, the proxy might examine the response from the remote site, to check whether a multicast session is being launched, and if so, check whether the multicast group(s) are candidates to be relayed.
いくつかの状況では、しかし、クライアントは、前のマルチキャストセッションに参加するためにファイアウォールを接触させることを避けることができません。この接触はまた、「通知」操作として機能するため、この場合には、それが意味をなすことがあります。例えば、ファイアウォールに関連付けられたRTSP [8]プロキシを考えます。内部ユーザーから - - プロキシが要求を受信すると、リモートRTSPセッションを開くために、プロキシは、リモートサイトからの応答を調べるかもしれないマルチキャストセッションが起動されているかどうかをチェックするために、そうであれば、（マルチキャストグループかどうかを確認しますS）が中継する候補です。
The actual mechanism that's used to relay multicast packets will depend upon the nature of the firewall. One common firewall configuration is to use two nodes: one part of the intranet; the other part of the external Internet. In this case, multicast packets would be relayed between these two nodes (and then re-multicast on the other side) using a tunneling protocol.
マルチキャストパケットを中継するために使われている実際のメカニズムは、ファイアウォールの性質に依存します。一つの一般的なファイアウォールの設定は、2つのノードを使用することです：イントラネットの一部を、外部のインターネットの他の部分。この場合、マルチキャストパケットは、トンネリングプロトコルを使用して（他方側のマルチキャスト再次いでなど）、これらの2つのノード間で中継されることになります。
A tunneling protocol for multicast should *not* run on top of TCP, because the reliability and ordering guarantees that TCP provides are unnecessary for multicast communication (where any reliability is provided at a higher level), yet would add latency. Instead, a UDP-based tunneling protocol is a better fit for relaying multicast packets. (If congestion avoidance is a concern, then the tunnel traffic could be rate-limited, perhaps on a per-group basis.)
マルチキャストのためのトンネリングプロトコルは、信頼性とTCPが提供する注文保証は（任意の信頼性がより高いレベルで提供される）マルチキャスト通信には不要なので*、TCPの上で実行しないでください、まだ遅延を追加します。代わりに、UDPベースのトンネリングプロトコルは、マルチキャストパケットを中継するためのより良いフィット感です。 （輻輳回避が懸念される場合には、トンネルトラフィックは、レート制限、おそらくグループ単位であってもよいです。）
One possible tunneling protocol is the "UDP Multicast Tunneling Protocol" (UMTP) [9]. Although this protocol was originally designed as a mechanism for connecting individual client machines to the MBone, it is also a natural fit for for use across firewalls. UMTP uses only a single UDP port, in each direction, for its tunneleling, so an existing firewall can easily be configured to support multicast relaying, by adding a UMTP implementation at each end, and enabling the UDP port for tunneling.
一つの可能なトンネリングプロトコルは、「UDPマルチキャストトンネリングプロトコル」（UMTP）である[9]。このプロトコルは、もともとあるMBoneに、個々のクライアントマシンを接続するためのメカニズムとして設計されましたが、それはまた、ファイアウォールを越えて使用するための自然なフィット感です。 UMTPはtunnelelingため、各方向に、単一のUDPポートを使用するため、既存のファイアウォールを容易に各端部でUMTP実装を添加し、トンネリングのためのUDPポートを有効にすることによって、マルチキャスト中継をサポートするように構成することができます。
Notes:
ノート：
(i) When multicast packets are relayed from the intranet onto the external Internet, they should be given the same TTL that they had when they arrived on the firewall's internal interface (except decremented by 1). Therefore, the internal end of the multicast relay mechanism needs to be able to read the TTL of incoming packets. (This may require special privileges.) In contrast, the TTL of packets being relayed in the other direction - from the external Internet onto the intranet - is usually less important; some default value (sufficient to reach the whole intranet) will usually suffice. Thus, the Internet end of the multicast relay mechanism - which might be less trusted than the intranet end - need not run with special privileges. (ii) One end of the multicast tunnel - usually the intranet end - will typically act as the controller (i.e., "master") of the tunnel, with the other end - usually the Internet end - acting as a "slave". For security, the "master" end of the tunnel should be configured not to accept any commands from the "slave" (which will often be less trusted).
マルチキャストパケットは外部のインターネットにイントラネットから中継される（i）は、彼らが（1デクリメントを除く）は、ファイアウォールの内部インターフェイスに到着したとき、彼らが持っていた同じTTLを与えられるべきです。したがって、マルチキャスト中継機構の内部端は、着信パケットのTTLを読み取ることができる必要があります。 （これは、特別な権限を必要とするかもしれない。）これとは対照的に、他の方向に中継されるパケットのTTL - イントラネット上に外部インターネットからは、 - 通常あまり重要です。 （全体のイントラネットに達するのに十分な）いくつかのデフォルト値は、通常は十分です。このように、マルチキャストリレー機構のインターネット終了 - イントラネット端部よりも信頼性の低いかもしれない - 特別な権限で実行する必要はありません。 （ii）のマルチキャストトンネルの一端 - 通常イントラネット端が - 典型的には、もう一方の端で、トンネルのコントローラ（すなわち、「マスター」）として機能する - 通常インターネット端を - 「スレーブ」として機能します。セキュリティのために、トンネルの「マスター」端は、（多くの場合、信頼性の低いであろう）「スレーブ」から任意のコマンドを受け付けないように構成されるべきです。
So far we have assumed that there is only one firewall between the intranet and the external Internet. If, however, the intranet has more than one firewall, then it's important that no single multicast group be relayed by more than one firewall. Otherwise (because firewalls are assumed to be application-level gateways - not proper multicast routers), packets sent to any such group would become replicated on the other side of the firewalls. The set of candidate groups must therefore be partitioned among the firewalls (so that exactly one firewall has responsibility for relaying each candidate group). Clearly, this will require coordination between the administrators of the respective firewalls.
これまでは、イントラネットと外部のインターネットとの間に一つだけにファイアウォールがあることを前提としています。しかし、イントラネットは、複数のファイアウォールを持っている場合、それは単一のマルチキャストグループが複数のファイアウォールによって中継されないことが重要です。 （ファイアウォールは、アプリケーション・レベルのゲートウェイであると仮定されるので - ない適切なマルチキャストルータ）そうでなければ、そのようなグループに送信されたパケットは、ファイアウォールの反対側に複製なります。 （厳密に1つのファイアウォールは、各候補グループを中継する責任を有するように）候補グループの集合は、したがって、ファイアウォールの間で分配されなければなりません。明らかに、これはそれぞれのファイアウォールの管理者間の調整が必要になります。
As a general rule, candidate groups should be assigned - if possible - to the firewall that is topologically closest to most of the group members (on both the intranet and the external Internet). For example, if a company's intranet spans the Atlantic, with firewalls in New York and London, then groups with mostly North American members should be assigned to the New York firewall, and groups with mostly European members should be assigned to the London firewall. (Unfortunately, even if a group has many internal and external members on both sides of the Atlantic, only one firewall will be allowed to relay it. Some inefficiencies in the data delivery tree are unavoidable in this case.)
一般的なルールとして、候補群を割り当てる必要があります - 可能な場合 - （イントラネットと外部のインターネットの両方で）グループメンバーのほとんどに位相的に最も近いファイアウォールに。会社のイントラネットは、ニューヨークやロンドンでのファイアウォールで、大西洋をまたがる場合たとえば、その後、アメリカのほとんどが北のメンバーを持つグループは、ニューヨークのファイアウォールに割り当てられるべきである、と主にヨーロッパのメンバーとのグループは、ロンドンのファイアウォールに割り当てる必要があります。 （残念ながら、グループは、大西洋の両側に多くの内部および外部のメンバーを持っている場合でも、唯一1つのファイアウォールは、それをリレーすることが許可されます。データ配信ツリー内のいくつかの非効率性は、この場合には避けられません。）
SOCKS [10] is a mechanism for transparently performing unicast communication across a firewall. A special client library - simulating the regular 'sockets' library - sits between applications and the transport level. A conversation between a pair of nodes is implemented (transparently) as a pair of conversations: one between the first node and a firewall; the other between the firewall and the second node.
SOCKS [10]透過ファイアウォールを介してユニキャスト通信を行うための機構です。特別なクライアントライブラリ - 定期的な「ソケット」ライブラリをシミュレートするには - アプリケーションとトランスポートレベルの間に位置します。ノードの対の間の会話は、会話のペアとして（透過的に）実装されている：第1ノードとファイアウォールとの間の1つ;ファイアウォールと第2ノードとの間の他の。
In contrast, because multicast communication does not involve a conversation between a pair of nodes, the SOCKS model is less appropriate. Although multicast communication across a firewall is implemented as two separate multicast communications (one inside the firewall; the other outside), the *same* multicast address(es) and port(s) are used on both sides of the firewall. Thus, multicast applications running inside the firewall see the same environment as those running outside, so there is no need for them to use a special library.
マルチキャスト通信は、ノードの対の間の対話を必要としないので対照的に、SOCKSモデルはあまり適切です。ファイアウォールを介したマルチキャスト通信が二つの別個のマルチキャスト通信（ファイアウォールの内側オン;外部他）として実装されているが、*同じ*マルチキャストアドレス（ES）とポート（単数または複数）のファイアウォールの両側で使用されています。彼らは特別なライブラリを使用するための必要がないので、このように、ファイアウォールの内側で実行されているマルチキャストアプリケーションは、外部の実行中のものと同じ環境を参照してください。
Nonetheless, there has been a proposal [11] to extend SOCKS V5 to support multicast. This proposal includes two possible modes of communication:
それにもかかわらず、マルチキャストをサポートするためにSOCKS V5を拡張する提案[11]がありました。この提案は、通信可能な2つのモードがあります。
(i) "MU-mode", uses only *unicast* communication within the intranet (between the firewall and each internal group member), and (ii) "MM-mode", which uses unicast for client-to-firewall relay control, but uses *multicast* for other communication within the intranet.
（I）「MUモード」は、クライアント・ツー・ファイアウォールリレー制御のためのユニキャストを使用し、及び（ii）「MM-モード」、（ファイアウォールと各内部グループのメンバー間）イントラネット内のみ*ユニキャスト*通信を使用してしかし、イントラネット内の他の通信のための*マルチキャスト*を使用しています。
As noted in section 2 above, "MU-mode" would be a poor choice (unless, for some reason, the intranet does not support multicast routing at all). If multicast routing is available, there should rarely be a compelling reason to replace multicast with 'multiple-unicast'. Not only does this scale badly, but it also requires (otherwise unnecessary) changes to each application node, because the multicast service model is different from that of unicast.
上記のセクション2で述べたように、「MUモード」が（何らかの理由で、イントラネットがマルチキャストルーティングに全てをサポートしていない場合を除く）お粗末な選択であろう。マルチキャストルーティングが使用可能な場合、稀に「複数のユニキャスト」でマルチキャストを置き換えるために、説得力のある理由があってはなりません。このスケールはひどくないが、それはまた、必要とするだけでなく（そうでない場合は不要）マルチキャストサービスモデルは、ユニキャストとは異なるため、各アプリケーションノードに変更します。
On the other hand, "MM-mode" (or some variant thereof) *might* be useful in environments where a firewall can learn about group membership only via "explicit notification". In this case each node might use SOCKS to notify the firewall whenever it joins and leaves a group. However, as we explained above, this should only be considered as a last resort - a far better solution is to leverage off the existing multicast routing mechanism.
一方、「MM-モード」（またはいくつかの変異体）*かもしれない*ファイアウォールが唯一の「明示的な通知」を経由して、グループメンバーシップについて学ぶことができた環境で有用です。この場合、各ノードは、それが参加し、グループを離れたときに、ファイアウォールを通知するためにSOCKSを使用する場合があります。はるかに優れたソリューションは、既存のマルチキャストルーティングメカニズムをオフに活用することである - 私たちはしかし、前述したように、これは最後の手段としてのみ考慮されるべきです。
It has been suggested [11] that a benefit of using multicast SOCKS (or an "explicit notification" scheme in general) is that it allows the firewall to authenticate a client's multicast "join" and "leave" operations. This, however, does not provide any security, because it does not prevent other clients within the intranet from joining the multicast session (and receiving packets), nor from sending packets to the multicast session. As we noted in section 3 above, authentication and privacy in multicast sessions is usually obtained by signing and encrypting the multicast data, not by attempting to impose low-level restrictions on group membership. We note also that even if group membership inside the intranet could be restricted, it would not be possible, in general, to impose any such membership restrictions on the external Internet.
マルチキャストSOCKSを使用する利点（または一般的には「明示的な通知」方式では）それはファイアウォールがクライアントのマルチキャスト「参加」と操作を「残す」を認証するためにできることであるという[11]が提案されています。それはマルチキャストセッションに参加する（パケットを受信）から、またマルチキャストセッションにパケットを送信するから、イントラネット内の他のクライアントを防ぐことはできませんので、これは、しかし、どのようなセキュリティを提供していません。我々は上記のセクション3で述べたように、マルチキャストセッションでの認証とプライバシーは、通常は署名ではなくグループメンバーシップに低レベルの制限を課すことを試みることによって、マルチキャストデータを暗号化することによって得られます。私たちは、イントラネット内のグループメンバーシップを制限することができたとしても、それは外部のインターネット上の任意のそのようなメンバーシップの制限を課すことを、一般的には、可能ではないことにも注意してください。
Once a security policy has been established, the techniques described in this document can be used to implement this policy. No security mechanism, however, can overcome a badly designed security policy. Specifically, network administrators must be confident that the multicast groups/ports that they designate as being 'safe' really are free from harmful data. In particular, administrators must be familiar with the applications that will receive and process multicast data, and (as with unicast applications) be confident that they cannot cause harm (e.g., by executing unsafe code received over the network).
セキュリティポリシーが確立されると、この文書に記載された技術は、このポリシーを実装するために使用することができます。いいえ、セキュリティ・メカニズムは、しかし、ひどく設計されたセキュリティポリシーを克服することはできません。具体的には、ネットワーク管理者は、彼らが「安全」であるとして指定するマルチキャストグループ/ポートが本当に有害なデータがないことを確信する必要があります。具体的には（例えば、安全でないコードを実行することにより、ネットワークを介して受信された）は、害を及ぼすことができないことを確信することが、管理者が受信するアプリケーションとプロセスマルチキャストデータに精通している必要があり、及び（ユニキャストアプリケーションと同様に）。
Because it is possible for an adversary to initiate a "denial of service" attack by flooding an otherwise-legitimate multicast group with garbage, administrators may also wish to guard against this by placing bandwidth limits on cross-firewall relaying.
敵がゴミでそれ以外の場合は、正当なマルチキャストグループを溢れさせることにより、「サービス拒否の」攻撃を開始することが可能であるため、管理者は、クロスファイアウォール中継に帯域幅制限を置くことによって、これを防ぐために望むことができます。
Bringing IP multicast across a firewall requires that the intranet first establish a multicast security policy that defines which multicast groups (& corresponding UDP ports) are candidates to be relayed across the firewall. The firewall implements this policy by dynamically determining when each candidate group/port needs to be relayed, and then by doing the actual relaying. This document has outlined how a firewall can perform these tasks.
ファイアウォールを介してIPマルチキャストをもたらすことは、イントラネットは、最初のマルチキャストグループ（＆UDPポートに対応する）を定義マルチキャストセキュリティポリシーを確立することを要求するファイアウォールを介して中継する候補です。ファイアウォールは、各候補グループ/ポートは、実際の中継を行うことによって、その後中継、とする必要があるときに動的に決定することによって、このポリシーを実装しています。この文書では、ファイアウォールがこれらのタスクを実行する方法を概説しました。
[1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[1]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[2] Djahandari, K., Sterne, D. F., "An MBone Proxy for an Application Gateway Firewall" IEEE Symposium on Security and Privacy, 1997.
[2]セキュリティとプライバシー、1997年Djahandari、K.、スターン、D. F.、 "アプリケーションゲートウェイファイアウォールのあるMBoneプロキシ" IEEEシンポジウム。
[3] Freed, N. and K. Carosso, "An Internet Firewall Transparency Requirement", Work in Progress.
[3]フリード、N.とK. Carosso、「インターネットファイアウォールの透明性要件」が進行中で働いています。
[4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[4] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365 July 1998.
[6]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365を1998年7月。
[7] Fenner, B., "Domain Wide Multicast Group Membership Reports", Work in Progress.
[7]フェナー、B.、「ドメインワイドマルチキャストグループメンバーシップレポート」が進行中で働いています。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[9] Finlayson, R., "The UDP Multicast Tunneling Protocol", Work in Progress.
[9]フィンレイソン、R.、 "UDPマルチキャストトンネリングプロトコル" が進行中で働いています。
[10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Joned, SOCKS Protocol Version 5", RFC 1928, April 1996.
[10]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL. Joned、SOCKSプロトコルバージョン5" 、RFC 1928、1996年4月。
[11] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", Work in Progress.
[11]シュイナード、D.、 "SOCKS V5 UDPおよびマルチキャスト拡張機能" が進行中で働いています。
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
ロス・フィンレイソン、ライブネットワークス株式会社（LIVE.COM）
EMail: finlayson@live.com WWW: http://www.live.com/
電子メール：finlayson@live.com WWW：http://www.live.com/
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。