Subject: mcast firewalling idea

From: [email-masked] (Scott Michel)
Date: Fri, 10 Oct 1997 11:32:43 -0700 (PDT)

[M-x pain-sponge-mode <RET>]

What would be the implication if the following mods were made to the
multicast forwarding code? I'm not as plugged into the mcast issues as
I'd like to be, but here goes anyway:

1. A host inside the firewall issues an IGMP join to the egress router.

2. The egress router continues to propagate the join upstream to continue
   tree building. It also sends the join to the ingress router, if the
   ingress router isn't the same as the egress.

3. For all mcast packets from internal hosts, the router replaces
   the mcast packet's source address with the egress address of the
   router.
  
4. For all incoming and outgoing mcast packets, do UDP port remapping so
   as to avoid the usual nasties like NFS and portmapper or reserved
   ports. So what is port 2049 coming from the external world becomes
   11967 to the internal secured network or some such. This requires
   the router to keep track of and re-port all incoming mcast UDP pkts.

5. The egress router ignores all incoming mcast packets.

6. The ingress router ignores all outbound mcast packets.

It occurs to me that high level protocols are affected by the egress
router's proxying where the source IP address is passed as part of
the payload. But at least it avoids the multiple unicast approach, and
seems to have some chance of working.

It seems to me that two problems get solved this way: (a) you can
firewall the mcast traffic without breaking the underlying fabric
too much, (b) this solves some problems with assymetric networks which
don't have MAC addresses or use IP addresses as MAC addresses (like
Hughes DBS where the iface is recv only).

-scooter

---

From: [email-masked] (Jeremy Hall)
Date: Fri, 10 Oct 1997 23:41:04 -0400 (EDT)

Why not use an rtp mixer? Have the firewall join the group and set up a
boundary. The firewall could alter the sdr announcements so that it could
transcode between the inside and the outside.

---

From: [email-masked] (Scott Michel)
Date: Mon, 13 Oct 1997 14:08:50 -0700 (PDT)

> transcode between the inside and the outside.

1. It's not clear if our security people will trust an extra machine
   outside the firewall to do the RTP mixing.

2. Our security people like solutions inside the firewall. So do other
   people. They feel they're in control that way.

3. Latency. The RTP mixer would have to live in user space, which involves
   at least 3 context switches per packet (kernel->user->kernel) if not
   more.

-scooter

---

From: [email-masked] (Jeremy Hall)
Date: Mon, 13 Oct 1997 19:11:26 -0400 (EDT)

no, run the mixer on the firewall.

---

From: [email-masked] (Scott Michel)
Date: Mon, 13 Oct 1997 14:08:50 -0700 (PDT)

-scooter

---

From: [email-masked] (Jeremy Hall)
Date: Mon, 13 Oct 1997 19:11:26 -0400 (EDT)