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+42gyHEALCjZZGjMWTLQsPgp191c4dfZYFffOL6iV7pwYHw@mail.gmail.com>
Date:	Wed, 10 Feb 2016 15:52:04 +0100
From:	Jesse Gross <jesse@...nel.org>
To:	Tom Herbert <tom@...bertland.com>
Cc:	David Wragg <david@...ve.works>,
	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 3:21 PM, Tom Herbert <tom@...bertland.com> wrote:
> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross <jesse@...nel.org> wrote:
>> 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.
>>
> Right, but if the user sets a bad value and packets are silently
> dropped on the floor then that seems like a bad result that could have
> easily been prevented.

Sure, we might as well prevent the extreme edge cases that can never
be valid. In the case of Geneve though, this would be the minimum
header size, not the maximum, since it's possible that the user
actually knows how big the options are that they want to use.

But as I said, the practical impact is low because IP_MAX_MTU is so
much larger than the MTU of real devices. There will always be many
values that the MTU can be set to that result in dropped packets. This
is true of all tunnel types.