Re: TCP SYN Cookies for NetBSD

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

    Date:        Mon, 5 Nov 2012 22:26:59 -0500 (EST)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201211060326.WAA17541%Sparkle.Rodents-Montreal.ORG@localhost>

  | Except that it's not; it's no different from a server that crashes
  | immediately after sending _every_ SYN|ACK packet

No, only the ones where the returning ACK is lost by the network.
That is, it is the same as a server that crashes sometimes.   That's
every server...

  | Or, equivalently, crashing whenever
  | the network path loses the third packet.

The point isn't how usual this is at the server end, or even how realistic
- just that at the client end, which is the only place it matters, something
needs to handle this situation anyway, as it can happen with any TCP
implementation at the server.

  | There's a (not unreasonable, I think) expectation that a crash loses
  | all state for all connections to the crashed host,

No, that is an unreasonable assumption.   You're assuming that TCP is
in the kernel, and only a complete system crash loses state.   Nothing
in TCP assumes that, though it is the normal environment today.   However,
early implementations had most of TCP as part of the application (just
port de-multiplexing common) a simple application bug and crash would kill
a single connection while leaving others alive.   It isn't even impossible
for an implementation to have had a bug where a timeout after sending the
SYN+ACK (which should retransmit that in cases where the returning ACK
was lost) to be the very place where the bug exists, causing the app to
crash every time this happens...

  | and for a significant time.

Again, not true if you're assuming the a system reboot is required, and
only on systems where things like loading many MB's from slow storage, and
file system checks, etc, are required - other systems reboot from rom, and
have no modifiable data storage, and can reboot complely within microseconds.

Further, other ancient implementations had TCP offloaded in the network
"card" - a simple reset of that device would lose all TCP state, but be
very quick indeed.

  | The pseudo-crash involved here exhibits neither of those properties.

And even if that were true, it is irrelevant.   It isn't what is visible
at the server (or other clients) that matters to TCP, but only what iss
een, and done, at the remote end of the (each) individual peer connection
affected.

  | 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.

You know that's not what I was saying.   What I said, was that this is
not some horrible violation of the TCP spec that can be expected to cause
all kinds of problems for client implementations (the way you suggested)
and so must be avoided at all costs.   Rather it is something that the
clients need to be able to handle anyway.   And like all rare events
that don't often get tested (in TCP or anywhere else) forcing testing
and correction of any defects found, isn't a bad thing either.

I agree with apb, and what seems to be je's intent as well, that the
actual implementation would be better if it only drops the syn cache use
when that overflows, rather than removing it completely - but either way,
the clients (including NetBSD TCP clients of course) must be prepared to
deal.   And I do think it is better than even when the syn cache overflows,
the server attempt to keep making connections when possible (when the
network doesn't drop the retuirning ACK) rather than simply resetting
all later attempts - that's much better DoS defence.

kre