tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Trimming TCP options



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


Home | Main Index | Thread Index | Old Index