|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Improving Robustness of Distributed Services (Re: DDoS attacks)
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
|