Re: [tcpm] Is this a problem?

[John Heffner <[e-mail]>]

Mahesh Jethanandani wrote:
> 
> 
> Ethan Blanton wrote:
>> Yes; however, I agree with Joe (and others) that in the situation you
>> are *actually* trying to solve, this is not particularly relevant.  If
>> you are short on resources, the distinction between "not making
>> progress due to zero window" and "not making progress for some other
>> reason" does not seem important.  As previously mentioned, zero window
>> does _not_ indicate a malicious host in any way.
>>   
> Where is the fairness argument in knocking connections off without 
> making distinctions? A connection that is not making progress because of 
> congestion in the network is a transient behavior and is very different 
> from a connection that continues to advertise a zero window. The former 
> is much harder to do and requires TCP stack changes. Zero window 
> connection can be made to happen on a whim (as we successfully did) on a 
> large number of connections from a user level program with little or no 
> privileges.

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.

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.


Also, I have a quibble with some of the language in the draft that I 
think reflects a view of where the solution must go:

    In most implementations, TCP runs in kernel mode as part of the
    operating system.  In this mode the operating system may share the
    same address space as TCP.  For the purposes of discussion, this
    draft considers TCP protocol implementation to be a separate module
    responsible for all resources such as buffers and connection control
    blocks that it borrows from the operating system.  The operating
    system can enforce the maximum number of buffers it is willing to
    give to TCP but beyond that it lets TCP decide how to manage them.

Even if you view TCP as running with an inaccessible address space, it 
can still export all sorts of information, in both standard (see RFC 
4022 and RFC 4898) and non-standard ways.  From a standards point of 
view, I think RFC 4898 exports all the necessary information.

And even if the solution must be implemented in an independent TCP 
module, this does not mean the solution should be defined and 
standardized as a transport layer mechanism.  A TCP module could 
implement a memory-based fairness policy if it's controlling its own 
memory pool as you describe.  This does not mean you need to change the 
definition of how the TCP protocol behaves in the persist state.

   -John


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