netdev - Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B55D372.4020807@gmail.com>
Date:	Tue, 19 Jan 2010 10:44:50 -0500
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	Simon Arlott <simon@...e.lp0.eu>
CC:	netdev <netdev@...r.kernel.org>, Patrick McHardy <kaber@...sh.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data

Simon Arlott wrote:
> On Tue, January 19, 2010 09:17, William Allen Simpson wrote:
>> 2) There certainly *can* be data on SYN.  That code is already in
>> 2.6.33....
> 
> I could change the comment too, but the same logic applies when
> there is data and no MSS option - the packet can't be increased
> in size if it would then exceed 576 bytes and/or the destination
> MTU.
> 
Please change the comment.

If there is no MSS option, it should *not* be added, under *ANY*
circumstances.  That violates the end-to-end arguments (some call
them principles).

MSS isn't about the _destination_ MTU, it's about the *source*.
If you cannot guarantee you know the source MTU, there's no basis
for deciding the MSS.

While I understand that sometimes it's useful to reduce (never,
NEVER, *NEVER* increase) the MSS as a packet goes into a tunnel
(because there are problems in some NAT'd networks with determining
Path MTU via ICMP), I'm not aware of any circumstance where the MSS
would need to be reduced below 536.

I'm having some difficulty figuring out how this code originated --
with a nice log entry explaining the exact manufacturer's device
and network topology that the contributor had in mind?

> If it's possible to know that the packet can have an additional
> option added without exceeding MTU then this could be changed.
> The data part would need to be moved to make space at the end of
> the header.
> 
No options should be added to TCP in a router -- ever!
--
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