<div dir="ltr">I don't have an actual fix; but is something that could have a switch that could be configured per interface?  I know knobs and controls aren't really desirable, but if Off by default, it would encourage those turning it on to understand what they're exposing.<div><br></div><div>$0.02 </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 15, 2018 at 10:08 AM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi list,<br>
<br>
[CC'ing Luis, who's been working on this with me.]<br>
<br>
I've more or less figured out how to do PMTU discovery (something<br>
along the lines of <a href="https://xn--4db.cc/WFHQzX2o/c" rel="noreferrer" target="_blank">https://xn--4db.cc/WFHQzX2o/c</a> inspired by the vti<br>
driver). I wonder, however, if this is safe to do.<br>
<br>
The basic idea is that if you're talking to a WireGuard peer via its<br>
internal tunnel IP address, the kernel keeps some notion of what that<br>
internal IP address's PMTU is. Meanwhile, WireGuard itself is talking<br>
to that peer via its external endpoint IP address, and the kernel<br>
keeps some notion of what that external IP address's PMTU is. If the<br>
encrypted packets are larger than the external PMTU, well behaved<br>
networks will send ICMP messages, indicating that packets sent to that<br>
external endpoint IP should be smaller. This, however, doesn't have<br>
anything to do with what the user is trying to send internally, and so<br>
there will continue to be overly large packets sent.<br>
<br>
The way to fix it would be to relay the external endpoint PMTU to the<br>
internal tunnel PMTU. Then, when an external encrypted packet gets<br>
dropped due to being overly large, the ICMP message for that winds up<br>
affecting the internal tunneled IP address's PMTU, so that the next<br>
message it sends is smaller. All is well, packets flow, and TCP<br>
sessions no longer stall. This is generally how PMTU discovery works<br>
with network tunnels.<br>
<br>
The security problem is that those ICMP messages indicating we should<br>
send smaller packets are unauthenticated, since they're triggered by<br>
things external to the tunnel, rather than inside the tunnel. By<br>
propagating the information from those unauthenticated ICMP messages<br>
to state that concerns the inside of the tunnel, we're essentially<br>
enabling an unauthenticated state injection. This could enable some<br>
mischief. On the benign end of the spectrum, an attacker could launch<br>
a DoS attack by causing the sending end to use smaller and smaller<br>
packets. On the scarier end of the spectrum, an attacker could<br>
intelligently do this to change the size of packets and observe the<br>
way in which a data flow is rechunked, in order to infer something<br>
about the actual data being encrypted.<br>
<br>
These security concerns make me inclined to just simplistically<br>
declare, "PMTU discovery in tunnels can't be done securely with the<br>
existing Internet, so WireGuard doesn't support it." However,<br>
undoubtedly smart people have thought about this before, and perhaps<br>
they've come up with real solutions for this. Indeed I've come across<br>
various discussions of the matter in the IPsec RFCs. But at the<br>
present moment, I'm unsure what the most reasonable way forward is.<br>
<br>
So, I thought if anyone on the list has thought about this extensively<br>
before and would like to chime in with some wisdom, I'm all ears.<br>
<br>
Regards,<br>
Jason<br>
______________________________<wbr>_________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/<wbr>mailman/listinfo/wireguard</a><br>
</blockquote></div><br></div>