RST not emitted on listen backlog full?

[Thor Simon]

We've been doing some automated load testing and have noticed something
curious. When the TCP SYN cache code can't create a new socket for an
incoming connection because the listen backlog is full (128 max) there is
a call to tcp_respond which seems intended to cause a RST, but we never
see the RST hit the wire. We see no reason why and wonder if others have
noticed this (mis-)behavior.

This is with the netbsd-5 branch as of a couple of months ago.

[der Mouse]

Post by Thor Simon
We've been doing some automated load testing and have noticed
something curious. When the TCP SYN cache code can't create a new
socket for an incoming connection because the listen backlog is full
(128 max) there is a call to tcp_respond which seems intended to
cause a RST, but we never see the RST hit the wire. We see no reason
why and wonder if others have noticed this (mis-)behavior.

Well, quite aside from whether the code does what it is intended to do,
it seems to me that the actual behaviour is the right behaviour: if we
can't handle it now, but the reason could plausibly have gone away by
the time a retransmit happens (which it seems to me applies here), then
I'd say it's better to drop the packet and hope things are better when
we get the retransmit than to RST it.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

Post by Thor Simon
We've been doing some automated load testing and have noticed something
curious. When the TCP SYN cache code can't create a new socket for an
incoming connection because the listen backlog is full (128 max) there is
a call to tcp_respond which seems intended to cause a RST, but we never
see the RST hit the wire. We see no reason why and wonder if others have
noticed this (mis-)behavior.

Do you want to treat the listen backlog being full the same as if the port was closed?

Simply dropping the incoming SYN and letting TCP retransmit mechanism do another try later on, when perhaps the listen queue has room, seems to be a better choice.

However, if the SYN cache stuff has a lighter-weight entity handling the initial connections before creating the socket data structure once connection is established, it might be reasonable to reply with a SYN+ACK with window size = 0. The other side will periodically try to send probe packets with 0 or 1 byte of data, but you refuse to ack any more data until the listen queue has room, at which time you go ahead and allocate the socket, reply to the probe ack'ing the one byte (if sent) and setting a non-zero window size, and proceed with normal established behavior from there.

Regards,

[Chuck Swiger]

I think the behaviour (TCP RST vs retransit) needs to be sysctl'able, or setsockopt()able.

There's already SO_RCVTIMEO for setsockopt() which should be usable for the purpose on the client side...?

The thing is, RFC-793 is pretty clear about when to RST and when not to. You're supposed to RST connection attempt requests when you know they are invalid (ie, to a port which is closed and so forth); but there is nothing which suggests it's OK to RST for a valid connection attempt to an open port-- see the "SEGMENT ARRIVES" section.

Regards,

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think the behaviour (TCP RST vs retransit) needs to be sysctl'able,
or setsockopt()able.

A timely message back to the client that the connection will not proceed
permits the client to fall-over to another machine in it's list. Whether
or not that's the right message to send, is very much application
specific.

- --
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video

then sign the petition.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS+l5C4CLcPvd0N1lAQKh/Qf9ErECBXH9td/BPogJQJlpU9nQ/AdhEua8
bKhoXr3BobaftxmI8KJwZPnpQrm3FgP1Jrdhiub6Bkf2foeml9HxreqkRFEYr7DD
ruB2hpQTe7SqsC7CQQIj2C5o5Q18L9J+mtbhuMQUr/VcmDQglgtiBVUWZXCHZBZg
5oa09Hal4ABg6EppoUh4F1hO5JPwmgR8PyJ2dtPs9NMrwkxRK4PfrJr//I4vEs0a
40bLGjCYWu0vFFrByJqcrTYKx89ry95c9z1/YRVYCRyKs5FJVg1lL92nxxmwGs09
yZMwci18eBxe264GGLVNpREKhK6EMCnt100uH2kCNcIRYRosdsFViw==
=INHR
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven Bellovin]

Post by Chuck Swiger

I think the behaviour (TCP RST vs retransit) needs to be sysctl'able, or setsockopt()able.

There's already SO_RCVTIMEO for setsockopt() which should be usable for the purpose on the client side...?
The thing is, RFC-793 is pretty clear about when to RST and when not to. You're supposed to RST connection attempt requests when you know they are invalid (ie, to a port which is closed and so forth); but there is nothing which suggests it's OK to RST for a valid connection attempt to an open port-- see the "SEGMENT ARRIVES" section.

I mostly agree. The question is whether an RST is a better response if you're enduring a SYN flood attack. I suspect that the answer is that it doesn't matter much, since the bad guys will just keep sending, but it does bear a bit more thought.

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de