Re: [tcpm] DoS attack from misbehaving receivers

[Rob Sherwood <[e-mail]>]

On Mon, Feb 05, 2007 at 09:14:46PM -0500, Mark Allman wrote:
> Maybe I was not clear enough above.  I think I agree with you that
> detection on the sender-side is hard---although, a sender that is
> continuously pounding is actually quite noisy and getting only ACKs that
> acknowledge large amounts of sequence space is suggestive.

My confusion - I thought you were referring to detecting this on the
sender's side.  I agree that detecting the attack on the receiving
end is more straight forward, but it's not clear to me that relying
on receiver-side network operators to solve this problem is always
practical/desirable.  While this is a more philosophical argument,
it is a well established one in the DDoS literature: if your network
is under attack, you want to solve the problem locally, not depend on
operators at the source of the attack to solve it for you.  I consider
the issues with IP spoofing and the lack of pervasive egress filtering
a reasonable data point of why source-side solutions are not practical.
However, if this group feels that source-based prevention techniques
are sufficient, then I guess I should stop bugging you :-)

> I agree.  However, I can't believe you are actually suggesting using
> optacks to get 30KB/sec flows.  You don't need optack at that point.

I was suggesting that you need optack to get *many* 30KB/s flows, where
the total aggregate traffic is larger than possible without optack.  

> Three things ...
> 
>   + Optack is a secondary attack.  That is, a host will only do
>     optimistic ACKing once it has been compromised in some other
>     fashion.  So, saying that Slammer is somehow a bad example because
>     it is "small" is not quite right, IMO.
>
>   + I understand that one compromised machine can optack against
>     somewhat arbitrary servers.  (Although, note that you need to find
>     places to slurp from that actually have a reasonable amount of data
>     such that they could in fact impose a load on the network.)  But,
>     you are still going to be somewhat limited by the number of
>     compromised hosts you can bring to bear on the DDoS.

I think I've been unclear.  So if an attacker compromises K machines,
and uses them to optack attack N hosts, then you are saying that the
attack is limited because an attacker cannot make K big enough?  I think
I'm missing something, but my assumption was that this the attacker
would be launching this from a botnet, which there are studies that
show the existence of botnets on the order of 10K+ hosts and larger.
Having a K in the 10K range with any sort of amplification factor would
seem to be a significant threat to me.

Additionally, I'm assuming the reason this issue was brought back up (and
to this list) was that Michal Zalewski recently found a vulnerability in
deployed versions of Apache and IIS that allows for a malicious client
to request arbitrary data from a web server.  While this is not terribly
interesting in general, it means that every web server, not just those
with large files, are now potential optack targets.

http://www.securityfocus.com/archive/1/455833/100/0/threaded

>   + My point in bringing up Slammer is not that it is precisely the same
>     as what you are suggesting.  My point is that this was a case where
>     75K hosts were pounding the network as hard as they possibly could
>     and the core did not melt and there was no congestion collapse.  I
>     understand that you could theoretically bring more firepower to bear
>     on the network, but I am not sure that in practical terms you could
>     ever really do it.

Well, the short story is that I'm not 100% certain that the attack
is practical either.  My current research involves trying to decide
the attack's practicality  without actually running it.  This includes
some network topology mapping to evaluate the Internet's vulnerability
to optack and non-optack bandwidth flooding attacks, and simulations to
ensure that the attack is not self-limiting.  However, I think it is safe
to say that even if it is not practical to cause collapse in the core,
there is still danger to access links such that it is still worth while
spending time discussing possible solutions.

> What is the "deployability" issue?  That it cannot happen as quickly as
> a sender-only hack?  This all comes down to (1) do we think this is a
> problem that really needs to be addressed and, if so then (2) do we
> think this needs to be addressed immediately or would a cleaner approach
> that took a bit longer to engineer and deploy be fine?  I am not sure I
> even think this is a huge problem we are facing and so I am not in favor
> of short term hacks when we know how to do better.  I understand that we
> disagree on this point (which is fine).

So I have backed off of my original stance w.r.t (2) since our previous
conversation about this: the paper has been out for over a year now and
people are not exploiting this attack in the wild, so clearly there is
time to engineer a better solution if one is available.

That said, I maintain that any proper solution should only modify the
sender, where existing cleaner solutions modify both sender and receiver.
Because the change affects security, any New Solution should not be
optional or negotiated at connection time - both ends of the connection
need to support it, else the attack vector persists and the solution
accomplishes nothing.  It does no good to have a solution where the client
can just pretend to not support it.  If we require that all senders and
receivers implement New Solution, then it creates interoperability issues
with TCP implementations that do and do not yet support New Solution.
This is what I mean by the deployability issue.

- Rob
.

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm