Re: Improved SYN Cookies: Looking for testers

On 12.07.2013 12:56, Fabian Keil wrote:
> Andre Oppermann <andre_at_freebsd.org> wrote:
>
>> On 10.07.2013 15:18, Fabian Keil wrote:
>>> Andre Oppermann <andre_at_freebsd.org> wrote:
>>>
>>>> We have a SYN cookie implementation for quite some time now but it
>>>> has some limitations with current realities for window scaling and
>>>> SACK encoding the in the few available bits.
> [...]
>>>>     http://people.freebsd.org/~andre/syncookie-20130708.diff
>>>
>>> I've been using the patch for a couple of days and didn't notice any
>>> issues so far. Privoxy's regression tests continue to work as expected
>>> as well.
>>
>> Thanks for testing and reporting back.
>>
>> Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1
>> as well to bypass the syn cache entirely?
>
> I haven't noticed any issues with net.inet.tcp.syncookies_only=1.

Excellent.

>> It will give a bit of debug log output which is it telling you mostly about
>> rounding to the next nearest index value.  You can send the output privately
>> to me to spot unexpected outliers, if any.
>
> One unexpected outlier seems to be:

Both errors are normal and a sign of lazy application behavior, not a TCP
error.

> Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data after socket was closed, sending RST and removing tcpcb

This error is not uncommon and happens when the server side has closed the
socket (and sent FIN) while the client side is still trying to send data.
As the server has closed the socket we can't the deliver the data anymore
and respond with a reset to let the client know.  It typically happens with
web servers and short keep-alive timeouts.

> Jul 11 12:42:51 r500 kernel: [10947] TCP: [10.0.0.1]:62972 to [10.0.0.1]:8118 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed)

This is the same situation after the previous line but after the inpcb was
cleared.  Now a second, final (because of the FIN), in-flight packet from
the client arrives at the listen socket because the original inpcb is gone
now.  Since there isn't a matching SYN cache entry it falls back to check
for a syn cookie which obviously fails.  Having a FIN segment reach syncache
is unusual but not wrong.  In theory one could send a SYN, receive the SYN-ACK
and respond with ACK-FIN in one packet if it carried all data to be sent and
the application did a socket write shutdown already.

> Client and server are running on the same system.
>
> As I don't usually use net.inet.tcp.log_debug and haven't been able to intentionally
> reproduce the issue (but have seen it a few times), I'm not sure yet if the behaviour
> is actually related to the SYN cookie changes at all.

It's "normal" behavior and not related to the SYN cookie changes.

-- 
Andre