Re: Structuring the BKK spin bit discussion

Christian Huitema <huitema@huitema.net> Wed, 31 October 2018 18:44 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6D012F1A5 for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 11:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKJa1PtD88lG for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 11:44:35 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000DD128BCC for <quic@ietf.org>; Wed, 31 Oct 2018 11:44:34 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gHvTj-0013Jn-Rn for quic@ietf.org; Wed, 31 Oct 2018 19:44:32 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gHvT2-0007CC-7I for quic@ietf.org; Wed, 31 Oct 2018 14:44:28 -0400
Received: (qmail 18282 invoked from network); 31 Oct 2018 18:04:44 -0000
Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <kazuhooku@gmail.com>; 31 Oct 2018 18:04:43 -0000
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Lars Eggert <lars@eggert.org>, Marcus Ihlar <marcus.ihlar@ericsson.com>, Kazuho Oku <kazuhooku@gmail.com>
References: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net> <CANatvzxt-QBmeJUwp+MjtbpYXstPiEigDzQe0KfWJN+q0XR4Kg@mail.gmail.com> <HE1PR0701MB23938B01BC31888DAC3629B8E2CD0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <D8BB0373-FDEB-4312-94E6-BBA304D595BE@trammell.ch> <DM5PR2101MB10464C5346F73F83CAC25BD1B6CD0@DM5PR2101MB1046.namprd21.prod.outlook.com> <1F53D383-37C1-430B-8CC4-416CD5749A2D@trammell.ch>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <c7c51c5a-8f4a-c802-4c73-339288a3650d@huitema.net>
Date: Wed, 31 Oct 2018 11:04:23 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1F53D383-37C1-430B-8CC4-416CD5749A2D@trammell.ch>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O4ZNBWoBt4PoGsdmmviTwFPrUvIUNQYSy"
Subject: Re: Structuring the BKK spin bit discussion
X-Originating-IP: 168.144.250.231
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.19)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5lErpz26ZRHhKCVhrQnLsy5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViMDovPjqp8V2sUC7aqDc1Js7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB81OoFFeyN79z+gPkYXfWpU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxh1SJjtqxg9ToQOYgvpTXfiGuWFHL2CFALT37iujGyMC2K4cpU ualkQCN89mFr4hzV9Toz96geSJlwqLmXoHr6lp7KuHNaaKdg7iBEZefdsNV4YIf5ImMTjwbMKp8Y PS53nf7PGnOpecYaJDTU+UZIqwmLmW5xejNwBYllkh0bdnaT4v31xJIi7Xy4t2KeuFNOkVWClPVv bW5lVyQanRxw5nX9q2g89emBxjk4vbSaEK4mBBZyuzyr5ZxdVdkNxbnSdADg25CDX78caB9Pgj1m GtOITDa6LxNU+V0EKPyMEBN0UMMXiIAmQgAEYQzWQE9OdwZYmnjXBK2n15GHwEE5LdmmSBFbIW9r 526bbdC2BGGAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+neRXC2QfgHjpfJ8vHpGO1E1 rv1PGgUKl8Fk2bt6QgNFhK7unSGReaJhoESbMmiSIg22jZRl2kt9yYk5WCrzAYDU5KVZAuq7iRMO L0AqK7ggpVX8TjAFljeNKxwQ6q+MLFk8tLLJBl4kzg4sgIGXQirWSvYFRhImdY0rWWgG9tFHfqb5 R4VemuUI6bcEARsm0IytVb/slNDbsfQrrYxivbA+rrlJHnDn0ZA2vL1vx9UKwR4HDdDnpJnsnZ8l 83pkqWSdEOMftBjsWb6BDQzjSsFWaUKZ1JJcGxhwBY5CmZTIj1ZZXNSM8qRmAS6qJ+SgmVRG5T3/ 95tq5YraEsSrXcIxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iIuLUuVxdvZOq4GY2l8o5ZR4VHs>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2018 18:44:39 -0000

On 10/31/2018 10:16 AM, Brian Trammell (IETF) wrote:

> In the case that...
>
> - ...an end-to-end connection actually terminates at a location different than the apparent location in the endpoint IP address, because the endpoint IP address is a VPN tunnel endpoint
> - ...the "hidden" endpoint is very far (> ~3000-5000km) from the apparent location
> - ...that VPN tunnel exists solely to make the end-to-end association appear to originate from at or near the VPN tunnel endpoint (e.g., anti-geofencing)

The actual scenario relates to UDP/QUIC proxies, and how they would
compare to TCP/TLS proxies.

Today, I can build a TCP/TLS proxy that accepts connections at port 443,
examines the (possibly encrypted) SNI in the client Hello, establishes a
TCP connection to the hidden destination, and relays TLS packets between
the 2 connections. TCP is hop by hop, TLS is end to end, examining TCP
sequence numbers and ACKs does not reveal the hidden leg of the service.

Suppose that I build a QUIC proxy that accepts UDP packets at port 4433,
and then does pretty much the same job as load balancer: look for the
(possibly encrypted) SNI inside the client hello for initial packets;
look for the destination connection ID in other packets; forward the UDP
packets to the hidden server based on that, and vice versa in the other
direction. This is sort of equivalent to the TCP/TLS proxy scenario: UDP
is hop by hop; QUIC and TLS is end to end. The QUIC messages are
encrypted and don't reveal much, but the spin bit will reveal the
end-to-end RTT.

Of course, examining the content and timing of packets might in both
cases reveal the end-to-end RTT, but layering makes a difference. The
application may be able to implement end-to-end measures to counter the
analysis of end-to-end traffic, but the application cannot easily
influence the spin bit.

-- Christian Huitema