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 ever,
> That's true, but relatively harmless, in that TCP (or the apps) need
> to have some mechanism to recover from this anyway, as it is a state
> that TCP can get into even without SYN cookies (a server that uses
> SYN cookies is no different from a server that has crashed just after
> sending the 2nd packet of the 3 way handshake, causing the 3rd
> packet, the ACK, to be lost, along with all state at the server).

Except that it's not; it's no different from a server that crashes
immediately after sending _every_ SYN|ACK packet - except it's a weird
sort of crash that manages to retain enough state to handle a third
packet that _doesn't_ get lost.  Or, equivalently, crashing whenever
the network path loses the third packet.

There's a (not unreasonable, I think) expectation that a crash loses
all state for all connections to the crashed host, and for a
significant time.  The pseudo-crash involved here exhibits neither of
those properties.

I would also think that appearing to have crashed (especially when it
hasn't) would be something you'd want to get rid of, rather than cause.
I never thought I'd see you (apparently) seriously saying that it's a
good thing to add code so that a host can appear to have crashed (and a
very unusual kind of crash, too, not what is normally called a crash)
on a condition as mild as a network path losing a packet.

/~\ 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