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

[Jason A. Donenfeld]

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

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.

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.

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.

So, of those concerned about this, which concerns are actually about
(2) and (3)? Of those, which ones are about (2)? If you have concerns
specifically about (2) that couldn't be fixed with reasonable system
administration, I'd like to hear why and what the setup is that leads
to that situation.

As an aside, Roman asked about TTL. When tunneling, the outer packet
header always must take the new TTL of the route to the tunnel
endpoint, and not do anything with the potentially much smaller inner
TTL. So with tunneling, you can't quite rely on the TTL to drop to
zero as you'd wish. Hence, I'm interested in using the natural packet
size expansion instead.

Thanks for the discussion so far. I'm very interested to read
clarifying points about applicability to case (2) (and to a lesser
extent, about case (3)).

Thanks,
Jason