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