Re: TCP connections clogging up accf_http(9) (was: ESTABLISHED sockets with no fd open?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 19 May 2016 22:12:32 -0400
    From:        Tyler Retzlaff <rtr%netbsd.org@localhost>
    Message-ID:  <b6cb0b45-36a2-1036-ee64-ad971579c661%netbsd.org@localhost>

  | if getsockopt(2) SO_KEEPALIVE is set for the peer socket then yes.

That would (might) work with some of the situations described (the laptop
that has been turned off) but is useless against an actual DoS attack, and
also against the most likely bug in HTTP clients (particularly new ones).

That is, as long as the remote system is still there with the TCP connection
alive and sends ACKs when requested, keepalive doesn't help at all.  Aside
from the deliberate attacker, the obvious way this could happen with
accf_http would be with a client that has "forgotten" that an empty line
is required to finish a GET/HEAD request, and sends what it thinks is
all it needs to send, and awaits a response.  The filter hasn't yet received
the complete request, nor is what it has received invalid, so it will not
pass the connection to the application.   We have a textbook deadlock, and
no way out (other than user intervention at one end or the other).   Sure,
caused by a bug, but aren't they all?

I agree with Timo, these filters should all have (configureable) timeouts
added (and they should default to something rational - for accf_http, about
5 minutes should be plenty - so that apps that have not yet learned how to
set the timeout still benefit).  Whether when the timeout goes off the
connection should simply be reset, or be passed to the application should
probably also be configurable [as part of setting the timeout] (with the
default being reset I would expect).

  | I'd normally expect the application to implement more meaningful timeout 
  | mechanisms given what it is doing/waiting for. I'd definitely expect it 
  | to be tuned for ~seconds rather than hours.

I'd agree, and the mechanism to allow it to do that is what is being
discussed.   Currently, at least as best I can see, there is none.

How to add a timeout mechanism (the API would be a new setcockopt() I'd
assume, that's not the issue) at the minute I have no idea though.

In a message I haven't yet quite received enough to quote properly
Thor (tls@) says ..

  |  I'm not seeing where your limit of 193 for the length of that queue
  |  is coming from,

Perhaps that's the listen() queue limit in the application he's using?

kre