Network Working Group R. Finlayson
Request for Comments: 2588 LIVE.COM
Category: Informational May 1999
Network Working Group R. Finlayson
Request for Comments: 2588 LIVE.COM
Category: Informational May 1999
IP Multicast and Firewalls
IP组播与防火墙
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.
许多组织使用防火墙计算机作为公共Internet和其私有内部“intranet”之间的安全网关。在本文档中，我们将讨论围绕穿越防火墙的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.
防火墙是一种安全网关，用于控制私有管理域（“intranet”）和公共Internet之间的访问。本文档讨论防火墙如何处理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.
我们假设防火墙的外部（在互联网上）可以访问IP多播-即，在公共“多播互联网”（又名“MBone”）上，或者可能在其他多播网络上。
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
我们还假设*内部*网络（即intranet）支持IP多播路由。这是可行的，因为内部网往往是集中管理的。（此外，许多公司内部网已经在内部使用多播——用于培训、会议或公司公告。）相比之下，一些先前提出的多播防火墙机制（例如[2]）通过在内部网内发送*单播*数据包来工作。这样的机制通常是不合适的，因为它们的伸缩性很差，并且会导致内部网中的网络流量过大。相反，最好是依靠
upon the existing IP multicast routing/delivery mechanism, rather than trying to replace it with unicast.
基于现有的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.)
本文档介绍了通过多播在防火墙两侧进行多播会话的场景。例如，（i）特定的公共MBone会话可以中继到内部网上（例如，为了员工的利益），或者（ii）特殊的内部通信（例如，宣布新产品）可以中继到公共MBone上。相比之下，我们不处理漫游用户（防火墙之外）希望使用虚拟专用网络访问专用内部多播会话的情况。（此类“road warrior”场景不在本文档范围内。）
As noted by Freed and Carosso [3], a firewall can act in two different ways:
正如Freed和Carosso[3]所指出的，防火墙可以以两种不同的方式工作：
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/作为“协议终点”。在这种情况下，外部Internet无法直接访问任何内部节点（防火墙除外），内部网也无法直接访问任何外部节点（防火墙除外）。此类防火墙也称为“应用程序级网关”。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) 通过Internet发送的多播数据包在intranet上永远看不到（反之亦然），除非此类数据包由防火墙明确中继，（ii）中继多播数据包的IP源地址将是防火墙的IP源地址，而不是数据包的原始发送者的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.
另一方面，多播通信涉及任意大小、可能变化的参与者集，其成员可能永远不会完全知道。（这是一个特性，不是一个bug！）因此，多播通信的安全性不是基于其参与者，而是基于其*数据*。特别是，多播通信通过对分组数据进行身份验证（例如，使用数字签名）来进行身份验证，并且通过对该数据进行加密来获得隐私。多播通信中的“信任”完全基于对数据的信任。
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) 破坏性数据从Internet流入intranet，或（ii）敏感数据无意中从intranet流入外部Internet。
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端口）包含可以从Internet安全中继到intranet的数据。例如，安全管理员可能会选择允许转发MBone讲座，因为知道该数据仅包含音频/视频（&到安全端口）。（ii）哪些多播组（和相应的UDP端口）将不包含敏感的内部信息（因此不应从内部网中继到Internet）。当然，这需要信任内部用户将用于参与这些组的应用程序。例如，如果用户使用音频/视频“查看器”程序参与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:
简而言之，防火墙必须做三件事才能处理多播：
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.
这三项任务将在接下来的三节中进行更详细的描述。
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.
请注意，由于防火墙通常是集中管理intranet的方便场所，因此某些防火墙还可能执行其他管理功能，例如审计、记帐和资源监视。但是，这些附加功能不在本文档的范围内，因为它们与防火墙无关。它们同样适用于没有防火墙的管理域。
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端口），这些组是通过防火墙中继的候选组。防火墙支持此类策略的基本方式有三种：
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
1/静态配置。防火墙可以预先配置一组候选组/端口-例如，在配置文件中。2/显式动态配置。候选组/端口集可以根据来自一个或多个受信任客户端（可能是内部客户端）的显式请求动态设置（和更新）。例如，防火墙可能包含一个“远程控制”机制，允许这些受信任的客户端在身份验证时更新候选组/端口集。3/隐式动态配置。候选组/端口集可以基于一些预先授权的多播组/端口的内容（例如“会话目录”）隐式确定。例如，假设安全策略决定可以中继默认的MBone SAP/SDP会话目录[5]，以及在此目录中宣布的任何会话。与防火墙关联的“观察者”进程将监视此目录，并使用其内容
dynamically update the set of candidates.
动态更新候选集。
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->intranet中继），则这是低效的。其次，中继不需要的多播组的行为会消耗防火墙本身不必要的资源。
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
防火墙确定何时中继候选组的最佳方法是使用实际的多播路由信息，从而使其看起来就像一个真正的“域间”多播路由器。如果内部网仅由一个子网组成，则防火墙可以侦听IGMP请求，以了解候选组何时已被该子网上的节点加入。但是，如果intranet包含多个子网，则防火墙可以通过侦听“域范围多播组成员资格报告”来了解候选组成员资格[7]。不幸的是，这一机制直到最近才被定义，而且还没有被用户使用
most routers.
大多数路由器。
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回显请求数据包并侦听响应（具有一定的超时间隔）来执行这种探测。如果候选组的集合相当小，则此探测方案是可行的，但它应仅在内部网上使用，而不应在外部Internet上使用。这种方法的一个显著缺点是，某些操作系统（最著名的是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.
另一种可能性——更不理想——是每个节点在加入或离开多播组时显式通知防火墙。这需要更改节点的操作系统或库，或者需要应用程序的配合。因此，与前一种技术一样，此技术仅适用于内部网，而不适用于外部Internet。请注意，如果多播应用程序总是从特殊的“会话目录”或“通道指南”应用程序启动，那么该应用程序可能是唯一需要知道必须联系防火墙的应用程序。
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（用于单子网intranet）或“域范围多播组成员报告”。
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会话的请求时，代理可能会检查来自远程站点的响应，以检查是否正在启动多播会话，如果是，则检查多播组是否是要中继的候选组。
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.
用于中继多播数据包的实际机制将取决于防火墙的性质。一种常见的防火墙配置是使用两个节点：内部网的一部分；外部互联网的另一部分。在这种情况下，将使用隧道协议在这两个节点之间中继多播数据包（然后在另一端重新多播）。
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在每个方向上只使用一个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) 当多播数据包从intranet中继到外部Internet时，应为其提供与到达防火墙内部接口时相同的TTL（递减1除外）。因此，多播中继机制的内部端需要能够读取传入分组的TTL。（这可能需要特殊特权。）相反，在另一个方向（从外部互联网到内部网）中继的数据包的TTL通常不那么重要；一些默认值（足以到达整个intranet）通常就足够了。因此，多播中继机制的Internet端（可能不如intranet端可信）不需要以特殊权限运行。（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.
到目前为止，我们假设内部网和外部互联网之间只有一个防火墙。但是，如果intranet有多个防火墙，则重要的是没有单个多播组由多个防火墙中继。否则（因为防火墙被假定为应用程序级网关，而不是正确的多播路由器），发送到任何此类组的数据包将在防火墙的另一端复制。因此，候选组集必须在防火墙之间进行分区（以便只有一个防火墙负责中继每个候选组）。显然，这需要各个防火墙的管理员之间进行协调。
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.)
作为一般规则，应将候选组（如果可能）分配到拓扑上最接近大多数组成员（在内部网和外部互联网上）的防火墙。例如，如果一家公司的内部网跨越大西洋，在纽约和伦敦设有防火墙，则应将拥有大部分北美成员的组分配给纽约防火墙，而拥有大部分欧洲成员的组应分配给伦敦防火墙。（不幸的是，即使一个组在大西洋两岸都有许多内部和外部成员，也只允许一个防火墙对其进行中继。在这种情况下，数据传递树中的一些低效是不可避免的。）
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]是一种通过防火墙透明地执行单播通信的机制。一个特殊的客户端库（模拟常规的“套接字”库）位于应用程序和传输层之间。一对节点之间的对话（透明地）实现为一对对话：第一个节点和防火墙之间的对话；另一个在防火墙和第二个节点之间。
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模型不太合适。虽然跨防火墙的多播通信实现为两个独立的多播通信（一个在防火墙内，另一个在防火墙外），但在防火墙的两侧使用*相同*多播地址和端口。因此，在防火墙内运行的多播应用程序可以看到与在防火墙外运行的多播应用程序相同的环境，因此它们不需要使用特殊的库。
Nonetheless, there has been a proposal [11] to extend SOCKS V5 to support multicast. This proposal includes two possible modes of communication:
尽管如此，还是有人建议[11]扩展SOCKS V5以支持多播。本提案包括两种可能的通信方式：
(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.
有人建议[11]，使用多播SOCKS（或通常的“显式通知”方案）的好处在于，它允许防火墙验证客户端的多播“加入”和“离开”操作。但是，这并不提供任何安全性，因为它不会阻止内部网中的其他客户端加入多播会话（并接收数据包），也不会阻止向多播会话发送数据包。正如我们在上面第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] Deering，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] Djahandari，K.，Sterne，D.F.，“应用网关防火墙的MBone代理”，IEEE安全和隐私研讨会，1997年。
[3] Freed, N. and K. Carosso, "An Internet Firewall Transparency Requirement", Work in Progress.
[3] Freed，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.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365 July 1998.
[6] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[7] Fenner, B., "Domain Wide Multicast Group Membership Reports", Work in Progress.
[7] Fenner，B.，“域范围多播组成员报告”，正在进行中。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[9] Finlayson, R., "The UDP Multicast Tunneling Protocol", Work in Progress.
[9] Finlayson，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] Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Joned，《袜子协议第5版》，RFC 19281996年4月。
[11] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", Work in Progress.
[11] Chouinard，D.，“SOCKS V5 UDP和多播扩展”，正在进行中。
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
罗斯·芬莱森，直播网络公司（Live.COM）
EMail: finlayson@live.com
WWW: http://www.live.com/
EMail: 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编辑功能的资金目前由互联网协会提供。