[AG-TECH] Unicast-Multicast bridges?

[John Shalf]

Yeah,
my message was quite long, but that was the "multicast
forwarding loops" I was mentioning near the end.  The
utilization of these things as traffic amplifiers for denial
of service attacks is another concern.  So, again, the
message making something that is "deployable" is a much
bigger jump than making something that simply works...

-john

Jay Beavers wrote:
> 
> 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
> > >