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

Dickson, Brian brian.dickson at
Thu Jul 12 22:45:58 UTC 2001

> 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, Exodus, Verio, Sprint, AT&T, Global Crossing, Level
3, Ebone, ESnet, Qwest, etc. The total list (which can be seen at ) 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

Brian Dickson

More information about the NANOG mailing list