Improving Robustness of Distributed Services (Re: DDoS attacks)

Aleksi Suhonen nanog-poster at axu.tm
Thu Jul 12 09:13:17 UTC 2001


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)



Protecting the network can be divided into two parts:

Protecting network links and protecting client servers. There
are a lot of well known ways to protect client servers and
someone else can write about that. But apart from myself, I
haven't observed anyone trying to protect network links.
This I find surprising since it is often the links that the
abusers are specifically trying to attack.

The way I feel major inter server links should be protected
is that they should be moved "out of band."

They could for example be moved into permanent virtual circuits
with a few megabits of guaranteed bandwidth per second. Since this
protocol does not use a fully meshed network, but only an
acyclic subset of it, most of the reserved bandwidth would
be available for use by other services. In essence, using this
dedication wouldn't use up any more bandwidth in the backbones
than the current way of running links over the public Internet.
It would just make sure that these critical links couldn't
be caused to flap by denying their bandwidth.

If resources exist and are readily available, the inter server
links could maybe even be assigned a real dedicated circuit.



Wrt. the applicability of this approach to other distributed
services and protocols: It was just yesterday that I was talking
with a friend about BGP transit and peering practises (in general)
and one of the things I mentioned was that I would like to see
the practise of separating the BGP transit session on its own
circuit apart from the transit circuit being deployed more widely.

This would not be such a bad idea at exchanges either. In some
cases it might have very apparent uses for purposes other than
DoS resistance as well:

With the emergence of exchanges for multiple different "Internet
Commodities" (IPv4, IPv4 MBone, IPv6, ...) many of the exchanges
have a separate shared medium (often just a VLAN) for each of
the exchanged protocols.

I don't find debating about the reasons of separating them or not
at this stage of hardware, software and protocol maturity useful.
I'm just stating that this is one of the current practises.

Now, what operators - that are capable of carrying all the
protocols over a single infrastructure - could do at these
exchanges is that they could run peering their sessions for all
the protocols in one and work similar magic with the next-hop
addresses etc. as in the transit session case above. The
exchange point could provide a separate out of band shared
medium over which the operators could run these peering sessions.
This would simultaneously increase network stability by making
the BGP sessions themselves impervious to attacks.



These approaches of course require more complex configuration,
more thought, more clue when debugging, and generally more
everything, but I find that nothing new.


Kindest regards,

--
        Aleksi Suhonen / Axu TM Oy
        Internetworking Consulting
        http://www.axu.tm/

PS. Of the people that flamed the original poster, tell me which
were ones that didn't have any kind of affiliation with the
provider that the original poster had trouble with?

There was a time when they weren't the ones to effectively say
"We are the phone company. We don't care. We don't have to."



More information about the NANOG mailing list