On Thu, Jul 12, 2001 at 06:45:58PM -0400, Dickson, Brian wrote:

I would not characterize it as such. I think it is currently close enough, so that if the folks who collectively pour their time and effort into IRC, were to coordinate on choices of (non-UUnet) upstreams that support multicast, and the remainder (those without alternatives) were to tunnel to the (now-mainstream) multicast core, the benefits would outweigh the costs.

There is an underlying assumption here that people who are running servers are also able to impact routing; i.e. Multicast and tunnels and whatnot. This was a real problem last time around. You've also made the assumption that samesaid people can affect transit choice. In my experience, there are many instances where this does not hold true.

...

With companies like UUnet charging outrageous rates for multicast support or refusing to support it at all, this will not change.

For good or bad, there generally aren't networks *like* UUnet. (Let's not go there.) But to my knowledge, no one else charges for multicast, separately.

UUnet has a large customer base. If you're suggesting that nobody that wants to do this use UUnet connectivity, that's fine. I just don't see it happening.

The global state info, consider it as a whole. Any of that info is either used for forwarding decisions (data plane), or not, ie for "administrative" purposes (eg identifying current users on a given channel), correct? (Info about other IRC servers I would categorize as data plane stuff).

Global state in IRC terms consists of things like user and channel modes. Channels themselves carry state (things like 'keys' [think of them as channel passwords] and 'bans' [restrictions on specific users]) that is used to authorize clients wishing to join a channel. There is no easy way to duplicate this in a pure multicast environment. You can use some sort of pre-authorization mechanism via TCP, that passes along group information, but you cannot base groups solely on multicast. And that's where the real problem comes in. Past experiments with removing or minimizing this sort of data result in total chaos as the kiddies take advantage of fewer restrictions on their behavior. In fact, it's been my experience that the reason servers get attacked is to disrupt this state.

The "other" state information, isn't part of the forwarding chain; if that were to remain on servers, and continue to be maintained via unicast TCP, there is no need to put all the other TCP/multicast stuff in.

And there is the rub. Fine. So we multicast the channel streams, but clients still communicate with the servers via unicast TCP. Thusly, your built-in-RPF argument is moot. The server's address is exposed, and gets hit with your everyday, run-of-the-mill unicast DDoS attacks. State information is lost, and eventually the state chain collapses -- now nobody has current state, and it will all need to be reflooded when the state server is available again. End result, complete and utter chaos. Not only that, since this state data continually changes on a per channel basis, every client has to have an open TCP session to their respective servers. We now have one open TCP session and N multicast streams, where N is the number of channels a client is present on. You have added several streams and layers of complexity without actually solving the problem.

So you would have a hybrid client, using TCP and servers for state info, and multicast/UDP for actual messages. Attacking the servers doesn't affect messaging, and any attack on part of the multicast tree, towards any particular goal (eg nuking a particular client's connection), will be transient in nature and either (a) close to the victim, thus limited in scope and number of affected clients, or (b) a moving target within the multicast-enabled infrastructure, and virtually impossible to disrupt for extended periods short of bandwidth-based attacks.

Loss of state means people will resort to traditional attacks; joining a channel and flooding it with meaningless text comes to mind. It also means that since there is no state dictating who can stop this sort of activity, it will happen in perpetuity. Filtering client-side does not stop the activity, and costs more bandwidth. IRC, as we currently know it, is irrevocably linked to its state. IRC servers are not being attacked to disrupt /messaging/, they are being attacked to disrupt state information. Typically, to reduce visibility of clients by fragmenting the network, to gain access to channels that one does not have access to otherwise, etc.

So how is this any better than the current status? Well, if a server dies for whatever reason, the communication pathways themselves are unaffected, only the convenience stuff. And since that gets propogated to other servers, client side software can select alternate servers for that information.

That 'convenience stuff' is the only reason IRC is usable; if you are not able to remove users from channels, or otherwise regulate access, you have completely and total anarchy. Ask anyone who has tried it.

Maybe I'm missing some fine points on how IRC is implemented.

I would suggest reviewing current and past server code, as well as spending a lot of time working with current production IRC networks, if you seriously intend on doing this. There is more involved than is immediately obvious.

If there is no interest in either stopping DDOS, or in a survivable IRC network, I'll stop contributing to this thread.

I'm all for stopping DDoS. But that will not be accomplished by making every application on the net multicast-based. That particular hammer is not the best way to tighten this screw.

I'd like DDOS activity to die off, but have no opinion or interest in IRC, per se. But I'd recommend those involved in IRC give this serious consideration.

Many people involved in IRC have given this serious consideration on more than one occaision and decided that in IRC's current form, this was not a workable solution. Do not be so foolish to assume that in the last 13 years of IRC, nobody has considered multicast as an alternative. I recall discussions and even running code as far back as 1995 and 1996. You may be able to build a workable communications system on multicast. That system will very definitely not be IRC any time soon. If you would like to build another AIM/ICQ/what have you, be my guest. --msa