In some email I received from Andrew Brown, sie wrote:
> >>             client           NetBSD Firewall           server
> >>             ------          ----------          ------
> >>    1.        SYN----------- - - - - - - - - - ->
> >>    2.           <------------SYN-ACK(cookie)
> >>    3.        ACK----------- - - - - - - - - - ->
> >
> >Now, assume that the #3 packet is dropped.
> >
> >At this point, the firewall using cookies has no connection state.
> >
> >client is waiting for the server to send something.
> >
> >The client now hangs forever waiting for a packet which will never
> >arrive.

No, it doesn't.

> problem number 2: if the ack is not dropped, then this happens.
> 
> >   4.           - - - - - - -SYN--------------->
> >   5.           <- - - - - - - - - ------------SYN-ACK
> >   6.           - - - - - - -ACK---------------> 
> 
> which is where the actual server machine gets to respond and set up
> it's own connection end point.  the firewall machine will now have to
> do some form of connection laundering because odds are very much
> against the server responding to the client with the same isn that
> the firewall did.

The sucky part about all of this is you need to adjust the TCP checksum
for every packet where you alter the sequence number.  If you're already
doing NAT, then that's no biggie.  It's just extra work.

What gets me, about all of this, is that it just moves the resource
problem from one box to another and doesn't actually solve it.  To
this end, I can't see what difference it makes if the SYN-cookie
function is implemented in the end-host or the firewall.

Darren