From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: rcwhelan@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 59ee8b31 for ; Sun, 15 Apr 2018 15:30:56 +0000 (UTC) Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com [209.85.216.170]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id f02a0eae for ; Sun, 15 Apr 2018 15:30:56 +0000 (UTC) Received: by mail-qt0-f170.google.com with SMTP id a25so6574365qtm.1 for ; Sun, 15 Apr 2018 08:45:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Ryan Whelan Date: Sun, 15 Apr 2018 11:45:20 -0400 Message-ID: Subject: Re: PMTU Discovery Security Concerns To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="94eb2c1250002d07fa0569e4feb6" Cc: Luis Ressel , WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --94eb2c1250002d07fa0569e4feb6 Content-Type: text/plain; charset="UTF-8" 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 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 > --94eb2c1250002d07fa0569e4feb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have an actual fix; but is something that coul= d have a switch that could be configured per interface?=C2=A0 I know knobs = and controls aren't really desirable, but if Off by default, it would e= ncourage those turning it on to understand what they're exposing.
<= br>
$0.02=C2=A0

On Sun, Apr 15, 2018 at 10:08 AM, Jason A. Donenfeld <Ja= son@zx2c4.com> wrote:
Hi li= st,

[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 vt= i
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 th= e
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 acro= ss
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<= br> https://lists.zx2c4.com/mailman/listinfo/wire= guard

--94eb2c1250002d07fa0569e4feb6--