Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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)

  • From: Chris Roberts
  • Date: Thu Jul 12 07:26:41 2001

On Thu, Jul 12, 2001 at 12:13:17PM +0300, Aleksi Suhonen wrote:
> 
> 
> Hello,
> 
> I've been involved in running part of another IRC network and
> I've been trying to find reasonable ways to immunize networks
> to DoS attacks. The reasoning behind this quest is that if
> there is no way to deny the service, then the attacker shouldn't
> have a reason to even try.
> 
> I think this is relevant content for this mailing list because:
> 
> * Most of DoS attacks are against IRC networks. Hence, if we can
>   get rid of those, the health of the Internet as a whole should
>   improve.
> * Experience gathered with this approach should be useful to
>   developers and administrators of other distributed services
>   and protocols.
>   (e.g. usenet news, web cache heirarchies, DNS, BGP, ... YMMV)
> 
> 
> 
[...]

I've seen a few suggestions bounced around about way to protect the
inter server links.

Most of the suggestions brought forward revolve around hiding the server
to server links, to make them difficult targets to attack - running
server-to-server links over IPv6 (which is allegedly now as easy to DoS
as IPv4, unfortunately), running them over IPSec w/ private IP addresses
et al. Unfortunately, finding private peering and such for IRC servers
would be a very costly way to go - and not one that's attractive to many
of the educationals/ISPs/private parties that run for the most part,
non-revenue generating IRC services. 

There are a few other ways to protect your client servers semi-simply -
move them into a seperate block - which you can easily stop announcing
globally - or even just announce to only those peers with whom you peer
IRC, or those peers whose customers you allow to use your IRC server.
The latter of these would work well for large IRC networks with many
servers, as it controls exactly which servers people can use. 

Unfortunately though, I've still not found an elegant solution to
these problems that doesn't also remove the service, or still rely
on shipping the traffic across your borders.

To a certain extent, contacting your transits works to get attacks
stopped. I've certainly had good experiences with at least Cable
and Wireless, Teleglobe, and Genuity. But even then, the time from
attack starting to getting traffic filtered can be in the region of 30
minutes to an hour, and this only stops the traffic coming through your
transits. Peers are another matter entirely, and since even one or two
IXPs can result in the order of 400-500 peers, there's generally no
possible way to call all of them in a short timeframe.

Question for the list:
Does anyone have good or bad experiences with mailing lists containing
all of your transits, and peers NOC addresses, and using these kinds
of lists to contact / request filtering on mass? How do people
on the relevant NOC lists feel about this kind of situation?

Cheers,
Chris.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.