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

[Nico Schottelius <nico.schottelius@ungleich.ch>]

Hey Jason,


Jason A. Donenfeld <Jason@zx2c4.com> writes:

> Hey folks,
>
> There seems to be a bit of confusion about *which* stage of
> fragmentation would be affected by the proposal, so I drew some
> diagrams to help illustrate what I'm talking about. Please take a
> look:
>
> https://data.zx2c4.com/potential-wg-fragmentation-proposal.png

I love the math: 2792 = 1420 + 1420 = 1500 + 1500

Joke aside, ...

> 1) Ingress fragmentation would not be affected by this and is not
> relevant for this discussion. This is the case in which a computer
> gets a packet for forwarding out of the wireguard interface, and it's
> larger than the interface's mtu, so the computer fragments it before
> passing it onto that interface. I'm not suggesting any change in this
> behavior.

I believe this is something wireguard cannot influence *anyway* as the
sending side can send any sized packet towards us.

> 2) Local egress fragmentation WOULD be affected by this and is the
> most relevant thing in this discussion. In this case, a packet that
> gets encrypted and winds up being larger than the mtu of the interface
> that the encrypted packet will go out of gets fragmented. In this
> case, we could likely respond with an ICMP packet or similar in-path
> error. But keep in mind this whole situation is local: it usually will
> only happen out of misconfiguration. The best fix for the diagram I
> drew would be for the administrator to decrease the MTU of the
> wireguard interface to 1412.

So how does that behave in the situation that the upstream interface or
routes change? Let's say WG MTU = 1412, original PMTU = 1500, decreases
to 1420. Would that reduce the WG mtu automatically to 1332? I guess
not. So what happens with packets arrive with size = 1420?

> 3) Path egress fragmentation COULD be affected by this, but doesn't
> have to be. In this case, we simply set "don't fragment" on encrypted
> egress packets, which means they won't be fragmented by other
> computers along the path.

That's true, but then it would be required to fragment them locally,
wouldn't it?

I'm trying to wrap my head around this in comparison to IPv6/IPv4: In
the IPv6 world we don't have fragmentation on the path, it's always
client based. In the IPv4 world routers can dis/re-assemble packets on
the way.

If I understand it correctly, you are somewhat suggestion that wireguard
behaves a bit like an IPv6 router, albeit for both the v6 and the v4
world. Is that comparison making sense somehow?

I think it would be easier to understand, if there was a demo case, a
sample tunnel that rejects packets, if fragmentation is needed. What
would be the appropriate ICMP message for an IPv4 packet that does not
include the DF bit?

So far, I'm not fully convinced the approach is a smart way, especially
not when it comes to handling network debugging and given that we do
already have a TTL that should be a loop prevention as well.

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch