From: Dale W. Carder <dwcarder@...>
Date: November 11, 2004 4:12:04 PM CST
To: Network Security Admin Group <networksecurityadmin@...>
Subject: Multicast and firewalls

This email got really long as I wrote it, so here's an exec summary:

- Do not block multicast content through your firewall unless your users are used to, willing to accept, or department policies require content filtering. Content filtering is a messy business you probably want to avoid.

-----

I want to clear up some common misconceptions about multicast, and give some valid warnings about the firewall rules you may wish to use. I do acknowledge that certain departments have security policies and procedures, but it is my job to help you, the network security admins, understand what you may be doing with certain firewall rules and make informed decisions.

Multicast is not just DATN, and DATN is not the only content delivered via multicast. If you only allow DATN through, how are your users going to get streams from other campus multicast servers, other universities, other content providers, etc? For example, recently I have watched presentations at NANOG and I2 meetings, and even the olympics (sourced from Norway) via multicast. We're spending millions of dollars on networking. Use it! :-) Also realize that there are other uses of multicast, including server location, so be careful what you block with a firewall.

Let's talk for a second about www access, because we are all more familiar with it. In the HTTP world, think of I want content from yahoo, so I type in http://www.yahoo.com in my browser as that URL defines the content. Unless my network does content filtering, I expect that I can reach whatever web page I want. This is what users will expect.

Multicast (paired with IGMPv2 in particular) could be understood as just a network efficient content delivery service. If you think about "content" in this model some problems relating to firewalls come to light:

Multicast source addresses should be considered arbitrary! The multicast *group* or destination address has the significance, not necessarily the source (except w/ SSM). Even better, the UDP ports used are equally arbitrary! This is just like in the yahoo example above, DNS defines the content, and abstracts what server will deliver that content. Likewise, if DoIT moves a server's IP address but still uses the same multicast group for the content, blocking it is your fault. If we add channels or sources from around campus or even off-campus, again blocking these is your fault if the users complain.

When a client decides they want content, they subscribe to a particular multicast group. It's up to smart network electronics to figure out what server delivers this content. If the client does not want content, routers running PIM and switches running IGMPv2 pruning will make sure they don't get it. It's not as bad as the unsolicited world of TCP SYN's you may be used to. Things are a lot better here. Multicast can be implemented inherently stateful as a byproduct of being efficient.

However, there are probably good reasons to keep your hosts from sourcing or providing content, just like you probably don't want every PC running a web server. This the the place for firewalls with multicast. Your firewall rules should let the client subscribe to any content you want, but make sure your client PC's aren't the content and are not trying to DOS the content (or the routers!) inadvertently.

Dale

-----------------------------------------------------------------
Dale W. Carder dwcarder@...
Network Engineer office: (608) 263-3628
DoIT Network Services 24hr NOC: 263-4188
http://net.doit.wisc.edu/~dwcarder