netdev - Re: [PATCH net-next 1/3] udp_tunnel: allow to turn off path mtu discovery on encap sockets

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: <20200714143327.2d5b8581@redhat.com>
Date:   Tue, 14 Jul 2020 14:33:27 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     Florian Westphal <fw@...len.de>
Cc:     David Ahern <dsahern@...il.com>, netdev@...r.kernel.org,
        aconole@...hat.com
Subject: Re: [PATCH net-next 1/3] udp_tunnel: allow to turn off path mtu
 discovery on encap sockets

On Mon, 13 Jul 2020 16:02:19 +0200
Florian Westphal <fw@...len.de> wrote:

> AFAICS everyhing functions as designed, except:
> 1. The route exception should not exist in first place in this case
> 2. The route exception never times out (gets refreshed every time
>    tunnel tries to send a mtu-sized packet).
> 3. The original sender never learns about the pmtu event
> 
> Regarding 3) I had cooked up patches to inject a new ICMP error
> into the bridge input path from vxlan_err_lookup() to let the sender
> know the path MTU reduction.
> 
> Unfortunately it only works with Linux bridge (openvswitch tosses the
> packet).  Also, too many (internal) reviews told me they consider this
> an ugly hack, so I am not too keen on continuing down that route:
> 
> https://git.breakpoint.cc/cgit/fw/net-next.git/commit/?h=udp_tun_pmtud_12&id=ca5b0af203b6f8010f1e585850620db4561baae7

To be honest, after considering other solutions, yours suddenly appears
to be a lot less ugly. :) Well, I don't think that abusing the "lookup"
functions to do something completely different is a good idea, but that
would be a minor change to do it in another place).

I would still like the idea I proposed better (updating MTUs down the
chain), it's simpler and we don't have to duplicate existing
functionality (generating additional ICMP messages). We could also
decide to skip decreases of MTU on the bridge if the user ever set a
value manually (keeping that existing mechanism as it is).

Both should cover cases with a regular bridge. However, it's still not
clear to me what either solution covers in terms of Open vSwitch. I
think it would be interesting to know before proceeding further.

-- 
Stefano