[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TCP SYN Cookies for NetBSD
>> 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
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
Main Index |
Thread Index |