netdev - Re: [PATCH 3/3] [RFC] TCP syncookies: only allow 3 MSS values by default to mitigate spoofing attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 27 Aug 2013 15:52:21 +0200
From:	Jiri Bohac <jbohac@...e.cz>
To:	Florian Westphal <fw@...len.de>
Cc:	Jiri Bohac <jbohac@...e.cz>, Jakob Lell <jakob@...oblell.com>,
	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH 3/3] [RFC] TCP syncookies: only allow 3 MSS values by
 default to mitigate spoofing attacks

First of all - I don't really care about the default values as
long as they are tunable at run time. I'm fine with leaving the 8
valye MSS table as a default.

On Fri, Aug 16, 2013 at 11:31:01PM +0200, Florian Westphal wrote:
> Jiri Bohac <jbohac@...e.cz> wrote:
> > Rationale for the new values
> > - most packets are (1500 - headers); (1450 - headers) is not a huge waste and
> >   prevents fallback to much lower values
> 
> Still, 1410 seems weird.

I was thinking the path MTU would often be 1500 minus something
for various tunnelling/encapsualtion along the path. The packets
may have some options, so the 1450 was just a wild guess.

If we have only 3 differrent MSS values, I feel it is better to
waste 50 bytes on the "standard" 1500 MTU links instead of making 
packets with options and tunelled traffic fall back to something
like 500.

> > - clients will rarely send MSS below 536, so that's a safe fallback
> 
> Can you elaborate?
> You say 'is a safe fallback', yet it is removed in the patch?

Yeah, sorry,  I was writing the patch description before the patch
itself; I noticed the 512 in the original table and thought it
would be a good idea to keep this.

> > - we need to keep the minimum (64)

I don't know - I could imagine there is some embedded hardware
that can't do fragmentation and advertises very low MSS instead, for
example. I just felt removing this fallback could break things.
I'm not sure. 

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, SUSE CZ

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html