Re: Improving Robustness of Distributed Services (Re: DDoS attacks)

["Majdi S. Abbas" <msa () samurai sfo dead-dog com>]

On Thu, Jul 12, 2001 at 04:08:14PM -0400, Dickson, Brian wrote:
> To paraphrase Lilu in _The Fifth Element_, "mooolteeeecaast".
>
> Multicast.
>
> It's a huge leap, which would require development, no doubt.

        It's been done.

> However, consider the following:
>
> - What is IRC, or for that matter net-news, at its heart? A transient,
> store-and-forward, one-to-many message system.
>
> In otherwords, multicast re-implemented on unicast, in some cases poorly and
> at great cost (news).
>
> - What happens to IRC when you change this to multicast? IRC channels morph
> to multicast groups; RPs replace IRC servers; and most importantly, the
> infrasture "glue" no longer has a visible IP address, and becomes much less
> vulnerable to attack. Multicast has *intrisnic* RPF checking (that's how it
> works, in fact). Attackers cut themselves off first, before any propogation
> occurs. The protocol(s) deals with localized 'issues'. Anyone wishing to
> interrupt the IRC network would have to attack the entirety of the Internet,
> simultaneously. (This is *not* a challenge, really.)
>
> How difficult would it be to (a) implement, and (b) to migrate the users
> over to the new system?

        Having spent several years running IRC servers, and beating on the
code of same:

        The implementation has already been done more than once.  I spent
a lot of time playing around with this, years ago.  The main obstacles are:

        1) Multicast is not nearly widely enough deployed to be used as a
general communications medium.  With companies like UUnet charging outrageous
rates for multicast support or refusing to support it at all, this will not
change.  IRC is supported by organizations who feel they can spare the 
bandwidth.  When this bandwidth starts carrying a very hefty surcharge, there
will be no support for IRC.

        2) IRC as it currently exists is not merely a message distribution
system, ala USENET.  IRC contains a lot of global state data, that has to 
be propagated consistantly to all portions of the network.  This means, 
sequencing and error checking.  The big problem here is, if you implement
IRC with its current trappings on multicast, you then have to re-implement
the functionality of TCP on multicast UDP.

        3) Multicast has its own inherent problems and security issues.
New attacks will be developed to target these.

        4) The obvious headaches, such as deploying new clients to an overall
worldwide userbase of millions, on every imaginable platform, as well as
server code.  All done by volunteers.  Nobody makes any money off IRC.

        I would suggest that IRC is not 're-implementing multicast on
unicast' but 'staying unicast so as not to have to re-implement unicast on
multicast.'

> Multicast. A solution looking for a problem; a problem found, at last. :-)

        Not quite.  Sorry.

        --msa