19.6. Multicast and the Multicast Backbone (MBONE)

As we discussed in Chapter 4, "Packets and Protocols ", IP supports three kinds of packets; unicast (addressed to a single host), broadcast (addressed to all hosts), and multicast (addressed to a group of hosts). ulticast IP packets look just like regular IP packets with destination addresses that are in the range 224.0.0.0 through 239.255.255.255. An individual address in this range (224.0.1.1, for instance) is called a multicast group (because it addresses a group of hosts).

Because of the nature of multicast, it makes sense only to multicast IP protocols that are not session oriented. One host cannot usefully set up a single session with multiple other hosts. Since TCP is session oriented, a TCP packet should never have a multicast destination address. Currently the only IP protocols that are normally seen with multicast destination addresses are UDP, IGMP, and OSPF. Similarly, multicast addresses are valid only as destination addresses, not as source addresses (a packet can't come from a group of hosts).

ulticasting is particularly useful when you're dealing with high-bandwidth loss-tolerant applications like audio and video conferencing. With such applications, you may have a number of stations all receiving the same stream of packets, and the stream may consume a significant fraction of the available network bandwidth. If a given stream consumes 10 percent of your available network bandwidth (which is not uncommon), you wouldn't want to unicast it to each interested host because each of these unicasts would consume another 10 percent of your bandwidth, limiting you to 10 participating hosts, and that assumes that you did nothing else with the network. You also wouldn't want to broadcast it to all hosts unless all (or almost all) of your hosts were actually interested in the stream because it places a significant load on each host to process a broadcast packet and then decide to ignore it.

ulticast groups are somewhat like cable television channels. A variety of channels (multicast groups), such as HBO, CNN, ESPN, and TV, are available, but most homes (hosts) subscribe to only a few of the available channels. Some multicast groups are permanent; that is, certain addresses are reserved for certain uses, such as NTP, video conferencing of Internet Engineering Task Force (IETF) meetings, NASA Select video feeds (whenever the space shuttle is in orbit), and so on. Other multicast groups are transient: set up for a particular purpose or event and then shut down when they are no longer needed, to be reused for something else later on.

ulticasting is being used on the Internet today primarily for real-time conferencing services, including video, audio, and electronic whiteboard services. It's starting to be used for other services as well, such as transmitting Usenet news efficiently to a wide body of recipients.

Not all networks will pass multicast traffic. Some networks refuse to pass multicast in order to preserve network bandwidth, and others use routing hardware that doesn't understand multicast. In either case, it is possible to use multicast, while controlling the traffic that is passed, by using multicast tunnels.

A common approach to linking two multicast-capable networks (such as Ethernets) over a unicast-only network (such as a T1 leased line) is to create a tunnel over the unicast network, with multicast routers (often called mrouters) at either end of the tunnel. These mrouters take multicast IP packets, encapsulate them into unicast IP packets, and send them (via regular IP unicast) to the mrouter on the other end, which unencapsulates them to turn them back into multicast IP packets. By creating a web of mrouters and tunnels, you can create a virtual multicast network on top of a unicast backbone.

The MBONE is the ad hoc Multicast Backbone on the Internet and is just such a web of mrouters and tunnels. Its participants are sites that are interested in using IP multicasting for a variety of services on the Internet.

IP multicasting brings up several firewall issues. If a site uses tunneling to take part in the MBONE, what do the packets for the tunnels look like? What could be sent through the tunnels? If a site doesn't use tunnels, but uses IP multicasting directly, how will the site's packet filtering system deal with it? Can nonmulticast services (such as SMTP and NFS) be accessed by attackers via multicast, whether or not they're tunneled?

IP multicast tunneling is currently done with IP-in-IP encapsulation, which is discussed further in Chapter 4, "Packets and Protocols ". IP multicast tunnels used to be done with source-routed IP packets, but this practice caused a number of problems (not the least of which was upsetting folks who had firewalls), and it is no longer recommended.

To prevent a multicast tunnel from being used as a back door into or out of a network, the current publicly available mrouter code will only accept multicast packets through the tunnel; it won't accept unicast packets shoved through the tunnel in an attempt to bypass your firewall. If you're using a commercial multicast router, rather than the publicly available code off the Internet, you should verify that it will behave in a similar way.

If you have routers and a network topology that support multicast directly, without tunnels, you still have to worry about how any packet filtering system you use is going to cope with it. It shouldn't be too difficult, though, because from a packet filtering point of view, multicast packets look just like regular packets with somewhat unusual destination addresses (addresses in the range 224.0.0.0 through 239.255.255.255). Treat them just as you would anything else: block them all by default and allow the ones you understand and want to support. Keep in mind that each of these multicast addresses is going to apply to multiple internal machines, and that if you're accepting multicast packets from the outside world, then all of the internal machines that are accepting those packets will have to be protected against attack from the outside world -- just as if you were accepting any other packets directly from the outside world. Multicast routing is handled by a special protocol called IGMP, which is discussed in Chapter 22, "Administrative Services".

For a long time, multicast was used almost exclusively for multimedia, but there are now more and more uses of multicast for administrative protocols. This has made accepting multicast much more risky, since there are now vulnerable services (NIS under Unix, WINS replication under Windows NT) that support multicast.

Even if your tunnel is restricted to only multicast packets, or if you're using multicast directly without tunneling, and you have protected risky servers that support multicast, there is still the question of how your hosts will respond to multicast packets addressed to regular ports, such as your SMTP and NFS ports. Behavior varies from operating system to operating system, and even from release to release within the same operating system. If your operating system's code is based on release 3.3 or later of the "IP Multicast Extensions for BSD-Derived Unix Systems" from Xerox PARC and the University of Delaware, then your system should be safe against these kinds of attacks. Unless you installed the multicast extensions yourself, however, you could have a very difficult time determining what your operating system's multicast code is based on. (Your best bet is to ask your vendor, but don't be surprised if it's difficult to find anybody who knows.)

---