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: Is there a line of defense against Distributed Reflective attacks?

  • From: Christopher L. Morrow
  • Date: Fri Jan 17 13:40:32 2003


On Fri, 17 Jan 2003, John Kristoff wrote:

>  ---SNIP---
>
> It doesn't have to be forged, that step just makes it harder to
> trace back to the original source.  There are some solutions that
> try to deal with this, including an IETF working group called
> itrace.  UUNET also developed something called CenterTrack.  BBN

Wow, again.. Centertrack is a nice idea, but not feasible in a large scale
network... Aside from this, why would you tunnel 100kpps of attack traffic
anyway, why not just drop it, find the source and acl it there?

> has something called Source Path Isolation Engine (SPIE).  There

This would be cool to see a design/whitepaper for.. Kelly?

>   --- SNIP ---
>
> ECN cannot be an effective solution unless you trust all edge hosts,
> including the attacking hosts, will use it.  Since it is a mechanism
> that is used to signal transmitting hosts to slow down, attackers can
> choose not to implement ECN or ignore ECN signals.  Unless you could
> control all the ends hosts, and as long as there is intelligence in
> the end hosts a user could modify, this won't help.
>

Attacking hosts never behave nicely and rarely follow RFC's :) This is
another reason that things like rate-limits are only minutely effective at
stopping DoS attacks in a meaningful manner. (Unless you just want to
rate-limit all ICMP or something, which is a fine solution in some
instances, Jared@verio has written on this already)

> ---SNIP ---
>
> Many are reactive, often because you can't know what a DoS is until
> its happening.  In that case, providers can use BGP advertisements
> to blackhole hosts or networks (though that can essentially finish
> the job the attacker started).  If attacks target a DNS name, the

This is true, a blachole does finish the attackers job, but consider that
a very high number of attacks are on hosts with DNS names like:
dekadens.ghettot.org, death.hackmania.net, you.know.you.wanna.rapebob.com,
DEATHCRUSH.COM which are obviously just vhosts on a shell box. In these
cases no one really cares if the ip is blackholed, least of all the person
that owns the ip, he just wants to get back on his channel :)

> end hosts can change their IP address (though DNS servers may still
> get pounded).  If anything unique about the attack traffic can be

Almost all DoS tools will take a ip number for whom/what to attack, very
few will take a hostname and resolve it, once. NONE resolve for each
packet (or none today in normal use)... So, rotating to a new ip number
and dropping the attacked one is still a valid fix, provided your TTL
isn't more than a few minutes long.

> determined, filters or rate limits can be placed as close to the
> sources as possible to block it (and that fails as attack traffic
> becomes increasingly dispersed and identical to valid traffic).  If
> more capacity than attack traffic uses can be obtained, the attack
> could be ignored or mitigated (but this might be expensive and
> impractical).  If the sources can be tracked, perhaps they can be
> stopped (but large  number of sources make this a scaling issue and
> sometimes not all responsible parties are as cooperative or friendly
> as you might like).  There is also the threat of legal response, which
> could encourage networks and hosts to stop and prevent attacks in the

Legal response to the kiddies has never shown a marked improvement in
their behaviour. Much like the death penalty... its just not a deterrent,
perhaps because its not enforced on a more regular basis, perhaps because
no one thinks about that before they attack.

> future (this could have negative impacts for the openness of the net
> and potentially be difficult to enforce when multiple jurisdiations
> are involved).
>
> >From a proactive approach, hosts could be secured to prevent an
> outsider from using it for attack.  The sorry state of system
> security doesn't seem to be getting better and even if we had perfect
> end system security, an attacker could still use their own system(s)
> to launch attacks.  Eventually it all boils down to a physical

This is something else that bares some thought. Why all this dicussion
about 'isps should fix this' when 99% of the time its an end system
problem? Why not push back all this legal retoric on the system
manufacturers? Why not hold them responsible for the shoddy code and
workmanship? How is this any different than Ford and teir exploding gas
tanks? (yes.. bad example since it was the news group that made them
explode)

> security problem.  Pricing models can be used to make it expensive
> to send attack traffic.  How to do the billing and who to bill
> might not be so easy.   ...and there may always be a provider who
> charges less.  Rate limits can be used on a per source, per protocol
> or per flow basis.  Given enough hosts and not enough deployment in
> the network, this has yet to be effective.  Similarly, network
> based queueing mechanisms (e.g. RED), or pushback approaches already

While Steve Bellovin's idea for pushback is nice, I'm not sure its all
that practical. I don't see that its helpful if it turns off services
'automatically' :( Any automated security fix is subject to the classic:
"Oh now, ebay is attacking me now" syndrome :( People do really have to
interact for security incidents, and those people really do need a high
degree of clue.

> mentioned, which penalize or limit high rate flows are not widely
> deployed yet.

(see above, is this what you really want?)





Discussion Communities


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


Merit Network, Inc.