Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better

[Joe Holden <jwh@zorins.us>]

On 2021-06-06 21:03, Roman Mamedov wrote:
> On Sun, 6 Jun 2021 11:13:36 +0200
> "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
> 
>> Specifically the change would be to not allow IP fragmentation of the
>> encrypted UDP packets. This way, in the case of a loop, eventually the
>> packet size exceeds MTU, and it gets dropped: dumb and effective.
>> Depending on how this discussion goes, a compromise would be to not
>> allow fragmentation, but only for forwarded and kernel-generated
>> packets, not not for locally generated userspace packets. That's more
>> complex and I don't like it as much as just disallowing IP
>> fragmentation all together.
>>
>> Pros:
>> - It solves the routing loop problem very simply.
> 
> Doesn't TTL already solve this?
> 
>> - Maybe people are running
>> wireguard-over-gre-over-vxlan-over-l2tp-over-pppoe-over-god-knows-what-else,
>> and this reduces the MTU to below 1280, yet they still want to put
>> IPv6 through wireguard, and are willing to accept the performance
>> implications.
> 
> Not only that. Sometimes transparent bridging of 1500 MTU LANs is required.
> 
> VXLAN does not allow tunnel endpoints to produce fragmented VXLAN packets.
> 
> With WG we can fragment them one level lower, *and* gain a higher efficiency
> compared to hypothetical VXLAN's fragmentation, due to less header overhead on
> 2nd and further packets in a chain.
> 
> It would be unfortunate if this will become no longer possible.
> 
> It appears to me that people who might need to transparently join multiple
> Ethernet LANs due to legacy network topologies they have to work with, weird
> requirements, various legacy software etc, would outnumber those who even run
> WG over WG at all, let alone getting themselves into a routing loop that way.
> 
All of the above, really - not allowing "full" sized frames over WG
breaks a huge number of use cases - even simple ones, because regardless
of how much it's wished to be true, in reality pmtu isn't very useful
and doesn't work for many cases even in an environment where it isn't
completely broken by firewalls/misconfiguration.

A [probably common] simple example is where there are 1500 byte speakers
on either side of a WG link (e.g. the internet, or some satellite site)
- having a <1500 byte link in the middle will break many applications,
in particular especially UDP based protocols.

Unfortunately the better solution is likely to make it configurable, or
allow fragmentation for forwarded traffic (since the host already knows
the mtu, this solves the problem without requiring any user config) -
although understandably you don't want to add more complexity

thanks