Re: [tcpm] New I-D

John Heffner wrote:
> Mahesh Jethanandani wrote:
>> Context is the draft - 
>> http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt
>>
>> John Heffner wrote:
>>> As proof of concept, I wrote up a simple script (I think only about 
>>> 30 lines of python) that used the TCP ESTATS MIB to monitor 
>>> connections, and kill off ones making no progress while consuming 
>>> the most memory. This proved an effective defense against netkill, 
>>> and I think would solve the problem described in the draft as well.  
>>> It would be easy enough to write a kernel thread to do the same if 
>>> the system doesn't do ESTATS.
>>>
>>>   -John
>> John,
>>
>> The issue with Netkill or any other application trying to kill 
>> connections is that they cannot distinguish between connections that 
>> are held up because of network issues where packets are getting 
>> dropped and connections that are in persist state because the client 
>> refuses to open the zero window. TCP can distinguish between the 
>> connections and determine which ones need to go. Wouldn't you agree?
>>
>> m/
>
> That's going back a ways.  I think I've paged the original thread back 
> in to memory. ;)
>
> It may be important to distinguish between recovery and persist (the 
> ESTATS MIB will do this).  I mention netkill because it is pretty 
> effective at running the attacked system out of buffer memory without 
> using the persist state.  I think a more general defense is better 
> located at the operating system level (either a daemon or in the 
> kernel), since that is the point where resource contention is resolved 
> and policy enforced.
>
> Thanks,
>   -John
General defense - yes. Operating system can enforce a maximum number of 
resource allocation to TCP to prevent it from exhausting all the 
buffers. Let us further assume that the operating system enforces a per 
connection buffer utilization count.

Now suppose one was to write a resource contention daemon or do this as 
part of the kernel. What would be the information it would need? It 
would need per connection buffer utilization, how long the buffers have 
been on that connection, what is the state of the connection (assume it 
gets it from the MIB, which BTW gets it from TCP), how many times the 
connection has entered or exited this condition (in case someone is 
trying to fool the system), information that is part of TCP. So you can 
peek into the TCP connection table, extract all the information needed 
to make the determination or let TCP manage the buffers that it has 
borrowed from the operating system and is ultimately responsible for.

Without that intimate knowledge of each connection, I can think of at 
least two scenarios that can stump an operating system.

    * Large number of connections with one buffer each in persist
      condition, where the total number of buffers exceed the amount set
      as the upper limit set by the operating system. Without the OS
      knowing that the connection is in persist condition AND for how
      long (after all you do not want to whack a connection just because
      it entered persist condition), how does it determine if the
      connection should be torn down or not.
    * Fewer than a large number of connection mentioned above each in
      persist condition, where the numbers are short of the max. buffers
      per connection but the total number of buffers by all connections
      exceeds the max. count set by the OS for all of TCP. Now the
      sender can run out of buffers sooner and with fewer connection setups.

This all assumes that TCP always runs as part of an operating system. Is 
that assumption always true?