Hi,
Talking about my example with chained VPNs. It is a misconfiguration but
not intentional, and no responsible administrator can solve this because
client really has no way to tell a VPN provider what MTU he needs.
Technically VP providers can make such interface for clients but none of
four VPN providers I've tried during the last three years has this.
Usually VPN providers just use a default ?wg-quick? MTU in their server
configs.
On the client side it is (2 local egress fragmentation), client knows
both of the MTU values, but on the server side it already needs (3 path
egress fragmentation). If I understand the terminology correctly. For a
packet on the route: remote host -> VPN provider 1 -> VPN provider 2 ->
client. An unecrypted packet comes form remote host, the VPN provider 1
just sends a bigger encrypted packet to the VPN provider 2 and even if
it responds with ICMP Fragmentation Needed to the VPN provider 1, it
will be ignored and would not be repeated in the unecrypted channel to
remote host. So the remote host will never know why the packet was
dropped and it will slow down PMTUD. How difficult it is and what
security implications it will have if WireGuard do capture ICMP
Fragmentation Needed responses and repeat them in unencrypted channel?
On 07.06.2021 12:34, Jason A. Donenfeld wrote:
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
