netdev - Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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]

Date:   Wed, 28 Sep 2016 03:48:41 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     parameswaran.r7@...il.com
Cc:     kleptog@...na.org, jchapman@...alix.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, nprachan@...cade.com,
        rshearma@...cade.com, dfawcus@...cade.com,
        stephen@...workplumber.org, acme@...hat.com, lboccass@...cade.com
Subject: Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay
 L2

From: "R. Parameswaran" <parameswaran.r7@...il.com>
Date: Tue, 27 Sep 2016 12:17:21 -0700 (PDT)

> Later, in vxlan_dev_configure(), called from vxlan_dev_create(), it gets 
> adjusted to account for the headers:
> 
> vxlan_dev_configure():
> ...
>  if (!conf->mtu)
>                         dev->mtu = lowerdev->mtu - (use_ipv6 ? 
> VXLAN6_HEADROOM : VXLAN_HEADROOM);
> 
> 
> where VXLAN_HEADROOM is defined as follows: 
> 
> /* IP header + UDP + VXLAN + Ethernet header */
> #define VXLAN_HEADROOM (20 + 8 + 8 + 14)
> /* IPv6 header + UDP + VXLAN + Ethernet header */
> #define VXLAN6_HEADROOM (40 + 8 + 8 + 14)

Right but I don't see it going through the effort to make use of the
PMTU like you are.

I have another strong concern related to this.  There seems to be no
mechanism used to propagate any PMTU events into the device's MTU.

Because if there is a limiting nexthop in the route to the other end
of the UDP tunnel, you won't learn the PMTU until you (or some other
entity on the machine) actually starts sending traffic to the tunnel's
endpoint.

If the PMTU events aren't propagated into the tunnel's MTU or similar
I think this is an ad-hoc solution.

I would suggest that you either:

1) Do what VXLAN appears to do an ignore the PMTu

2) Add code to handle PMTU events that land on the UDP tunnel
   socket.

Thanks.