Re: [PATCH] Fix corrupt TCP packets when options space overflows with MD5SIG enabled (v2)

[Bill Fink <billfink@mindspring.com>]

On Tue, 17 Jun 2008, Adam Langley wrote:

> On Tue, Jun 17, 2008 at 5:07 PM, David Miller <davem@davemloft.net> 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 am not particularly familiar with the TCP MD5 option, but in googling
around I found the following at the end of Section 2.2 Transmission,
of RFC 4808, "TCP-MD5 Key Change", dated March 2007:

    "Note that there is an ambiguity when an acknowledgment is received
    for a segment transmitted with two different keys.  The TCP Timestamp
    option [RFC1323] can be used for disambiguation."

This would seem to imply, that at least in some scenarios, it would be
advisable to have TS enabled in conjunction with MD5.

						-Bill