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

[Vasili Pupkin]

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
>