Re: [PATCH] NET: Add TCP connection abort IOCTL

[John Heffner <jheffner@psc.edu>]

Mark Huth wrote:
> 
> 
> David Miller wrote:
>> From: dagriego@gmail.com (David Griego)
>> Date: Tue, 27 Mar 2007 14:47:54 -0700
>>
>>  
>>> Adds an IOCTL for aborting established TCP connections, and is
>>> designed to be an HA performance improvement for cleaning up, failure 
>>> notification, and application termination.
>>>
>>> Signed-off-by:  David Griego <dagriego@gmail.com>
>>>     
>>
>> SO_LINGER with a zero linger time plus close() isn't working
>> properly?
>>
>> There is no reason for this ioctl at all.  Either existing
>> facilities provide what you need or what you want is a
>> protocol violation we can't do.
>>   
> Actually, there are legitimate uses for this sort of API.  The patch 
> allows an administrator to kill specific connections that are in use by 
> other applications, where the close is not available, since the socket 
> is owned by another process.  Say one of your large applications has 
> hundreds or even thousands of open connections and you have determined 
> that a particular connection is causing trouble.  This API allows the 
> admin to kill that particular connection, and doesn't appear to violate 
> any RFC offhand, since an abort is sent  to the peer.
> 
> One may argue that the applications should be modified, but that is not 
> always possible in the case of various ISVs.  As Linux gains market 
> share in the large server market, more and more applications are being 
> ported from other platforms that have this sort of 
> management/administrative interfaces.
> 
> Mark Huth

I also believe this is a useful thing to have.  I'm not 100% sure this 
ioctl is the way to go, but it seems reasonable.  This directly 
corresponds to writing deleteTcb to the tcpConnectionState variable in 
the TCP MIB (RFC 4022).  I don't think it constitutes a protocol violation.

As a concrete example of a way I've used this type of feature is to 
defend against a netkill [1] style attack, where the defense involves 
making decisions about which connections to kill when memory gets 
scarce.  It makes sense to do this with a system daemon, since an admin 
might have an arbitrarily complicated policy as to which applications 
and peers have priority for the memory.  This is too complicated to 
distribute and enforce across all applications.  You could do this in 
the kernel, but why if you don't have to?

   -John

[1] http://shlang.com/netkill/