Improving Robustness of Distributed Services (Re: DDoS attacks)
* 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. :-) Brian Dickson
On Thu, Jul 12, 2001 at 04:08:14PM -0400, Dickson, Brian wrote:
How difficult would it be to (a) implement, and (b) to migrate the users over to the new system?
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
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
On Thu, 12 Jul 2001, Dickson, Brian wrote:
- 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).
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
participants (4)
-
Adam McKenna -
Dickson, Brian -
Joshua Goodall -
Majdi S. Abbas