Improving Robustness of Distributed Services (Re: DDoS attacks)

Mailman List Mirror (Read Only)
1

* Most of DoS attacks are against IRC networks. Hence, if we can get rid

of those, the health of the Internet as a whole should improve.

* Experience gathered with this approach should be useful to developers

and administrators of other distributed services and protocols.

To paraphrase Lilu in _The Fifth Element_, "mooolteeeecaast".

Multicast.

It's a huge leap, which would require development, no doubt.

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?

I can't speak to (a), never having operated a network with a
network-administered IRC server (that I know of anyway ;-)).
As to (b), if an initial gateway from unicast<->multicast (think
MBGP<->DVMRP for the mbone) or many exist, should be easy. Show users that
the new system is more resilient, and they'll use it. More importantly, have
the operators and/or upstream networks promise to support the old system for
a limited time only, after successful deployment of the new system. For
network admins, the fact that it's more efficent for backbone use (a bigger
factor near the edge, where bottom-tier ISPs with not many resources, and
lots of IRC users - fill the modem ports with bandwidth, at no cost to your
upstream link!) should be a selling point in and of itself.

A significant number of top-tier networks already have the necessary
multicast support and peering. Not much more needs to happen, beyond client
and server software, and administrative tools.

Multicast. A solution looking for a problem; a problem found, at last. :slight_smile:

Brian Dickson

2

You could do this, but if you did, it would no longer be IRC. It'd be
something else. You'd need new servers, new clients, etc.

Also, once the software is written, it'd probably be about as easy to
implement as EfNext.

--Adam

3

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. :slight_smile:

  Not quite. Sorry.

  --msa

4

AFAIK, there is no implemented multicasting protocol - routing and reliable
transport - that can scale to the number of groups, senders and receivers
visible in current IRC networks. Source-based trees would require the
order of 1E6 (S,G) pairs and core/RP-based routing would be an even easier
target for the SK's than IRC already is.

Achieving instant group messaging on a global scale with convential multicast
is unlikely. Relevant academic research continues.

J