MBONE: Multicasting Tomorrow's Internet
Are there security risks?
Security risks depend on the application. Most MBONE applications cannot be coaxed into writing to disk by arriving packets; they also do not run set-uid. One possible exception might be the LBL whiteboard, wb, since it contains a PostScript interpreter. As with any network application, it is possible for users to pick up an attractive-looking multicast application that acts as a Trojan horse or virus. Currently, all MBONE applications use UDP. While only machines that subscribe to a particular multicast address will receive multicast packets, multicast is at the IP layer and thus all UDP packets arriving with a given destination address will be accepted by the kernel. As an example, a host receiving audio on port 3456 at a certain multicast address will also unwittingly receive (possibly malicious) NFS packets sent to the same multicast address and different port.
Thus, any filtering routers have to inspect the UDP payload within the IP-over-IP packet for unwanted UDP ports or non-UDP protocols. If a tunnel crosses a protection boundary, IGMP packets (protocol 2) and IP-in-IP (protocol 4) traverse the tunnel. Since IGMP is separate from regular routing, external users cannot influence the internal routing of unicast packets. Sites that restrict incoming TCP and UDP traffic should be aware that MBONE traffic, without any action by internal users, may impose additional load on the network and thus impair the working of the internal network until the appropriate mrouted daemons are terminated.
Table of Contents | Previous Section | Next Section