[AG-TECH] Unicast-Multicast bridges?

[Jay Beavers]

Just a caution on these bridges -- the RTP spec (RFC 1889) calls for
using CSRCs and handling loop detection for these 'bridges' or
'reflectors'.  Without it, you might accidentally establish a network
loop that would bring the network to its knees.

In the case of a multicast to unicast bridge node that rebroadcasts
packets as multicast, if one is brought up in an organization, you're
fine.  If two are brought up a loop forms and suddenly things get messy.

-----Original Message-----
From: John Shalf [mailto:jshalf at lbl.gov] 
Sent: Tuesday, January 22, 2002 2:13 PM
To: Ivan Judson
Cc: Robert Olson; ag-tech at mcs.anl.gov
Subject: Re: [AG-TECH] Unicast-Multicast bridges?


Hi Ivan,
no real cat to let out of the bag here.  I had to write a
very rudimentary bridge for our robot.  Anyone is welcome to
check it out from CVS (its open-access to anyone who wants
it).  I've just been balking at proffering this as
replacement for the current bridge because it is so
rudimentary and because the lesson we learned from the
FermiLab bridge is that any replacement requires someone
dedicated to supporting/developing it (which wouldn't be me
because I don't have any funding streams remotely related to
this work :-)  ).

So anyways, you are welcome to check it out;

* Login:
  cvs -d :pserver:cvs_anon at cvs.cactuscode.org:/packages
login
  the passwd is "anon"
* Checkout:
  cvs -d :pserver:cvs_anon at cvs.cactuscode.org:/packages co
TCPXX
* Compile Library: (must use gnu make... sorry, no
autoconfig here...)
  cd TCPXX
  gmake
* Make the Bridge:
	cd Examples
	gmake mpx_t

Documentation is in the comments, but basically you do
	mpx_t mcast_group/mcast_portbase
unicast_addr1/mcast_portbase1 uncast_addr2/mcast_portbase2

Really, I think anyone can read a little Comer & Stevens and
write a quickie bridge (just like I did), but my primary
caveat is that it would require significantly more
development to be production-quality.  This is certainly the
case with the current bridge (and dppt for that matter). 
Other caveats are; 

  1) This implementation is only good for subnet-to-subnet
bridging really.  So you could run one of these on one
subnet and another on a peer subnet and it will bridge the
multicast traffic between the two using what is essentially
an IP tunnel. 

  2) No access-control.... Without access-control of *some*
form this cannot really be used for production without some
access control as well as close evaluation for how the
current bridge software can be misused in wasy that flood
networks (something that I understand is quite easy to do
and *very* undesireable).

  3) It compiles under a variety of OS's (Linux, Irix, AIX,
Unicos, etc...) but this particular implementation uses
posix threads which can be quite terrible under AIX and
IRIX.  So if you wanted to use it under anything that isn't
Linux or Solaris, you'd want to use select() instead of the
threads.  There are such variants in there (mpx.cc etc...),
but they are not really tested at all.

  4) Might misbehave if you have multiple network cards on
your machine because it only binds to the *default* NIC
rather than binding to every available NIC.  The result is
that if you have multicast enabled on one port, but not on
another (as I discovered is the case on our SGI system),
then you get really unexpected failures.

Some thoughts (if this were to be a *real* development
effort):

1) A reasonable replacement for the current multicast bridge
software should 
	-listen for unicast packets being sent to it and accept
those hosts to be "clients".  
	-forward all of the traffic from the "clients" into the
multicast group that it is joined to
	-forward traffic from its multicast group to *each* of the
unicast "client" connections
  The problem with this is that it would be extremely simple
to use IP spoofing to turn this into a very destructive
engine for denial of service attacks.  Essentially, a
malicious person could send this engine a few "spoofed"
packets with return addresses that have bogus return
addresses in "boeing.com" domain.  This is an incredible
traffic amplifier since each bogus packet will cause the
bridge to send many unicast packets in response; taking your
firewall to its knees. So unless this is done with strict
access control to start with, I'd think it quite dangerous
to deploy such an implementation.  

2) Another possible implementation would simply involve
unicast tunnels between subnets.  The bridge snafs up all
local multicast traffic and sends it out through a unicast
tunnel.  It simultaneously takes all unicast traffic it
receives from its tunnel and sends it out as multicast on
the local network.  So you would run a pair of these
programs; one on your multicast-capable subnet and the other
on a subnet that can't do multicast.  Because it only
bridges traffic to a single unicast address rather than
multiple addresses, you don't have the traffic amplification
effect that makes the other bridge implementation so
dangerous.  A potential problem with this is that you must
be careful to guard against multicast forwarding loops (any
answer to that problem is going to be somewhat difficult). 
Anyways, this is sort of like implementation #1 but with
explicit access control (it only sends/receives unicast
packets from a single address rather than
accepting_from/blasting_to anyone who cares to join.

Anyways, these are things that make it clear that a robust
infrastructure requires some sustained effort to create.

-john

Ivan Judson wrote:
> 
> John Schalf from LBL has some code he might consider proffering up to
help
> generate a new open reflector/bridge.
> 
> John, am I remembering right or did I just let the wrong cat out of
the
> bag?
> 
> --Ivan
> 
> On Mon, 21 Jan 2002, Robert Olson wrote:
> 
> > "Reflector" is the magic word to search for ...
> >
> >
http://www.google.com/search?q=multicast+unicast+reflector&btnG=Google+S
earch
> >
> >
> > --bob
> >
> > At 05:40 PM 1/21/2002 -0800, Randy Groves wrote:
> > >I've been poking around the net to see if there is another
> > >unicast-multicast bridge available other than the Multi-Session
Bridge,
> > >which seems to be unavailable, as are the authors.  Bob Olson told
me a
> > >while ago that he could not re-distribute the code to which he has
> > >access.  Repeated attempts to contact anyone involved with the
package
> > >have failed.
> > >
> > >What other options exist?
> > >
> > >Thanks!!
> > >
> > >-randy
> >