On Tue, Jun 17, 2008 at 5:07 PM, David Miller [off-list ref] wrote:

The problematic case is when all 3 of tstamps, wscale, and md5 are
enabled.  To be honest, tstamps are the least valuable of the 3.  The
only way to accurately fill in gaps is to have at least some SACK
information, it is much harder to guestimate than RTTs.

So, have a population of Linux hosts out there which will send corrupt
packets when MD5+SACK is enabled. So we want to fix that problem all
at once, hopefully.

How's this:

If we receive a SYN packet with MD5 + SACK + TS was assume that it's
from an older kernel and reply with MD5 + TS. Not including SACK means
that it won't send us corrupt packets and since we couldn't previously
do SACK with these packets anyway, we're not loosing anything.

However, by default we send MD5 + SACK. If we are talking to an old
kernel, that means that they are sending corrupt packets if they have

2 SACK blocks (the current logic limits them to 4 I believe).

Hopefully this is pretty rare (and, again, better than we are
currently doing). It also means that we have MD5 + SACK between new
hosts, which is optimal.

I was actually writing a patch to implement
http://tools.ietf.org/html/draft-eddy-tcp-loo-03 (Long Options), which
involved pulling all the options logic into a single function for SYN
and one more for normal packets (rather than the duplication which we
have now). I'll probably send a draft patch for comments later today
(PST).

Pulling all the options logic together makes it a lot easier to make
these changes (once we've worked the bugs out of the change
initially). Possibly I should split it from the long options stuff and
make it a separate patch. It already solves this MD5+SACK bug and
other where MD5 signatures are accounted for twice in the MSS
calculations.

Cheers,


AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org