From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: z@zenit.ru Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 467d2e2f for ; Thu, 18 Jan 2018 11:26:54 +0000 (UTC) Received: from xenia.zenit.ru (xenia.zenit.ru [194.186.83.3]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8e9beb3e for ; Thu, 18 Jan 2018 11:26:53 +0000 (UTC) Received: from [172.20.100.100] (agbar.zenit.ru [172.20.100.100]) by xenia.zenit.ru (Postfix) with ESMTPSA id 5C5688223C for ; Thu, 18 Jan 2018 14:30:19 +0300 (MSK) To: WireGuard mailing list From: Vadim Zotov Subject: passtos patch Message-ID: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> Date: Thu, 18 Jan 2018 14:30:18 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CEED63D73E59CC3CCEF14EBA" List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------CEED63D73E59CC3CCEF14EBA Content-Type: multipart/alternative; boundary="------------5C6FA63CC362ED6C3541296B" --------------5C6FA63CC362ED6C3541296B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sCgppbiBzb21lIGNpcmN1bXN0YW5jZXMgaXQgaXMgaW1wb3J0YW50IHRvIHNldCB0 aGUgVE9TIGZpZWxkIGluIHR1bm5lbApwYWNrZXQgZXF1aXZhbGVudCB0byBwYXlsb2FkIHBh Y2tldCBUT1MuCgpmb3IgZXhhbXBsZSwgb3VyIHByb3ZpZGVyIHN1cHBvcnRzIHRocmVlIGRp ZmZlcmVudCBTTEFzLCBkZXBlbmRpbmcgb24KcGFja2V0IFRPUyBmaWVsZCwgd2l0aCBkaWZm ZXJlbnQgaml0dGVyLAoKcGFja2V0IGxvc3MgYW5kIHNlcnZpY2UgYXZhaWxhYmlsaXR5LiBJ biBjdXJyZW50IHJlbGVhc2Ugd2lyZWd1YXJkCmFsd2F5cyBzZXQgdG9zIHRvIDAuCgpUaGlz IHBhdGNoIHNvbHZlcyB0aGF0IHByb2JsZW0uCgoKLS0tIHNlbmQuYy5vcmlnIDIwMTctMTAt MTcgMjA6MjY6MjkuMDAwMDAwMDAwICswMzAwCisrKyBzZW5kLmPCoMKgwqDCoMKgIDIwMTgt MDEtMDggMTU6MTA6MjUuMzY0NDI4MTA5ICswMzAwCkBAIC0zMDIsNyArMzAyLDcgQEAKwqDC oMKgwqDCoMKgwqDCoCAqIGFsbCBvZiB0aGUgcGFja2V0cyBpbiB0aGUgcXVldWUuIElmIHdl IGNhbid0IGFzc2lnbiBub25jZXMKZm9yIGFsbCBvZiB0aGVtLArCoMKgwqDCoMKgwqDCoMKg ICogd2UganVzdCBjb25zaWRlciBpdCBhIGZhaWx1cmUgYW5kIHdhaXQgZm9yIHRoZSBuZXh0 IGhhbmRzaGFrZS4gKi8KwqDCoMKgwqDCoMKgwqAgc2tiX3F1ZXVlX3dhbGsgKCZwYWNrZXRz LCBza2IpIHsKLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUEFDS0VUX0NCKHNrYikt PmRzID0gaXBfdHVubmVsX2Vjbl9lbmNhcCgwIC8qIE5vIG91dGVyClRPUzogbm8gbGVhay4g VE9ETzogc2hvdWxkIHdlIHVzZSBmbG93aS0+dG9zIGFzIG91dGVyPyAqLywgaXBfaGRyKHNr YiksCnNrYik7CivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBBQ0tFVF9DQihza2Ip LT5kcyA9CmlwX3R1bm5lbF9lY25fZW5jYXAoaXB2NF9nZXRfZHNmaWVsZChpcF9oZHIoc2ti KSkgJiB+SU5FVF9FQ05fTUFTSywKaXBfaGRyKHNrYiksIHNrYik7CsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBQQUNLRVRfQ0Ioc2tiKS0+bm9uY2UgPQphdG9taWM2NF9pbmNf cmV0dXJuKCZrZXktPmNvdW50ZXIuY291bnRlcikgLSAxOwrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgaWYgKHVubGlrZWx5KFBBQ0tFVF9DQihza2IpLT5ub25jZSA+PQpSRUpF Q1RfQUZURVJfTUVTU0FHRVMpKQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIGdvdG8gb3V0X2ludmFsaWQ7Cgo= --------------5C6FA63CC362ED6C3541296B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

in some circumstances it is important to set the TOS field in tunnel packet equivalent to payload packet TOS.

for example, our provider supports three different SLAs, depending on packet TOS field, with different jitter,

packet loss and service availability. In current release wireguard always set tos to 0.

This patch solves that problem.


--- send.c.orig 2017-10-17 20:26:29.000000000 +0300
+++ send.c      2018-01-08 15:10:25.364428109 +0300
@@ -302,7 +302,7 @@
         * all of the packets in the queue. If we can't assign nonces for all of them,
         * we just consider it a failure and wait for the next handshake. */
        skb_queue_walk (&packets, skb) {
-               PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0 /* No outer TOS: no leak. TODO: should we use flowi->tos as outer? */, ip_hdr(skb), skb);
+               PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(ipv4_get_dsfield(ip_hdr(skb)) & ~INET_ECN_MASK, ip_hdr(skb), skb);
                PACKET_CB(skb)->nonce = atomic64_inc_return(&key->counter.counter) - 1;
                if (unlikely(PACKET_CB(skb)->nonce >= REJECT_AFTER_MESSAGES))
                        goto out_invalid;

--------------5C6FA63CC362ED6C3541296B-- --------------CEED63D73E59CC3CCEF14EBA Content-Type: text/x-patch; name="passtos.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="passtos.patch" --- send.c.orig 2017-10-17 20:26:29.000000000 +0300 +++ send.c 2018-01-08 15:10:25.364428109 +0300 @@ -302,7 +302,7 @@ * all of the packets in the queue. If we can't assign nonces for all o= f them, * we just consider it a failure and wait for the next handshake. */ skb_queue_walk (&packets, skb) { - PACKET_CB(skb)->ds =3D ip_tunnel_ecn_encap(0 /* No outer TOS: no leak.= TODO: should we use flowi->tos as outer? */, ip_hdr(skb), skb); + PACKET_CB(skb)->ds =3D ip_tunnel_ecn_encap(ipv4_get_dsfield(ip_hdr(skb= )) & ~INET_ECN_MASK, ip_hdr(skb), skb); PACKET_CB(skb)->nonce =3D atomic64_inc_return(&key->counter.counter) -= 1; if (unlikely(PACKET_CB(skb)->nonce >=3D REJECT_AFTER_MESSAGES)) goto out_invalid; --------------CEED63D73E59CC3CCEF14EBA-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: me.kalin@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id ad1923d7 for ; Thu, 18 Jan 2018 11:53:49 +0000 (UTC) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id a273c3be for ; Thu, 18 Jan 2018 11:53:49 +0000 (UTC) Received: by mail-ot0-f172.google.com with SMTP id x15so19837259ote.0 for ; Thu, 18 Jan 2018 03:57:16 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> From: Kalin KOZHUHAROV Date: Thu, 18 Jan 2018 12:56:55 +0100 Message-ID: Subject: Re: passtos patch To: Vadim Zotov Content-Type: text/plain; charset="UTF-8" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jan 18, 2018 at 12:30 PM, Vadim Zotov wrote: > in some circumstances it is important to set the TOS field in tunnel packet equivalent to payload packet TOS. > for example, our provider supports three different SLAs, depending on packet TOS field, with different jitter, > packet loss and service availability. In current release wireguard always set tos to 0. > Yep, I completely agree to "in some circumstances" :-D I am not sure how copying the TOS field can be exploited, I guess it is one of those things "potential hazard, use KISS, avoid till needed AND assessment can be made"... Copying the field straight (in plain-text in a way), will provide some see-through-the-tunnel, which WG is designed NOT to allow, AFAIK. There are no optional parameters/options in wireguard (well, except fwmark), but I guess that one should be implemented as an option, at least at first. But again, that contradict KISS principle... Since this is not a common scenario, IMHO, and there are only a handful TOS worth doing something, a workaround would be to bunch a few wg tunnels (even bridge them at both ends?), use fwmark and mangle the TOS with iptables/ift... Just a suggestion, not tried obviously. Regards, Kalin. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: matthias@urlichs.de Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3ed33325 for ; Thu, 18 Jan 2018 13:00:46 +0000 (UTC) Received: from netz.smurf.noris.de (mail.smurf.noris.de [213.95.149.21]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id f9be5240 for ; Thu, 18 Jan 2018 13:00:46 +0000 (UTC) Received: from hyper1.noris.net ([62.128.1.62] helo=[10.6.0.3]) by mail.vm.smurf.noris.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1ec9rJ-000AZC-O9 for wireguard@lists.zx2c4.com; Thu, 18 Jan 2018 14:03:57 +0100 Subject: Re: passtos patch To: wireguard@lists.zx2c4.com References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> From: Matthias Urlichs Message-ID: <77d34157-cbe4-8085-7168-9a0e5fe52505@urlichs.de> Date: Thu, 18 Jan 2018 14:03:56 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 18.01.2018 12:56, Kalin KOZHUHAROV wrote: > a workaround would be to bunch a > few wg tunnels (even bridge them at both ends?), use fwmark and mangle > the TOS with iptables/ift... So instead of outside information being visible by way of the TOS field it's now visible by way of different UDP ports we're talking to. I don't see any advantage here. In fact I don't see much advantage of passing TOS out in the first place. Either you have a reliable transit network with short queues, or you don't. In the former case TOS is useless. In the latter case you have other problems which a TOS field cannot fix anyway. (OK, this is a bit more black+white than the Real World, but …) -- -- Matthias Urlichs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Jason@zx2c4.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 0dce437b for ; Thu, 18 Jan 2018 16:07:48 +0000 (UTC) Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 03338851 for ; Thu, 18 Jan 2018 16:07:48 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 84be52f2 for ; Thu, 18 Jan 2018 15:58:56 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 2c32d0d5 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Thu, 18 Jan 2018 15:58:56 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id y141so16072679oia.0 for ; Thu, 18 Jan 2018 08:11:17 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> From: "Jason A. Donenfeld" Date: Thu, 18 Jan 2018 17:11:16 +0100 Message-ID: Subject: Re: passtos patch To: Vadim Zotov Content-Type: text/plain; charset="UTF-8" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Not sure the infoleak is worth it. List: thoughts? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: labawi-wg@matrix-dream.net Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id ca41c2c5 for ; Thu, 18 Jan 2018 20:53:51 +0000 (UTC) Received: from matrix-dream.net (matrix2.matrix-dream.net [84.200.73.251]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8805eaa4 for ; Thu, 18 Jan 2018 20:53:51 +0000 (UTC) Date: Thu, 18 Jan 2018 20:57:19 +0000 From: Ivan =?iso-8859-1?Q?Lab=E1th?= To: Kalin KOZHUHAROV Subject: Re: passtos patch Message-ID: <20180118205718.GA12926@matrix-dream.net> References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Jan 18, 2018 at 12:56:55PM +0100, Kalin KOZHUHAROV wrote: > > Since this is not a common scenario, IMHO, and there are only a > handful TOS worth doing something, a workaround would be to bunch a > few wg tunnels (even bridge them at both ends?), use fwmark and mangle > the TOS with iptables/ift... > Just a suggestion, not tried obviously. > Perhaps it would be possible to use one of the **tables packet markings to store the TOS before it enters the tunnel and restore it on the encrypted packet. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: eric@ericlight.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 079d5cdc for ; Thu, 18 Jan 2018 21:07:00 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 745a456c for ; Thu, 18 Jan 2018 21:06:59 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C4B4F20A8B for ; Thu, 18 Jan 2018 16:10:29 -0500 (EST) Message-Id: <1516309829.3149945.1240291760.7ADD3DD5@webmail.messagingengine.com> From: Eric Light To: wireguard@lists.zx2c4.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 19 Jan 2018 10:10:29 +1300 In-Reply-To: Subject: Re: passtos patch References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi all, Wearing my 'Wireguard enthusiast who doesn't know *that* much about crypto, and only uses WG as an end-user' hat: It sounds to me like additional complexity, additional code, and additional information leakage, for what seems to be a relatively uncommon scenario, which by the sounds of things could be addressed with fwmark. Are any of those observations incorrect? E -------------------------------------------- Q: Why is this email five sentences or less? A: http://five.sentenc.es On Fri, 19 Jan 2018, at 05:11, Jason A. Donenfeld wrote: > Not sure the infoleak is worth it. > > List: thoughts? > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: dkg@fifthhorseman.net Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3e8214eb for ; Fri, 19 Jan 2018 04:01:16 +0000 (UTC) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id b1a0db48 for ; Fri, 19 Jan 2018 04:01:16 +0000 (UTC) From: Daniel Kahn Gillmor To: "Jason A. Donenfeld" , Vadim Zotov Subject: Re: passtos patch In-Reply-To: References: <4dc5f671-790e-88df-5483-ee00716d570e@zenit.ru> Date: Thu, 18 Jan 2018 23:04:39 -0500 Message-ID: <87y3ku4hpk.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --=-=-= Content-Type: text/plain On Thu 2018-01-18 17:11:16 +0100, Jason A. Donenfeld wrote: > Not sure the infoleak is worth it. > > List: thoughts? I don't think the infoleak is worth it. Certainly not by default. and i know wg doesn't want to have a lot of fiddly knobs, so if it's not by default, please don't add a fiddly knob here. As just one scenario where it's harmful, consider the case where your ISP wants to sell you VoIP service. They have a concrete financial incentive to delay or add jitter to packets coming from you marked with common VoIP ToS markings if your VoIP connections are not made through their competing service. If your VoIP traffic goes out via wireguard, your ISP will damage it to try to convince you that their service is what you should be using :/ The goal of wireguard-style tunnelling is to avoid leaking information about what the user is actively doing. Let's not introduce exceptions where we actively try to export otherwise-confidential information outside the encrypted envelope. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzicvlOwymaWlnoHjyu+ogyFnUzMFAlphblcACgkQyu+ogyFn UzO/WQ/+JQ3WfwT7dP3tgq8ljgUGiNZZJnXlf+qbIM9OYZGXT1iHtKx7e4C5XSUk raepg66qNvXQsTxRypFdd8pc2bt6tmwr8Vk4tsJdB4TPO1pPsKYL65fjCcRBx4LM x9uFh60mHlmAbU7bf5jaSpNizio1KGv63yPQUdsq9SMbbV3eDRR3UDDqZUQqTHyf uSaGKNXYyn0+UboMvNGGUyrrj5yM8PxZZvZwXNn2F71cr6xc3RJ1QFF00FQ3fwsr IrY/hx7ofzExtzzq9B73jv0f9McO80T18jSCxdbAtUdpa6jTcDBPoCHu52qHZAWe rA4uhgzKcBDWhBo2bgvQYGojXXdQttdiwWrOjWdy3w3CVEOOSiKf2ok9gSHayi/W eCyCnWxnOPU+vObEDXcnVGQV2PQQcXN+RaLC0jSUXXnUQXWbhPQfwaUm9rWjLS2i wbAs0yeLjZTZA+aq+UvhN7K0zPde6J5qS9Ug6DoRJt8d0Gk7U078ArNaU4uEFFQr 2ZFxWeC4l8a0fxY6rxZlFjjAmtcYZIOhSzWPXNyT9uyJsph+xn6zAMX5r6fOnh4D kVghy0qqndk5T9YOgvNgBHWnjGUUpqgOPVrppFJg9DfDhscK4F65TUPzbf+uDXhw BwFvAqJ4Bw4gyjn+5z5QZEF89YkthGIulJuYSXkYU+273FTTLQA= =9e2L -----END PGP SIGNATURE----- --=-=-=--