Re: Trimming TCP options

[Mihai Chelaru <mihai.chelaru%ngnetworks.ro@localhost>]

Pe 04.01.2011 00:04, Chuck Swiger a scris:
> It's important to note that (most?) TCP stacks will resend SYN packets with 
> fewer TCP options set if the initial SYN request doesn't get answered in some 
> fashion.  To validate that your changes are working as expected, you should 
> tcpdump filtering for SYN packets and watch out for duplicate SYNs being sent.

Hi Chuck !

It's not NetBSD case, where by default all 3 retransmits will use the 
same options.

I modified this morning a little bit that code, and let initial syn and 
first retransmit with full options, the second retransmit with MSS 
option only and the last one with no options at all, and added some 
stats. Until now results look good:

        1072 connection requests
        1654 connection accepts
        2196 connections established (including accepts)
        2721 connections closed (including 47 drops)
        145 embryonic connections dropped
        400 SYN options degraded -> incremented at second syn re-xmit
        2 connected with no options -> connection established after 
second syn re-xmit

I'll keep an eye on the last counter in the following days.

> Hmm, I find it more useful to describe TCP options by strings representing the 
> options in the sequence they appear, which is the mechanism various OS 
> fingerprinting tools like NMAP, p0f, etc use.
>
> NetBSD: MNWSNNNT

It's even MNWSNNNNT (one more N).

> Cisco IOS (11, 12): M
> Cisco VPN concentrators: MNNS
> FreeBSD (4.x&  early 5.x): MNWNNT
> FreeBSD (5.3+, 6.x): MNWNNTNNS
> FreeBSD (7.x+): MNWST
> Linux: MSTNW (although MTWSN and others can appear)
> MacOS X: MNWNNTS (10.3 or older uses MNWNNT, similar to FreeBSD 4.x)

MNWNNTSNN or MNWNNTSE0 ?

> NMAP probes: WNMT
> OpenBSD: MNNSNWNNT (HP/UX 11.x also uses this)
> Solaris: NNTNWM
> Win 98/ME: MNNS
> Win 2000/XP SP2 or older: MNWNNS
> Win 2000 (Server variants)/2003/XP (SP3): MNWNNTNNS
>
> There can be a lot of variation depending on whether SACK, TCP timestamps, RFC 1323 extensions, etc 
> are enabled.  However, it was widely common to use "NNT" to ensure that the timestamp 
> would be 32-bit aligned; and somewhat common to use "NNS" for similar reasons (although 
> it shouldn't be required, as you've noted).
>
> The approach you're using of compressing the options as best you can, and then 
> adding TCPOPT_EOL(s) at the end to maintain the 32-bit alignment looks good.
>
> Regards,

Thanks,

--
Mihai