Improving Robustness of Distributed Services (Re: DDoS attack s)

Thu Jul 12 23:38:46 UTC 2001

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