Re: [tcpm] Is this a problem?

[Mahesh Jethanandani <[e-mail]>]

John Heffner wrote:
> It's actually an easy and generally more effective attack to just drop 
> all the packets on the floor rather than continue ACKing with zero 
> window.  The connection will eventually time out, but it takes so 
> long, it's easy to initiate another one in this time to take its 
> place.  Once again, please look carefully at Stas's netkill: 
> <http://shlang.com/netkill/>.  It's a simple short perl script.  The 
> defense you are proposing does nothing for this attack.
That is true. The attack is very similar to the one we describe. It 
applies to a different state in TCP - FIN_WAIT_1. I would suggest that 
your attack is not just a "mbuf exhaustion" but also a TCP connection 
resource attack. It is possible to run either or both of them out. The 
defense we propose is specifically for connections in persist condition. 
We found it more tricky to simulate the situation you describe because 
it required the amount of data requested to fit in the receiver 
advertised window. In addition, it does have a timeout (albeit a long 
one) and requires more active clients to attack the server. However ...
>
> I don't think it's critical to determine whether a connection is 
> stalled while limited by cwnd or rwin.  This *may* be useful 
> information, but it's not the most important.  In my view, the more 
> important thing to know is (1) whether the connection is making 
> progress, and (2) how much memory (the contended resource) it is 
> using.   Using this information, you can implement a policy that 
> resets connections that are consuming resources with no benefit 
> (progress).  This solves the more general problem -- both the netkill 
> attack and a persist attack.
... our solution keeps track of connections that are in persist 
condition and keeps track of connections that are not making progress 
and consuming memory. The framework of the solution is amenable to 
include connections in FIN_WAIT_1 state.


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