netdev - Re: [PATCH net v2 2/3] geneve: Relax MTU constraints

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: <CAEh+42iGHk9zVYPcpSz5w5XPg450p8avuQLbMZZH+B5fZvF9WQ@mail.gmail.com>
Date:	Wed, 10 Feb 2016 12:59:20 +0100
From:	Jesse Gross <jesse@...nel.org>
To:	David Wragg <david@...ve.works>
Cc:	Tom Herbert <tom@...bertland.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	ovs dev <dev@...nvswitch.org>,
	David Miller <davem@...emloft.net>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Thomas Graf <tgraf@...g.ch>,
	Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net v2 2/3] geneve: Relax MTU constraints

On Wed, Feb 10, 2016 at 12:41 PM, David Wragg <david@...ve.works> wrote:
> Tom Herbert <tom@...bertland.com> writes:
>> The correct thing to do is determine the maximum amount of
>> encapsulation overhead that can ever be set in a packet and use for
>> setting the MTU. For instance, when RCO is enable in GUE, the size of
>> the option is included in tunnel->encap_hlen even though it will not
>> be used in all packets (via ip_tunnel_change_mtu). If there is no way
>> to determine a maximum overhead a priori from configuration, then
>> maximum overhead could be assumed to be maximum possible encapsulation
>> header size which for Geneve is 132 bytes IIRC.
>
> Ok, I'll come up with a patch to address this.

I don't think that this really applies in this situation. The concerns
here relate to what the MTU is actually set to but this patch affects
the range of MTUs allowed to be set by the user. I don't see a reason
to disallow the user from setting a precise value if they know what it
should be.

In any case, I don't think it is likely to have much impact. By
default with tunnels the output device is not fixed and therefore the
base MTU that is used is IP_MAX_MTU. Subtracting some tunnel overhead
amount from this is still likely quite a bit higher than any physical
MTU.

If you really want, I would subtract the base Geneve header size from
IP_MAX_MTU to get the true max but it's probably not a big deal in any
case.