RFC 2588

IP Multicast and Firewalls

📅 published May 1999, from ietf

RFC 2588: IP Multicast and Firewalls 🎀

okay bestie, this is RFC 2588 🌸 written by R. Finlayson from LIVE.COM, dated May 1999. It's filed as Informational, which means it's sharing info with the Internet crowd, not making a standard ✨. Its header doesn't list any obsoletes or updates, so it doesn't replace or change any other RFC 💖.

Status of This Memo 🦋

This memo gives info to the Internet community. It is not an Internet standard of any kind 💅. Distribution of this memo is unlimited 💜.

Copyright (C) The Internet Society (1999). All Rights Reserved. 🫶

1. Abstract ✨

Lots of organizations run a firewall computer as a security gateway between the public Internet and their private internal intranet 🧱. This doc is about the drama of getting IP multicast traffic across that firewall, and the different ways a firewall can set up and control that crossing 🚪. It also explains why SOCKS, which was built specifically for unicast traffic, is kinda not the best fit for multicast 🙈.

2. Introduction 🎀

A firewall is a security gateway that controls access between a private administrative domain (an "intranet") and the public Internet. This doc is about how a firewall handles IP multicast [1] traffic 🌷.

We assume the external side of the firewall has access to IP multicast. Like, it's on the public "Multicast Internet" (aka "MBone") or maybe some other multicast network 🌍.

We also assume the internal network (the intranet) supports IP multicast routing. This is practical, because intranets tend to be centrally administered. Also, lots of corporate intranets already use multicast internally for training, meetings, or company announcements 📣. Some earlier firewall ideas for multicast (like [2]) worked by sending unicast packets within the intranet. Those are usually a bad look 😬 because they scale poorly and can cause excessive network traffic inside the intranet. It's better to rely on the existing IP multicast routing and delivery instead of trying to replace it with unicast 💅.

This doc covers scenarios where a multicast session is carried over multicast on both sides of the firewall 🔁. For example: (i) a public MBone session gets relayed onto the intranet (for the employees' benefit), or (ii) a special internal communication (like announcing a new product) gets relayed onto the public MBone 🚀. What we don't cover is a roaming user outside the firewall who wants to access a private internal multicast session through a virtual private network. Those "road warrior" scenarios are outside the scope of this doc 🧳.

As Freed and Carosso [3] noted, a firewall can act in two different ways 🤓:

  • 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. These firewalls are also known as "application-level gateways."
  • 2/ As a "packet filter." In this case, internal and external nodes can see each other at the IP level, but the firewall filters out (blocks passage of) certain packets based on their header or contents.

For the rest of this doc, we assume the first type, since it's the most restrictive and generally gives the most security 🔐. For multicast, that means:

  • (i) A multicast packet sent over the Internet will never be seen on the intranet (and vice versa), unless the firewall explicitly relays it, and
  • (ii) The IP source address of a relayed multicast packet will be the firewall's, not the original sender's. To work correctly, the applications and protocols being used must take this into account. (Thankfully, most modern multicast-based protocols, like RTP [4], are designed with this kind of relaying in mind 🙌.)

3. Why Multicast is Different 🧠

When we think about the security implications of IP multicast, it's important to notice how multicast communication is fundamentally different from unicast 👀.

Unicast is a 'conversation' between an explicit pair of participants. So it makes sense for unicast security to be based on those participants (for example, by authenticating each one). Trust in unicast can also be based on trust in each participant, as well as trust in the data 🤝.

Multicast is different. It involves an arbitrary-sized, potentially varying set of participants, and their membership might never be fully known. (This is a feature, not a bug! ✨) Because of this, multicast security isn't based on its participants. It's based on its data 💜. Specifically, multicast communication is authenticated by authenticating packet data (for example, using digital signatures), and privacy is obtained by encrypting that data 🔏. So 'trust' within multicast communication is based solely on trust in the data 💯.

The main threat 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.

To avoid this threat, the intranet's security administrator has to set up a security policy in advance. That policy 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 admin might choose to permit relaying an MBone lecture, knowing the data is only audio/video (& to safe ports) 🎥.
  • (ii) Which multicast groups (and corresponding UDP ports) will not contain sensitive internal information, so that they should not be relayed from the intranet onto the Internet. This requires placing trust in the applications that internal users will use to take part in these groups. For example, if users use an audio/video 'viewer' program to join an MBone session, then that program must be trusted not to be a "Trojan Horse" 🐴😈. (This requirement for "trusted applications" is by no means specific to multicast, of course.)

Once the security policy is established, it's the firewall's job to implement it 🛡️.

5. What Firewalls Need to Do 🛠️

In short, a firewall must do three things to handle multicast 📋:

  • 1/ Support the chosen multicast security policy (which establishes particular multicast groups as 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).

We'll go through these three tasks in more detail in the next three sections 🧚.

Since a firewall is often a convenient place to centralize intranet administration, some firewalls might also do extra admin jobs, like auditing, accounting, and resource monitoring 📊. Those extra functions are outside the scope of this doc, though, because they aren't specifically firewall-related. They're just as applicable to an administrative domain that isn't firewalled 🙄.

6. Supporting a Multicast Security Policy 🔐

As we said above, a multicast security policy comes down to specifying the set of allowed multicast groups (& corresponding UDP ports) that are candidates to be relayed across the firewall. There are three basic ways a firewall can support that policy 🎀:

  • 1/ Static configuration. The firewall could be configured in advance with the set of candidate groups and ports, for example in a configuration file 📝.
  • 2/ Explicit dynamic configuration. The set of candidate groups and ports could be set (and updated) dynamically, based on an explicit request from one or more trusted clients (presumably internal ones). For example, the firewall could have a 'remote control' mechanism that lets these trusted clients update the set of candidate groups and ports, once they've authenticated 🕹️.
  • 3/ Implicit dynamic configuration. The set of candidate groups and ports could be figured out implicitly, based on the contents of some pre-authorized multicast group and port, like a "session directory." Say the security policy decides the default MBone SAP/SDP session directory [5] may be relayed, along with any sessions announced in that directory. A 'watcher' process associated with the firewall would watch the directory and use its contents to dynamically update the set of candidates 👀.

Notes:

  • (i) Certain ranges of multicast addresses are defined to be "administratively scoped" [6]. Even though the firewall doesn't 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 don't become candidates for relaying 🚫.
  • (iii) Even if sessions announced in a session directory are considered automatic candidates for relaying (that's case 3/ above), the firewall's 'watcher' process should still do some checks on incoming announcements. In particular, it should make sure each session's 'group' address really is a multicast address. As noted above, it should also check that the port number is within a safe range 🛡️. Depending on the security policy, it may also want to stop any locally created session announcements from becoming candidates (or being relayed) 🙅‍♀️.

7. Determining When to Relay Candidate Groups ✨

okay so if a multicast group becomes a candidate to get relayed across the firewall, the actual relaying should not be happening nonstop 🙅‍♀️. It should only kick in when somebody actually wants that group relayed. There are two reasons, bestie 💅. First, relaying a group means one or both sides of the firewall have to join it, and that sets up multicast routing state in the network. That's super wasteful if nobody currently wants it, especially for Internet->intranet relaying 😤. Second, relaying a group nobody asked for burns resources inside the firewall itself. Rude 💀.

The best way for the firewall to figure out when to relay is to use actual multicast routing info, so it acts basically like a real 'inter-domain' multicast router 🧠. If the intranet is just one subnet, the firewall can listen to IGMP requests to see when a node on that subnet joins a candidate group. If the intranet has more than one subnet, the firewall can learn about memberships by listening to "Domain Wide Multicast Group Membership Reports" [7]. Lowkey the catch is that this mechanism was only recently defined, and most routers don't use it yet 😭.

Another option, less desirable (ngl), is for the firewall to periodically 'probe' each candidate group. You send an ICMP ECHO request to the group and wait for a response, with some timeout interval ⏱️. Probing is fine as long as the set of candidate groups is reasonably small, but it should only be used on the intranet, never the external Internet 🙅. The big drawback is that some operating systems, most notably Windows 95, don't respond to multicast ICMP ECHOs 💀. Still, this approach has been shown to work on a large, all-Unix network 🐧.

Even less desirable is for each node to explicitly notify the firewall whenever it joins or leaves a multicast group. This needs changes to the node's operating system or libraries, or cooperation from the application. So like probing, this technique only applies within the intranet, not the external Internet 🚧. Also, if multicast applications are always launched from a special "session directory" or "channel guide" application, then that app may be the only one that needs to know it has to contact the firewall 🎀.

What makes probing and explicit notification the undesirable options is that they duplicate some of what multicast routing already does, and they scale poorly for large networks 📉. So if possible, firewalls should try to use the existing multicast routing info: either IGMP (for a single-subnet intranet) or "Domain Wide Multicast Group Membership Reports" 💖.

Sometimes though, the client can't avoid contacting the firewall before joining a multicast session. In that case, the contact can also act as a 'notification' 🦋. Picture an RTSP [8] proxy associated with the firewall. When it gets a request from an internal user to open a remote RTSP session, it might check the response from the remote site to see whether a multicast session is being launched, and if so, check whether the multicast group(s) are candidates to be relayed 👀.

8. Relaying Candidate Groups 🚀

How the relaying actually happens depends on the firewall. One common setup uses two nodes: one part of the intranet, and the other part of the external Internet. Multicast packets get relayed between those two nodes using a tunneling protocol, and then re-multicast on the other side 🌈.

A tunneling protocol for multicast should not run on top of TCP 🙅. TCP's reliability and ordering guarantees aren't needed for multicast (any reliability gets handled at a higher level), and they'd just add latency 🐌. So a UDP-based tunneling protocol is a better fit. (If congestion avoidance is a concern, the tunnel traffic could be rate-limited, maybe on a per-group basis 🚦.)

One possible option is the "UDP Multicast Tunneling Protocol" (UMTP) [9]. It was originally designed for connecting individual client machines to the MBone, but it's also a natural fit for use across firewalls 🎀. UMTP uses only a single UDP port in each direction for its tunneling, so an existing firewall can easily support multicast relaying by adding a UMTP implementation at each end and enabling that UDP port ✨.

Notes:

  • (i) When multicast packets are relayed from the intranet onto the external Internet, they should be given the same TTL they had when they arrived on the firewall's internal interface, except decremented by 1. So the internal end of the relay needs to be able to read the TTL of incoming packets (this may require special privileges 🔐). The TTL of packets relayed the other way, from the external Internet onto the intranet, is usually less important, and some default value (enough to reach the whole intranet) will usually do the job. That means the Internet end, which might be less trusted than the intranet end, doesn't need to run with special privileges 🙌.
  • (ii) One end of the tunnel, usually the intranet end, will typically act as the controller (i.e., "master") of the tunnel, and the other end, usually the Internet end, acts as a "slave". For security, the "master" end should be configured not to accept any commands from the "slave", which will often be less trusted 🔒.

9. Networks With More Than One Firewall 🏰

So far we've assumed there's only one firewall between the intranet and the external Internet. But if the intranet has more than one firewall, it's super important that no single multicast group gets relayed by more than one of them 🚨. Why? Because firewalls are assumed to be application-level gateways, not proper multicast routers, so packets sent to any such group would get replicated on the other side of the firewalls 😱. The set of candidate groups has to be partitioned among the firewalls, so that exactly one firewall is responsible for relaying each candidate group. This will clearly need coordination between the administrators of the respective firewalls 🤝.

As a general rule, candidate groups should be assigned, if possible, to the firewall that's 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 go to the New York firewall, and groups with mostly European members should go to the London firewall 🌍. (Unfortunately, even if a group has many internal and external members on both sides of the Atlantic, only one firewall is allowed to relay it. Some inefficiencies in the data delivery tree are unavoidable in this case 😩.)

10. Why SOCKS is Less Appropriate for Multicast 🧦

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, and the other between the firewall and the second node.

Multicast communication doesn't involve a conversation between a pair of nodes, so the SOCKS model is less appropriate 🙃. Although multicast communication across a firewall is implemented as two separate multicast communications (one inside the firewall, one outside), the same multicast address(es) and port(s) are used on both sides. So multicast applications inside the firewall see the same environment as those outside, and there's no need for them to use a special library 💜.

Nonetheless, there has been a proposal [11] to extend SOCKS V5 to support multicast 🧐. This proposal includes two possible modes of communication:

  • (i) "MU-mode", which 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.

As noted in section 2 above, "MU-mode" would be a poor choice (unless, for some reason, the intranet doesn't 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 that scale badly, it also requires (otherwise unnecessary) changes to each application node, because the multicast service model is different from that of unicast 🙄.

On the other hand, "MM-mode" (or some variant of it) might be useful in environments where a firewall can learn about group membership only via "explicit notification". In that case, each node might use SOCKS to notify the firewall whenever it joins and leaves a group. But as we explained above, this should only be considered as a last resort. A far better solution is to leverage the existing multicast routing mechanism 🏆.

It has been suggested [11] that a benefit of using multicast SOCKS (or an "explicit notification" scheme in general) is that it lets the firewall authenticate a client's multicast "join" and "leave" operations. Sounds nice, but it doesn't actually provide any security 🚫. It doesn't 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 are usually obtained by signing and encrypting the multicast data, not by trying to impose low-level restrictions on group membership 🔐✨. We also note that even if group membership inside the intranet could be restricted, it wouldn't be possible, in general, to impose any such membership restrictions on the external Internet 🌐.

11. Security Considerations 🔐

okay this section is SO important bestie 🚨 once a security policy is set up, the techniques in this doc are how you actually make it happen 💅 but no security mechanism can save a badly designed policy 💀 so network admins have to be super confident that the multicast groups/ports they mark as 'safe' really are free from harmful data 🙈 they need to know the apps that receive and process multicast data, and (same as with unicast apps) be sure those apps can't cause harm, like by running unsafe code that came in over the network 😭

also, an adversary can totally pull off a "denial of service" attack by flooding an otherwise-legit multicast group with garbage 🗑️ so admins might wanna guard against that by putting bandwidth limits on cross-firewall relaying 🛡️

12. Summary 🌸

okay recap time 🎀 bringing IP multicast across a firewall starts with the intranet setting up a multicast security policy that defines which multicast groups (& corresponding UDP ports) are candidates to be relayed across the firewall 📋 then the firewall carries out that policy by figuring out dynamically when each candidate group/port needs relaying, and then doing the actual relaying 🦋 this document has laid out how a firewall can pull all of that off ✨

13. References 📚

  • [1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
  • [2] Djahandari, K., Sterne, D. F., "An MBone Proxy for an Application Gateway Firewall" IEEE Symposium on Security and Privacy, 1997.
  • [3] Freed, N. and K. Carosso, "An Internet Firewall Transparency Requirement", Work in Progress.
  • [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  • [6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365 July 1998.
  • [7] Fenner, B., "Domain Wide Multicast Group Membership Reports", Work in Progress.
  • [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
  • [9] Finlayson, R., "The UDP Multicast Tunneling Protocol", Work in Progress.
  • [10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Joned, SOCKS Protocol Version 5", RFC 1928, April 1996.
  • [11] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", Work in Progress.

14. Author's Address 🖊️

Ross Finlayson, Live Networks, Inc. (LIVE.COM) 💜

EMail: finlayson@live.com

WWW: http://www.live.com/

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

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. 💖

📦 where this page comes from