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

Mailman List Mirror (Read Only)
1

The implementation has already been done more than once. I spent a lot of

time playing around with this, years ago.

I did not know that. Thanks for the correction.

The main obstacles are:

1) Multicast is not nearly widely enough deployed to be used as a general

communications medium.

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.
Multihoming to get multicast may not cost much, if your total multicast
traffic is small. Keep in mind you only have one copy of a given multicast
stream, regardless of client base. Obviously, redundant multicast upstreams
is advisable, if it's an important part of your business.

The current folks doing multicast (and providing transit to those customers
of theirs doing multicst), at tier 1 and peering with each other, includes
the likes of Above.net, Exodus, Verio, Sprint, AT&T, Global Crossing, Level
3, Ebone, ESnet, Qwest, etc. The total list (which can be seen at
http://www.multicasttech.com/status/mbgp.sum ) may only total about 3% of
the AS's, but it's a very good 3%.

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.

If you give money to companies that do not support your efforts or
requirements, who is to blame? Act in a coordinate fashion, and either 701
will support free (or sanely priced) multicast, or you'll be a customer of
networks that already support it.

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.

I don't want to waste too much bandwidth on this (especially since I'm
neither an IRC admin nor user), but...

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).

In a multicast, true multicast, environment, the data plane would not
require *any* servers, per se. That is the important element of multicast
benefit. All the state info *for forwarding* would be kept on ISP router
infrastructure (yes, scaling is an issue, blah blah blah). Large (regional
or national) ISPs will generally have fully redundant and dynamic multicast
infrastructure, if multicast is deployed. (I'm talking MBGP/MSDP/PIM, not
DVMRP; redundacy include lots of RP's.) BTW, I know of what I speak; at my
previous employer (Teleglobe), we had deployed such an infrastructure
internationally and participated at the MIXs, and even provided multicast
transit for the multicast feed from the OSLO IETF.

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.

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.

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.

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

(3 and 4, security and deployment/conversion/porting - I acknowledged those
issues in my original message.)

If there is no interest in either stopping DDOS, or in a survivable IRC
network, I'll stop contributing to this thread.
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.

Brian Dickson

2

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