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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200718085645.7420da02@elisabeth>
Date:   Sat, 18 Jul 2020 08:56:45 +0200
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Florian Westphal <fw@...len.de>, 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 Fri, 17 Jul 2020 09:04:51 -0600
David Ahern <dsahern@...il.com> wrote:

> On 7/17/20 6:27 AM, Stefano Brivio wrote:
> >>  
> >>> Note that this doesn't work as it is because of a number of reasons
> >>> (skb doesn't have a dst, pkt_type is not PACKET_HOST), and perhaps we
> >>> shouldn't be using icmp_send(), but at a glance that looks simpler.    
> >>
> >> Yes, it also requires that the bridge has IP connectivity
> >> to reach the inner ip, which might not be the case.  
> > 
> > If the VXLAN endpoint is a port of the bridge, that needs to be the
> > case, right? Otherwise the VXLAN endpoint can't be reached.
> >   
> >>> Another slight preference I have towards this idea is that the only
> >>> known way we can break PMTU discovery right now is by using a bridge,
> >>> so fixing the problem there looks more future-proof than addressing any
> >>> kind of tunnel with this problem. I think FoU and GUE would hit the
> >>> same problem, I don't know about IP tunnels, sticking that selftest
> >>> snippet to whatever other test in pmtu.sh should tell.    
> >>
> >> Every type of bridge port that needs to add additional header on egress
> >> has this problem in the bridge scenario once the peer of the IP tunnel
> >> signals a PMTU event.  
> > 
> > Yes :(
> 
> The vxlan/tunnel device knows it is a bridge port, and it knows it is
> going to push a udp and ip{v6} header. So why not use that information
> in setting / updating the MTU? That's what I was getting at on Monday
> with my comment about lwtunnel_headroom equivalent.

If I understand correctly, you're proposing something similar to my
earlier draft from:

	<20200713003813.01f2d5d3@...sabeth>
	https://lore.kernel.org/netdev/20200713003813.01f2d5d3@elisabeth/

the problem with it is that it wouldn't help: the MTU is already set to
the right value for both port and bridge in the case Florian originally
reported.

Also, given the implications on overriding configured MTUs, and
introducing (further) IP logic into the bridge, if Florian's idea of
injecting ICMP messages could be implemented in a generic function:

On Wed, 15 Jul 2020 16:33:56 +0200
Florian Westphal <fw@...len.de> wrote:

> Yes, it might be possible to move the proposed icmp inject into
> skb_tunnel_check_pmtu() -- it gets the needed headroom passed as arg,
> it could detect when device driver is in a bridge and it already knows
> when skb has no dst entry that it a pmtu change could be propagated to.

I think that would be preferable: then it's fixed for all tunnels in a
generic, probably simpler way, without those two issues.

But then again, we're talking about Linux bridge. Unfortunately this
doesn't fix the problem with Open vSwitch either.

-- 
Stefano