Re: TCP SYN Cookies for NetBSD

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> If the third packet of the three-way handshake (the pure ACK) is
>> lost, neither end is going to retransmit [...].  Thus, we have a
>> half-open connection.
> Yes, that situation is possible.  However I wouldn't go as far as to
> say a connection is "permanently" wedged as eventually the client or
> the server will attempt to transmit data,

The passive end won't because it doesn't have a connection yet, and
it's thrown away the only state that could have provoked it to
retransmit.  The client end might or might not, depending on the
protocol in question; there certainly is no reason to be confident all
protocols will have the active end sending something in the face of
silence from the passive end.

> a keepalive if the connection was never intended to transmit data,

Only if the active end has keepalives turned on (something which is out
of the control of the SYN-cookie-using passive end).

> or the connection will time out due to inactivity

If you're talking about TCP-level timeouts, this happens only if
someone has data to send.  If the active peer has data to send, you'll
get an RST, presumably relatively quickly, without need for any
inactivity timeout; the passive peer can't have data to send yet
because it doesn't have a connection yet.  Higher-level timeouts depend
on the protocol in use; there's no reason to assume they will all have
timeouts.

So, if the third packet of the handshake is lost, the best case is that
the connection gets shot down by an RST; the worst case is that it
mysteriously hangs forever.  And the things that can keep it from
hanging forever in the latter case are completely out of the control of
the peer with the broken code.

And, of course, both problems get worse as packet loss rates go up -
exactly the worst time to impose mysterious connection troubles.

> If an RST is generated the peer will do the right thing and clean up
> the connection.

How is that "the right thing"?  Letting the active peer think it has a
connection and then RSTing it as soon as it sends any data doesn't
strike me as a very right thing.

> This is obviously not ideal,

Well, of course not.  Ignoring the TCP spec isn't, not if you expect to
interoperate.  (This even fails the "what if everyone did it" test; the
interoperability failures occur even when it's talking to another such
implementation.)

> but as a method to avoid syn cache exhaustion (or to avoid creating a
> syn cache at all) I believe it is acceptable.

Not to me.  I would consider it a crippling bug if I saw such behaviour
from a TCP stack.

> I also believe leaving syn cookies as an option (compile time,
> sysctl, etc) for the user will give reasonable flexibility for people
> who don't like this tradeoff.

We can't force hosts to follow the spec, of course.  And we can't keep
people from hacking whatever brokenness they like into the kernel.  But
the spec exists to permit interoperability, and just because people can
break their systems is no excuse to hand them pre-broken systems - I
consider it a bug for a TCP stack to be that easy to break this way.

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