[e2e] TCP-SYN and delayed TCB allocation

[David Borman]

> > B) has it been modified that it is now done after the 1st ACK?

It all depends on what OS you are talking about...  FreeBSD makes use
of the syncaching code that I wrote back in the days of the the original
SYN flood attacks.  They now use it for all their incoming connections,
so only minimal state is kept for connections in SYN-RCVD state.  When
the ACK is received in response to the SYN,ACK, the full blown TCP is
created.

However, since the original syncache code was only used when the normal
mechanism overflowed, it did not do any SYN,ACK retransmissions for
connections in the syncache.  But since FreeBSD now sends all their
connections through the SYN cache, they had to add timers so that they
can do SYN,ACK retransmissions out of the syncache.  But that means
that during a real synflood attack, they are doing more work sending
out SYN,ACK retransmissions for all those bogus connections.  And for
most connections, you are eventually going to create a full blown
TCB anyway, so there really isn't any cost savings in defering the
full TCB creation until transition from SYN-RCVD to ESTABLISHED.
BSD/OS still uses the standard creation of a full TCB block when
a SYN is received, and only when that queue overflows do connections
get created in the syncache, and we don't do SYN,ACK retransmissions
out of the syncache.  So, we can hang valid connections in the syncache
if our SYN,ACK is received by the other side, but the returning ACK is
lost.  (If our SYN,ACK is lost, the other side will retransmit the
SYN, causing us to generate another SYN,ACK).  But when you are under
attack, I figure its better to be able to maintain connectivity for
the majority of the valid connections, rather than buckle over and
die.

> > if not, any reason why not B? we would so the same if we had a
> > "NAT/Firewall" with delayed binding etc
>
> If B), where do you put the data that could have been sent in the SYN?
> I'm not sure you can ACK the SYN without ACKing the data therein (though
> you don't deliver it until receiving the ACK and transitioning to
> ESTABLISHED)...

As long as you don't ACK the data, you don't need to save it.  Throw
away the data and just ACK the SYN.  The other side will have retained
a copy of the data, and will have to retransmit it.  Slow, but it will
work.
			-David Borman