From nobody Wed May 3 00:46:44 2017 Return-Path: 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 AF6EF12762F for ; Wed, 3 May 2017 00:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 V3pYy3xfEy83 for ; Wed, 3 May 2017 00:46:41 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8118127868 for ; Wed, 3 May 2017 00:44:10 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id w50so99437662wrc.0 for ; Wed, 03 May 2017 00:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HAYX/76DaE2ITepd6V4EgPHgNcZocu+Nh8D9ayDkkUw=; b=rx7EHehgUf2JWae1lH+cm/3iyXlwvQ8eNHa+Xjr/p8T6V/guAKudH/z/NgYrKqk1dF +xGB/Ym4dG8L1O44kEAGCsTaE2RDOOszk8p89Iaxic0u4fNuNhAiCxhxEQoR5NTjTu+q j+bEkaojgB1vOtvQWYmj2fFopVRrb34oG8wJMDA69YFSJpP+tzWLjm9D/Hsdn8GhGJtf g2uAl8cujG5/XMROhOGYChXHIKbxYbt+2JOtp3mUgBlGGbN8D2N1eJLCt15Vh272dDQf KtLly8dmoBdZmGlwxVdSjvue3JncUx7SXjwymvXSOMXntVVxGemP5sGSlfdBv/5/5bwA NkMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HAYX/76DaE2ITepd6V4EgPHgNcZocu+Nh8D9ayDkkUw=; b=MT9187DKxBW2gAz+bvjOLTLiZgggiSfmHrc31AR17jc2dKBrsNuXdAk8qXUDwjVvSf 67ei3xDfyjfpXZK+QyBdKDj4IYX94CponScTB1/FAg6nsHJx+eNz3df/gRYNHh3TZvYY ndFmW6mmlOd0p9iZTLWP0QlIvzk+5M5vHBqOThPfjCYJT9u/fgSn0SBbADzMflgitxPy tOhcPV0fq6xM99mXhiKQYHDY+dcrJcd/BBKaK68qnk+z0GJv1lceMb1cnIfr40TIk/ff ZJ/V4XDYd7mxUEf+reChF8LeHGUuXFpKVfpCZz89i0BJGqzXniyMK9Gq3LN0i03mpO7d z/EQ== X-Gm-Message-State: AN3rC/7qnDOgYwTF0ZQb7YzqTI1ysb1wP34JAQWH3DSwh4teeidKcM8m NwAz1j+K0WMRwg9bSeqkMrZS4O0TLwYw X-Received: by 10.46.0.23 with SMTP id 23mr11296674lja.33.1493797449178; Wed, 03 May 2017 00:44:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 00:44:08 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Thomson Date: Wed, 3 May 2017 17:44:08 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Brian Trammell Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 07:46:43 -0000 Sorry about not getting back to your essay as quickly as I intended. As ou On 28 April 2017 at 19:27, Brian Trammell wrote: > So unless I'm missing something here, I'm not sure that "privileging just= one path" is a thing that happens. I was primarily talking about migration. If you move from one network to another, the path prior to the migration gets the handshake, the path after the migration gets the close. The first is privileged in the sense that it might see a reset verifier. And yes, multipath makes this much more obvious a problem. > (I'm ignoring multipath here, because in the multipath case, I suspect we= 'll end up with an MPTCP-like design [...] (I don't share your assumption about its design; I want a single cryptographic context, for one. FWIW, I'm thinking of multipath as make before break without the break. That's also why I want to make any path signals explicitly path-specific.) >> We can work around that, but it either requires removing packet >> numbers completely, or greatly enhancing the information exposed to >> the path. For instance, if we had a packet number echo the server >> would be able to pick a plausible packet number for its reset. > > ...I wouldn't say we need to greatly enhance it; this PR enhances it enou= gh for the purposes of separating endpoint-generated public resets from spo= ofed ones... Note that my PR does not do this. It would require changes to do so. > I agree completely that it's desirable to separate the discussions about = end-to-end from end-to-path and path-to-end signaling; but public reset, in= particular, counfounds that desire, since it's an end-to-end signal that r= adiates information to the path. We should focus on, and probably work to m= inimize, these inseparable effects. Yes, I agree. Though I'm not as enthusiastic about a design that makes public reset indistinguishable from other traffic. We could do it but the only way I know how to make that work is to force endpoints to try hashing every packet of a certain size that fails to decrypt. We could use a key phase change to reduce that to the points at which we roll keys, so it's not awful, but it's probably also creating some nasty externalities (e.g., packets of the magic size cause connections to fail). > I don't yet see a way to get better-than-economic defense without allowin= g a path element to authenticate an endpoint, so that it can verify that ea= ch header bit carrying a signal indeed came from the endpoint it should hav= e. This is vastly more expencive, and essentially goes down the path of bui= lding QUIC atop a multiparty cryptographic protocol -- mcTLS occupies a far= corner of this design space. I don't think it's possible to deploy somethi= ng like this safely in the Internet with the primitives we have available t= o us, but IANAC. Nor I, but you are right in observing that it gets funky if you want a verifiable end-to-middle signal. One-time passwords like in the public reset design only work for one bit of information, and I assume that any generic system here needs to signal more bits, which could mean public key crypto and I don't think that anyone wants that. (There's probably something else out there, but nothing I can think of works for a potentially large audience and arbitrary messages.) From nobody Wed May 3 01:40:40 2017 Return-Path: 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 DB9A8129485 for ; Wed, 3 May 2017 01:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 RZm0rsc8xNdd for ; Wed, 3 May 2017 01:40:36 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0660C124B0A for ; Wed, 3 May 2017 01:38:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,283,1491289200"; d="asc'?scan'208";a="186179104" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx142-out.netapp.com with ESMTP; 03 May 2017 01:22:52 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 May 2017 01:37:13 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 3 May 2017 01:37:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NzerZceSCYb3CuIDObWSREJafxNtSxSE/V6NZv0TI9c=; b=EHQFlqw98W6UZ0n02+kLSJ5VoP8k0etACh6gfv46yHEOKCE8fT9Q9QAHv0IPZef2NWcl0rOr5F/6kzqflm54EhBQ/i9vFc+EUXwRa8ir70xDKj+GNiJublZagYdeQpIExmMFQl16ecRDVw/meRCAtKQBS+Wn4fzXb6QDJJkj5Dk= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Wed, 3 May 2017 08:37:11 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1061.021; Wed, 3 May 2017 08:37:09 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Topic: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Index: AQHSw+h0UvPKGWYvsUKaLwDx0YPN4A== Date: Wed, 3 May 2017 08:37:09 +0000 Message-ID: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:rTyg1nGkZcgCNnxGLVhnLPZO8zirhHd5gSBkR8xZ1wRTrWRHyBGJQQgP4jIy/7T8Y0h/CNe3ykTkNeiBcEw3pcRloBC3wL0Tq1PKn7ib4lO2n3OV9V0WDnclOx/A8wi6oiuCImaBznGSIu1+TYckaQ8yWy5QzP7oMMhxFUGIW7AoN02ebvJ23cZCyQfTpeFSoKkn4Q6LDXFH305UE4qdNYmh16xpT0lAJlEyo4V0RNkTD/vBVcUj6oY3Q4wvaeP/kDcnW4prMwP45RpUYK4MI/KT1tuDnQcAOdrEmqRuqPsg5/WnyIJ+6mzuOX2x6/8xNtOIcWCn8OlvCjIDFJekEg== x-ms-office365-filtering-correlation-id: 89b4cd29-c1a9-4f1f-03f2-08d491ff96d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39410400002)(39840400002)(39400400002)(39450400003)(6916009)(3846002)(102836003)(6116002)(86362001)(305945005)(36756003)(77096006)(6512007)(53936002)(99286003)(110136004)(33656002)(6506006)(6486002)(99936001)(6306002)(50986999)(38730400002)(6436002)(25786009)(82746002)(3660700001)(66066001)(3280700002)(5660300001)(83716003)(2900100001)(189998001)(8676002)(478600001)(81166006)(122556002)(7736002)(57306001)(50226002)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_F773BE33-3FF2-4E79-AF50-9CC8BD63742D"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 08:37:09.7191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 08:40:39 -0000 --Apple-Mail=_F773BE33-3FF2-4E79-AF50-9CC8BD63742D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I've been looking at = https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft = and wondering which open-source TLS implementations are suitable for = providing the required TLS 1.3 functionality over UDP. Specifically, for = a C implementation. (There is a list of implementations at = https://github.com/tlswg/tls13-spec/wiki/Implementations, but it's not = clear which - if any - expose an API that would be suitable for = operating over UDP, for use with a QUIC stack.) Any pointers? Thanks, Lars --Apple-Mail=_F773BE33-3FF2-4E79-AF50-9CC8BD63742D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlkJlrUACgkQVLXDCb9w wVcQuBAA0Z7LDGR0nPfmofuVtiZwIRu9m8dDxQfJuOMOyQUkCtKws1zVs5SyD2zc 8ucac30KARRIBCeELDEcSvMibnLi3rUvAZVva6dpDZ3eV/Eoj1PW63IwqWeR6L0c a1sPWLhKSaqi7vAu+x3MZOuKqR/uW5qYFrrMGgG1s4pStoXIVQ37W9h+LFXy9zyK y4l4jH5kHVr/kKbFBbZC4uiZUP0kvVa1jM1vIQZR6cwMTwfeUA+G5mQgs1dam9Zv a5KkEF8NGFasE0TtkzoXtapqxH8ppNEWIbuhA2T0YFzfv2LdnVTKpymLCHUxPIvl +3Yk8LTozCmgjB4yx0zfl1YaDtySCQjasAFP/FOHRFcRpA9i5IYiO8fK1kfvssma AG9DUB7m0aE1An1klnkRs0WkdD/2Jeh2TtXEBft0N7Ias+cUFh/nZ8n4jSQAQ3bq 0nvhT/avvqrRLlDJfGVHgr3tGwcsBWerHjHNc7Z2uliSUlp8O1Ifb0v/s6urqkR6 a+gWymeb2vBBoezVzWUzO4yOakpO2NIZGBZib5m5y7Z0N2KrEIAegHHx6ErMq5MW 5BX2Pkm8gITePioYUKTpcjndJH00Zl4EqnNlJ44lUB5KXGtL/mGuN/iO/1n3gd3j woJ3VvGl+h66mzqTAG6xKwAoXpK049vy1t7h4NUg3PDqOZGPWs0= =DVts -----END PGP SIGNATURE----- --Apple-Mail=_F773BE33-3FF2-4E79-AF50-9CC8BD63742D-- From nobody Wed May 3 02:09:22 2017 Return-Path: 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 88A051200ED for ; Wed, 3 May 2017 02:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 01XSUtYUGxrq for ; Wed, 3 May 2017 02:09:19 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A007C129442 for ; Wed, 3 May 2017 02:07:00 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id y4so69861770pge.0 for ; Wed, 03 May 2017 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSnky8/MznDbaKXRC51bYVvkcUvzuhkYUcEvAvl8BKk=; b=qgGFfzvXDfrZwshDp9Q32JosTwdkubTv9MA/1+gYs7oPNOu1vrN2aM2Ocxk4XE2HcN qyoBvz8xTD+KeVvkBb5uRdQvcieNGVIgLx8vKpZQL8G1B/3NnocZor35J+KCFpQki0dH /0AO9SYR3ZM17pg5b+bNGRuiLZ7PosMGsICMj8UFr9sO3uGAHENvgZOluc4dUo/ancLT AtdlBpV+iJlZeY8Q3VdvHsdlolHMSOFu4jwuNbLsUvX+MlQFymq+1qcwNf3B+0Z6qI5a 3J7jbB6dHNmAnXwtxudu4FHbEEOlm2KbSDLUjXRS8TtPLg7O7qNTdZBtrnY9eASWkfUb fDVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JSnky8/MznDbaKXRC51bYVvkcUvzuhkYUcEvAvl8BKk=; b=fVt4YlQbTFHllGWjSNi6p/VLgUyFlbbvwgH4Zy2Q8lyc8jaXPocptH/bIDL2wVfFxG sHI9JqkT+gK6DK0R+CO7Z/aPKSB5QHIGDkpVTuINij3tZuw4cVWOrNhSe92eBj6q+nV5 fLsNEMtIVL7RQ6kVvQMC3O2kMHaYoHeci+d0WXEETHQWuVRqX32kGgurTAshG09d0xOt Y4vluiNLi3Lw1Dsf2CFmOxOrX3ewocz8Wz6Qf7vfaYF5Q2cg+8jIDzcIG5gbrsPJtRty 00cwIGPUUyqvv47Hn5TXyDyUjiawaZ2wd3yaoHidvzGktykaYv5dc2I+njq2ucB7ZV0V EtcQ== X-Gm-Message-State: AN3rC/7+5CrUfpFZyoZoepa2daIC+wSpJyKqhp1PkvyDQdg857Y7uNMA d/4f/XZEWLdX9ccelgYWT3FqSn7pJg== X-Received: by 10.99.108.6 with SMTP id h6mr36647234pgc.188.1493802420156; Wed, 03 May 2017 02:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.135.79 with HTTP; Wed, 3 May 2017 02:06:59 -0700 (PDT) In-Reply-To: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> From: Kazuho Oku Date: Wed, 3 May 2017 18:06:59 +0900 Message-ID: Subject: Re: Open-source TLS 1.3 with an API suitable for QUIC? To: "Eggert, Lars" Cc: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 09:09:21 -0000 Just FYI, I maintain picotls (one of the pure-C TLS 1.3 implementations listed on the wiki) which I have designed with QUIC in mind. The API of picotls is designed like a codec (rather than an abstraction layer on top of the sockets API) so that it can be naturally integrated with UDP-based protocols. Actually, I have started working on to implement QUIC using the library and have a dedicated branch for adding the missing parts that are required for QUIC[1]. I believe that the only piece that is missing at the moment is the Exporter. [1] https://github.com/h2o/picotls/tree/kazuho/quic 2017-05-03 17:37 GMT+09:00 Eggert, Lars : > Hi, > > I've been looking at https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft and wondering which open-source TLS implementations are suitable for providing the required TLS 1.3 functionality over UDP. Specifically, for a C implementation. > > (There is a list of implementations at https://github.com/tlswg/tls13-spec/wiki/Implementations, but it's not clear which - if any - expose an API that would be suitable for operating over UDP, for use with a QUIC stack.) > > Any pointers? > > Thanks, > Lars > > -- Kazuho Oku From nobody Wed May 3 03:09:14 2017 Return-Path: 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 2FBDE12896F for ; Wed, 3 May 2017 03:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fj1dNrvFkZOf for ; Wed, 3 May 2017 03:09:09 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B741294D8 for ; Wed, 3 May 2017 03:06:47 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D0D6340E1C; Wed, 3 May 2017 12:06:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.10669); Wed, 3 May 2017 12:06:45 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 3 May 2017 12:06:45 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 16357319; Wed, 03 May 2017 12:06:45 +0200 Subject: Re: Updated Public Reset authentication patch Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_900CEAAC-F808-4913-8BAF-4C6204435D19"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Wed, 3 May 2017 12:06:44 +0200 Cc: QUIC WG Message-Id: <709C6C93-B6A7-49EE-A47A-4DB9E3DFB13A@trammell.ch> References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 10:09:12 -0000 --Apple-Mail=_900CEAAC-F808-4913-8BAF-4C6204435D19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 03 May 2017, at 09:44, Martin Thomson = wrote: >=20 > Sorry about not getting back to your essay as quickly as I intended. = As ou >=20 > On 28 April 2017 at 19:27, Brian Trammell wrote: >> So unless I'm missing something here, I'm not sure that "privileging = just one path" is a thing that happens. >=20 > I was primarily talking about migration. If you move from one network > to another, the path prior to the migration gets the handshake, the > path after the migration gets the close. The first is privileged in > the sense that it might see a reset verifier. And yes, multipath > makes this much more obvious a problem. Ah, understood. >> (I'm ignoring multipath here, because in the multipath case, I = suspect we'll end up with an MPTCP-like design [...] >=20 > (I don't share your assumption about its design; I want a single > cryptographic context, for one. FWIW, I'm thinking of multipath as > make before break without the break. That's also why I want to make > any path signals explicitly path-specific.) (Aside: I'm pretty sure we agree on the design here: I intended less by = "MPTCP-like" than was taken. :) Single cryptographic context is IMO a = no-brainer, as is designing it with similar semantics to = make-before-break migration. But let's have that discussion when it = comes on charter.) >=20 >>> We can work around that, but it either requires removing packet >>> numbers completely, or greatly enhancing the information exposed to >>> the path. For instance, if we had a packet number echo the server >>> would be able to pick a plausible packet number for its reset. >>=20 >> ...I wouldn't say we need to greatly enhance it; this PR enhances it = enough for the purposes of separating endpoint-generated public resets = from spoofed ones... >=20 > Note that my PR does not do this. It would require changes to do so. Ah. Yep. Sorry, I carried over some state from PR20 the first time I = read this. >> I agree completely that it's desirable to separate the discussions = about end-to-end from end-to-path and path-to-end signaling; but public = reset, in particular, counfounds that desire, since it's an end-to-end = signal that radiates information to the path. We should focus on, and = probably work to minimize, these inseparable effects. >=20 > Yes, I agree. Though I'm not as enthusiastic about a design that > makes public reset indistinguishable from other traffic. We could do > it but the only way I know how to make that work is to force endpoints > to try hashing every packet of a certain size that fails to decrypt. > We could use a key phase change to reduce that to the points at which > we roll keys, so it's not awful, but it's probably also creating some > nasty externalities (e.g., packets of the magic size cause connections > to fail). Ew. >> I don't yet see a way to get better-than-economic defense without = allowing a path element to authenticate an endpoint, so that it can = verify that each header bit carrying a signal indeed came from the = endpoint it should have. This is vastly more expencive, and essentially = goes down the path of building QUIC atop a multiparty cryptographic = protocol -- mcTLS occupies a far corner of this design space. I don't = think it's possible to deploy something like this safely in the Internet = with the primitives we have available to us, but IANAC. >=20 > Nor I, but you are right in observing that it gets funky if you want a > verifiable end-to-middle signal. One-time passwords like in the > public reset design only work for one bit of information, and I assume > that any generic system here needs to signal more bits, which could > mean public key crypto and I don't think that anyone wants that. > (There's probably something else out there, but nothing I can think of > works for a potentially large audience and arbitrary messages.) One could probably design a proof verification to signal one of N (for = small N) conditions, of which one would be reset, such that the = signaling of a verification would require the production of a new proof = for further signaling (by providing for one verification value per = condition, all values of which are simple transforms of the bits hashed = to create the proof -- verification time scales linearly with the number = of possible conditions). This isn't completely generic, but it's better = than one bit. With respect to close/reset*, there's another possibility on the = verifiability continuum that we allude to (but don't fully define) in = the state machine draft: "cancellable". Here, an endpoint can signal a = close, but so can any on-path device that has access to a valid = connection ID and packet number. A spoofed close will be detected by the = endpoint (since it won't decrypt), which will continue sending traffic = on the same n-tuple and connection ID. The presence of continued traffic = on the n-tuple is itself a signal that a prior close was spoofed. Spoof = cancellation semantics only apply to close signaling, and there are = weird corner cases to consider (what about a spoofed close coincident = with a real migration? can two collaborating nodes use cancellation to = keep legitimate firewall pinholes open for illegitimate purposes? etc.), = but this does represent another possible design... * We still need to clarify what we mean by reset: is this "all = connection termination" or "abnormal connection termination" or = "unrecoverable connectivity error"? Cheers, Brian --Apple-Mail=_900CEAAC-F808-4913-8BAF-4C6204435D19 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZCau0AAoJEIoSt78L6kaj6Y4P/3yJT4SkWpzQRsFodfzhAmpO 49VcinSE7ptvCwd58ILbHlkdhjlfmXPQdxszAMwVjiRVaonL+vBkX2F6H8qPBpNk xZhEWGcPUjo0KdQCFfElICEEdewd4k9tKoO1p4zkOmc12eS8MXchPrcH8syoWCBe AMdn8q7BJEpH6u4DTSkqM+eYU1zZOkfjvJZ4qdaqZZQxZ4mNSSLPjRCyh0ctRS0I YJTp5z3eTF+/Uv4ycSCvJnlbZOsB6wCAvr3V9aYwRxB4KyPSzpc8QZH0vQFKLANJ BR6S9s36vM8FBVCUcqQK3BgXJ2DRW/cWzukozDg/2CiPFe3twD35s2PCgMHvfTi5 dABwaFuNoDcS61i+/0RU6C4y9ucB2C+Nep/r1iqt33w+sC2s+hDr96EJ8Jay3rJH 1Rb5QYCex9jfJkKcdgstZJ6Scv8OUTPJ8bgJX0ADDIqLejuLxxspY4NflUQe4N5g IHhFL2sgduD6bqPMac3k5cJ2zlDJYC/3a58ZW2wrj7E8ksXEUeHj+pX1iC+GtwGA 2k61vlJ3gWEgYe2bMk12LFPLS1HRmkPLpzDtp+QBQVsGXWEVcKMtRhlEVTKldYq/ SMFS023f2GitfTNASYcKTCU+eTMwjVdOpvff0WZGmS39zL3SxwANTVHVxGi4f6ZH WXqv7MvYyltyo4mq4gUU =5dtU -----END PGP SIGNATURE----- --Apple-Mail=_900CEAAC-F808-4913-8BAF-4C6204435D19-- From nobody Wed May 3 03:46:32 2017 Return-Path: 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 7B29D126C0F for ; Wed, 3 May 2017 03:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TNMt7HVSJHtJ for ; Wed, 3 May 2017 03:46:27 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3F91242F5 for ; Wed, 3 May 2017 03:43:30 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m123so52549199wma.0 for ; Wed, 03 May 2017 03:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hejiGKJ1U3RdYT5W3GewBB6OHMuyXOxqEsIDdw6cgcs=; b=ZLBP28WWb10YM/WUP49qz+41nI10vcnEOcjZiEOFdrS8RLEWLHTHqHVpTJQSGyArIZ 1AmeZeYEJDwVBTb9NlZr3dOrquhhO58DSqQnGLXJAMbbmgEN/3a6aVkyVbYxNMg67Ays PIkGIe23SN+m3DVP7qQ5mUsQLRSRrl+gzs0uEqMrtcYXNO2jSrQePN4+tQIOKTadfDQD OISEm38ZpycxZOD3ZtGC1yHrbR8S7Fr5lVHAZ569eS7Xu4595VCCtIyarlpJe0hVVsi9 q/5fv4bNsYHgU8EOde1iAZ33cUT4Ni97M1FMK2+Ml8J03+N8U9tqIvnwZw8JCSochCFR s4Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hejiGKJ1U3RdYT5W3GewBB6OHMuyXOxqEsIDdw6cgcs=; b=Hn4iQS54MdN5xunVJLl9XJ/J1Ue3hp70NqG66k/5T85FLaVaxau++cpuMzi4oHQO3r yg8HBtjhz6r2LzAwX/b1CnndSbBv8insUsSEJSSd9QLaTdiqdffh9NrtkMw3zyEu+yfJ NkoPUBvGpHnGGI0X54s9DPydVoPpuzka69DPqpS0SCV5qFPEmwXSSahCSsNf6mFAq3JO Im+aAU1SwNnG5EUeaz7006Jh9xG9h/KvaLm0PBwEfrqXBxDRGtZuXu1tG0mARccyT0AM qqo1thdlzhBZ5uz6ln6ERBgN37Sl/4TdbqjW6j53bEn9np5mZ6MnhweqJOWiLKnZk0hf yzog== X-Gm-Message-State: AN3rC/5j74n1nhfNauy+t9lx7VkqchI6tuQi6H8MlAuskVv2wmpsCErO CusAAPHun6ZpfzLaN8q1c8nh+CZioj/XRCs= X-Received: by 10.25.79.27 with SMTP id d27mr10347279lfb.76.1493808208808; Wed, 03 May 2017 03:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 03:43:28 -0700 (PDT) From: Martin Thomson Date: Wed, 3 May 2017 20:43:28 +1000 Message-ID: Subject: Proposed changes to cleartext packets To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 10:46:29 -0000 Issue: https://github.com/quicwg/base-drafts/issues/442 I've heard quite a few concerns about the current design for server selection of the connection ID. The primary concern is that the choice of final connection ID is made on the same flight as the server handshake messages - the same flight where the server is required to commit non-trivial state and computation resources to the connection. The current design is actually anathema to certain load balancer designs. If the node that receives a packet wants to get rid of it before sending the final server flight, the load balancer can no longer route statelessly. The server folks I've spoken to want to pick a connection ID during both version negotiation and stateless reject/address validation. This allows them to do trivial or at least lightweight processing on the node that receives the first packet AND steer the packet to the right node. I'm proposing that we move to a special "first client packet" approach rather than a "last server handshake packet" approach. This allows servers to identify which packet has a client-selected connection ID and create special logic for that. Issue: https://github.com/quicwg/base-drafts/pull/482#discussion_r114445062 The second problem is one that arises from stateless rejects. A few people observed that there is a disconnect between what the server sends in a stateless reject and what it subsequently sends. For instance, the server can't generate a stateless reject then send subsequent packets with the expected packet numbers. The reason: it might need to generate multiple stateless reject packets in response to multiple handshake attempts from a client. It can't save the packet number it chose in the cookie it sends because that would mean sending different values for the same octets on stream 0 and clients could get confused by that. Also, it was previously necessary to resort to shenanigans at the server after a stateless reject. The second ClientHello will start at a non-zero offset on stream 0, but the server will effectively have never received that data. That means pretending that the data was received and delivered already, but then being able to validate the offset and back out the change if validation fails. All in all, that's more special handling than is ideal. Jana proposed resetting the transport side of things when this happens. That means resetting the stream 0 offset and not getting bent out of shape when the server chooses a non-contiguous packet number. That seems like a reasonable idea, and I'm proposing a new cleartext message type for that so that it can be explicit when the server is doing this. That message comes with its own special treatment (it is used for HelloRetryRequest only, and HelloRetryRequest has to use it, it has to be one packet). This externalizes some of the server costs for stateless rejects, and it adds another special case packet type. Neither of which I'm entirely happy about, but it seems like a reasonable compromise. These are two separate issues, but they are intermingled in annoying ways, so I have a single draft PR for both changes: https://github.com/quicwg/base-drafts/pull/493 There is a question in the PR about two alternative designs: 1. Require the client to send an initial packet after version negotiation on the basis that version negotiation is a complete do-over. 2. Maybe also after a stateless reject, which would mean that all packets containing the ClientHello would use that "initial" type. That would mean that only the initial type would have packet size restrictions, which is nice. I think that these could be an improvement, but I'd like to hear from server folks. The cost here is that after version negotiation and maybe also a stateless reject, you would route the packet from the client as if it were a client-selected connection ID. I'm not sure how much that matters. What you do get is up to three opportunities to reroute a client (during version negotiation, optionally during stateless reject, and during the handshake). From nobody Wed May 3 03:54:57 2017 Return-Path: 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 D680C1293F9 for ; Wed, 3 May 2017 03:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aiZug2DOUTXR for ; Wed, 3 May 2017 03:54:54 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992D312947B for ; Wed, 3 May 2017 03:52:17 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id z52so103412283wrc.2 for ; Wed, 03 May 2017 03:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nUZbhwOihMj38HddiGoZ9eIsi1oY2qT3/096mdXLcSE=; b=Va21znDk7TBf0xrcZmWhedBEu9nou6AL3TPbUI6vtSirB1IHSSXvdZSCr2f9eWpNrM +oyZnjxNEOvOMjq1CAQCbmn3emSs8SsRuQWMlj77aiXBpMxH51u/TL0afdRhNbXEm/Ps YxzOq+wfsn/3mKBhlw8SUci4d2osGmOO/a39SMe9OIRdotqthaaWG6/X8IhsYEifqo05 XvZ2TwyxYEqzzqvPw1JhydD9P4pDFXiPPapmUZQXfa5F1Nyi+bKrJAPNxCeZYbJt66lC My3+vvaC4pDSZXH87CRYE7puUpJVV7Wh8kecrILDG1zcLNDNKEqSoIm8pmEusYbrhjCO JlUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nUZbhwOihMj38HddiGoZ9eIsi1oY2qT3/096mdXLcSE=; b=e4cNtWEO2QaYX5Xzx164S25Qdpd/QFesPzzSeN28OG8iSUaY/grJRlowzNLqMyS/wL LXHEkWXw2N68Vpzjfc1moR84RAHCSzhRifrzChF+gZ1rXkI1VG7aMixNsu1mnI+54oun QJsATmXDuHp5vaHC9ikB9gVsvStoP1h34nieFwmkcdDeYlJhJ7EBNkmyIoeYZlm05t9+ ejijKxJFNe7mVjn8U2hY6eoF5zSL4U+w+tjfNIax+NKED7n3elkg7Xwmt1kC4wXmvTpB bqdz12b91Xi+W0a0DBce/opkEfpos/CY3qQ6bGmzhRD4fD8EjsJgicylXCY9jqtLAyiu VQFg== X-Gm-Message-State: AN3rC/5xMPKlDk55JGq13t3fJhxxfZWVPTz3R8V4+nJl5G2gBkg2mx2Z r5ekwQdOouBh0dZJXdsjQA6u4gnsk33N X-Received: by 10.46.70.26 with SMTP id t26mr9043741lja.22.1493808736076; Wed, 03 May 2017 03:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 03:52:14 -0700 (PDT) In-Reply-To: <709C6C93-B6A7-49EE-A47A-4DB9E3DFB13A@trammell.ch> References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> <709C6C93-B6A7-49EE-A47A-4DB9E3DFB13A@trammell.ch> From: Martin Thomson Date: Wed, 3 May 2017 20:52:14 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: "Brian Trammell (IETF)" Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 10:54:56 -0000 On 3 May 2017 at 20:06, Brian Trammell (IETF) wrote: > With respect to close/reset*, there's another possibility on the verifiab= ility continuum that we allude to (but don't fully define) in the state mac= hine draft: "cancellable". Here, an endpoint can signal a close, but so can= any on-path device that has access to a valid connection ID and packet num= ber. A spoofed close will be detected by the endpoint (since it won't decry= pt), which will continue sending traffic on the same n-tuple and connection= ID. The presence of continued traffic on the n-tuple is itself a signal th= at a prior close was spoofed. Spoof cancellation semantics only apply to cl= ose signaling, and there are weird corner cases to consider (what about a s= poofed close coincident with a real migration? can two collaborating nodes = use cancellation to keep legitimate firewall pinholes open for illegitimate= purposes? etc.), but this does represent another possible design... Yes, someone suggested that ICMP unreachable might have this property. From nobody Wed May 3 05:32:00 2017 Return-Path: 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 3CB6412944E for ; Wed, 3 May 2017 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 WUEd_XvZWCiV for ; Wed, 3 May 2017 05:31:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E68EC12948D for ; Wed, 3 May 2017 05:28:55 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v43CNwVx029022; Wed, 3 May 2017 13:28:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=XxVNM8cdP/uVjCK7HeuWnisTgKYqnyhVa70PhCb5WAE=; b=hbrOBjml0xlxYJN9Gyqp2XHttn+weY0rHddgC2/5nU2RbKTb2QU03ZeBOcnAbEzGWr7t FRUgLpvdAt/8biJ8XQNDHh3WpMKr4kQDxpiSbJX6/cBogFKtGSzbudoTNiXQShleshv3 svammFcMjKxR4xhUauz7WyvRJltu0A7Aeayg24tyBw6rkyoTS8QLuNUUdVjUbyBEuz8m zuI+zTVt7kkl0ykuczjB1txTLs4qLTaIMNyn+l1UoJhwKosBRjQJ210y1IpiE+qZ6h75 bWWmB+F9TUyEmzjCC1VgHdxJVyDShdKQ5UOWOPF6LP+hsdiG1QFD648e0lISTUG78yD1 4Q== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2a72my2yve-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 13:28:52 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v43CQRSU000304; Wed, 3 May 2017 08:28:52 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a72m90xru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 08:28:52 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 07:28:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 07:28:50 -0500 From: "Salz, Rich" To: "Eggert, Lars" , IETF QUIC WG Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Topic: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Index: AQHSw+h0UvPKGWYvsUKaLwDx0YPN4KHiiaCA Date: Wed, 3 May 2017 12:28:49 +0000 Message-ID: <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> In-Reply-To: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.55] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030232 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030232 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:31:58 -0000 > wondering which open-source TLS > implementations are suitable for providing the required TLS 1.3 functiona= lity > over UDP. Specifically, for a C implementation. If there are API's that OpenSSL would need to provide, please let me know (= ideally within a month) and we will work to provide them. From nobody Wed May 3 07:09:53 2017 Return-Path: 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 87F69129494 for ; Wed, 3 May 2017 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 N196n-u5Eet3 for ; Wed, 3 May 2017 07:09:50 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 03171128BB6 for ; Wed, 3 May 2017 07:06:37 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1d5uvG-0001lC-6n for quic@ietf.org; Wed, 03 May 2017 16:06:36 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1d5uvE-0005RY-1w for quic@ietf.org; Wed, 03 May 2017 10:06:29 -0400 Received: (qmail 8246 invoked from network); 3 May 2017 14:06:24 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.199]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 May 2017 14:06:23 -0000 To: quic@ietf.org References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Christian Huitema Message-ID: Date: Wed, 3 May 2017 07:06:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------35F7AB14BEE0F0419A1E68A5" Subject: Re: Updated Public Reset authentication patch X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49FXKwZbSflcvTu2SSy6NnOlTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrE+Dtux4xCkRhuiCHM462jRcOb18WfxGyg6Om6u4YYm40F72nfB+tgbRyJ bmdtUGM5hjoyEb9Oq0NWpyO3vrfYzS02aeiYw+GANPqwVsDMNz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBcKaDTe3QRRhTm1Fh3Md1t3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0n3+jqS1O CMRjMV7xKpCccLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/pl2Au/rbQ4WfNtF9NsPsDM43HV4wT7sJ7Bs HSo/t7FuGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+YzaHXGDtmr6LoB+LyIJrZ6Ke72V7y3QDXL8JTpxprEN X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:09:51 -0000 This is a multi-part message in MIME format. --------------35F7AB14BEE0F0419A1E68A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/3/2017 12:44 AM, Martin Thomson wrote: >> I agree completely that it's desirable to separate the discussions abo= ut end-to-end from end-to-path and path-to-end signaling; but public rese= t, in particular, counfounds that desire, since it's an end-to-end signal= that radiates information to the path. We should focus on, and probably = work to minimize, these inseparable effects. > Yes, I agree. Though I'm not as enthusiastic about a design that > makes public reset indistinguishable from other traffic. We could do > it but the only way I know how to make that work is to force endpoints > to try hashing every packet of a certain size that fails to decrypt. > We could use a key phase change to reduce that to the points at which > we roll keys, so it's not awful, but it's probably also creating some > nasty externalities (e.g., packets of the magic size cause connections > to fail). We could do better than "hash every packet" if instead of just sending a reset verifier the server also sent a reset nonce. The public reset would then contain something like header|reset-nonce|reset-proof, where proof =3D hash(reset-nonce|reset-verifier). Servers with reduced state could just derive both nonce and verifier from a static secret and the connection ID. Clients that remember both nonce and verifier would just check that the nonce matches the preset value before computing the hash, thus greatly reducing risk of spending CPU cycles on random garbage. -- Christian Huitema --------------35F7AB14BEE0F0419A1E68A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 5/3/2017 12:44 AM, Martin Thomson wrote:
I agree completely that it's desirable to separate the discussions about end-to-end from end-to-path and path-to-end signaling; but public reset, in particular, counfounds that desire, since it's an end-to-end signal that radiates information to the path. We should focus on, and probably work to minimize, these inseparable effects.

Yes, I agree.  Though I'm not as enthusiastic about a design that
makes public reset indistinguishable from other traffic.  We could do
it but the only way I know how to make that work is to force endpoints
to try hashing every packet of a certain size that fails to decrypt.
We could use a key phase change to reduce that to the points at which
we roll keys, so it's not awful, but it's probably also creating some
nasty externalities (e.g., packets of the magic size cause connections
to fail).
We could do better than "hash every packet" if instead of just sending a reset verifier the server also sent a reset nonce. The public reset would then contain something like header|reset-nonce|reset-proof, where proof = hash(reset-nonce|reset-verifier). Servers with reduced state could just derive both nonce and verifier from a static secret and the connection ID. Clients that remember both nonce and verifier would just check that the nonce matches the preset value before computing the hash, thus greatly reducing risk of spending CPU cycles on random garbage.

-- Christian Huitema
--------------35F7AB14BEE0F0419A1E68A5-- From nobody Wed May 3 07:36:42 2017 Return-Path: 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 AE29412948F for ; Wed, 3 May 2017 07:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 1n1KKOOftzpt for ; Wed, 3 May 2017 07:36:39 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF6C12957B for ; Wed, 3 May 2017 07:33:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u70so85872532ywe.2 for ; Wed, 03 May 2017 07:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oEC1TGaElWl1GZtaLy443jICc2i2HlzJRS/tQX16/tY=; b=LDFR466EsUzgyO6rKoqpFC1H+ZJMcEJxCfZeOgY3xLrHTWk1lNYlvhfJ+5CF4CnhCc l+kK2JuCfi3x1ddDjBot3jrTARUawhg/+XYKq/PulDa/W4DqjWiGlA5XnRyOpoAGJl4K 4Jy8w5tKeuOrGP3lLkoN9bIJHAw8Gtks5wKM40EoIx0ge5MfiyrMe/ZEo7msQ+ZeGByD 8bMlG6gI1PEmeniEiBTmN2k/XOrGKTvYMSqVoVpMqn56r+QwHBNT1wrlXBdrShIO2fVS PuDO4MbHjSljaV5/m22kJQATAZuo0U0BsV9szo6CXrZ3Oi0xZxJ0VGoxDs7kroUgzdb2 xDHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oEC1TGaElWl1GZtaLy443jICc2i2HlzJRS/tQX16/tY=; b=oZ6/YfO2GyxBiuUmzQHElxcUvVB1+V0MU3RSHxP0XE3Vws5iJM93p+3spBfDf7IJ4G arZWUIRUoTwLgXnsRJNbNcctEZWYfYOyjmn3ZS0WdKDQodrgH1hJXiXMtZb62JrUfZd7 GFTYINDHI7c5dbjq2F9uwkvNxfWtYvR2gw2Oygo6w3eP6QUm2ayz4d3fEpHyR7NyqmaT CkM3C4tGheoJDWl4i/c251Mra0qn7qbzIrszGyqIwf6aROFIhiUlts1xiqm3GAWzQ/O9 P2OTuJKf3lpKb+0o9JCTgnwrYS0AgzryAUKxo+yYvMsyYlY1SDiwsaXFKeDR2YbGgJbW T1yQ== X-Gm-Message-State: AN3rC/5ePAx2urGqb77bW9I+ntCpszmj6eFminEPvMZztAF5hw5p34ti wJ+JeNIaVlpUCVGGzxowV0QtvCeLYw== X-Received: by 10.129.85.75 with SMTP id j72mr29329081ywb.283.1493821998428; Wed, 03 May 2017 07:33:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 3 May 2017 07:32:37 -0700 (PDT) In-Reply-To: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> From: Eric Rescorla Date: Wed, 3 May 2017 07:32:37 -0700 Message-ID: Subject: Re: Open-source TLS 1.3 with an API suitable for QUIC? To: "Eggert, Lars" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113f1ae293452d054e9f8995 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:36:40 -0000 --001a113f1ae293452d054e9f8995 Content-Type: text/plain; charset=UTF-8 I believe that NSS already has essentially what you would need, but if it doesn't, please file bugs. -Ekr On Wed, May 3, 2017 at 1:37 AM, Eggert, Lars wrote: > Hi, > > I've been looking at https://github.com/quicwg/base-drafts/wiki/First- > Implementation-Draft and wondering which open-source TLS implementations > are suitable for providing the required TLS 1.3 functionality over UDP. > Specifically, for a C implementation. > > (There is a list of implementations at https://github.com/tlswg/ > tls13-spec/wiki/Implementations, but it's not clear which - if any - > expose an API that would be suitable for operating over UDP, for use with a > QUIC stack.) > > Any pointers? > > Thanks, > Lars > > > --001a113f1ae293452d054e9f8995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that NSS already has essentially what you would = need, but if it doesn't,
please file bugs.

-= Ekr


On Wed, May 3, 2017 at 1:37 AM, Eggert, Lars <lars@neta= pp.com> wrote:
Hi,

I've been looking at https:= //github.com/quicwg/base-drafts/wiki/First-Implementation-Draft and wondering which open-source TLS implementations are suitable for pro= viding the required TLS 1.3 functionality over UDP. Specifically, for a C i= mplementation.

(There is a list of implementations at https= ://github.com/tlswg/tls13-spec/wiki/Implementations, but it&#= 39;s not clear which - if any - expose an API that would be suitable for op= erating over UDP, for use with a QUIC stack.)

Any pointers?

Thanks,
Lars



--001a113f1ae293452d054e9f8995-- From nobody Wed May 3 07:44:32 2017 Return-Path: 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 AC089129408 for ; Wed, 3 May 2017 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 kziB8FgRUooL for ; Wed, 3 May 2017 07:44:28 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D03129353 for ; Wed, 3 May 2017 07:41:39 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u70so86011093ywe.2 for ; Wed, 03 May 2017 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QwCIONGCe4CiToJIUi4FwMGPq5esYAVpEbnzAvIWtys=; b=Og7ZhEF+QkmWj9VgS8b6BsqRVzWu36vJII3ZN6hBq0Ueny0GEkBk5b+CQlY5aRCnSX 823/byd8vCgudtpawCE1VBaBMoZ6hlmnQqp5oGN9T4Anj2NVpGroKDhD1Fr9wuTbx8TY LWLVgdyAEF2YBlRyrp4Wut6UE8rmp81TpBEMKJdprsStKrNSyF8Qa+xJ0rBbCG3T7dWc tVY3EH+v/fwFVXGLkJYzP1O3Nvw/nXpRv5b4BAH6g8acndmgMat6RVoFnNzk4wWoVmyl pG+PqFHJnjvaQvqsikEdgbwoRgWTW1gZRzFb0LzwBAG/Bi0TTgrvs2OIlAPHSAtsZjtw cTyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QwCIONGCe4CiToJIUi4FwMGPq5esYAVpEbnzAvIWtys=; b=DE+4+D5IIT4jZ+/W5fl2qk1hOSzZIrJF1SlpBF1JvjWL8EfNej3BayIhgUebd1tqtO rFbqo9My9+5oYyh+HRllqZptM9zbX97lZDpYTyd2UiNKuVtHdJikTRwLVEGvjO2gmuRG ZDWHDlFS7A/sqUVJiudxgVQHrlkpw4rPXXUPl9pzGTBLdJpbA03zLRO+lAzjoFjuesnW 4r76FTMugkHV7lHtTEDFCrAmb2vN9i7U9bMx6YZc3lDgopLfEWRGttqhTTCCaWR+5UYN KuYR8kuJNOd2cV/x5e25vUHte7Wl0ILhnm00pA2XdWv4fLgugO1X3mnNaZJ2DxoPVTR2 aUWA== X-Gm-Message-State: AN3rC/6OqcBp0WVbYtE34YkSLTo/kDL19lfUZNfv5/bZHJyRoF7GFmOt n6hq7TA+KA4GOEe87Knoig0LbSv5oJez X-Received: by 10.13.245.2 with SMTP id e2mr30668530ywf.270.1493822499042; Wed, 03 May 2017 07:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 3 May 2017 07:40:58 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Eric Rescorla Date: Wed, 3 May 2017 07:40:58 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c08763a69d582054e9fa79f Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:44:31 -0000 --94eb2c08763a69d582054e9fa79f Content-Type: text/plain; charset=UTF-8 > Yes, I agree. Though I'm not as enthusiastic about a design that > makes public reset indistinguishable from other traffic. We could do > it but the only way I know how to make that work is to force endpoints > to try hashing every packet of a certain size that fails to decrypt. > It's actually pretty easy. The only reason for the hash preimage trick is that you want public verifiability. I'm going to call this "Stateless Reset" to differentiate from "Public Reset". Assume the server has a long-term key K (as in the hash design). In EncryptedExtensions, the client sends V = HKDF(K, ). When the server wants to reset a connection it generates a properly formatted packet that consists of: Header || V || And when the client receives a packet, before trying to decrypt it, it looks for V as the initial bytes. No hashing required, and it's just a memcmp. -Ekr --94eb2c08763a69d582054e9fa79f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
Yes, I agree.=C2=A0 Though I'm not as en= thusiastic about a design that
makes public reset indistinguishable from other traffic.=C2=A0 We could do<= br> it but the only way I know how to make that work is to force endpoints
to try hashing every packet of a certain size that fails to decrypt.

It's actually pretty easy. The only reaso= n for the hash preimage trick
is that you want public verifiabili= ty.

I'm going to call this "Stateless Res= et" to differentiate from "Public Reset".
Assume t= he server has a long-term key K (as in the hash design).

In EncryptedExtensions, the client sends V =3D HKDF(K, <conn-id&g= t;).
When the server wants to reset a connection it generates= a properly
formatted packet that consists of:

Header || V || <random bytes>

And whe= n the client receives a packet, before trying to decrypt it, it
l= ooks for V as the initial bytes. No hashing required, and it's just
a memcmp.

-Ekr

--94eb2c08763a69d582054e9fa79f-- From nobody Wed May 3 07:50:35 2017 Return-Path: 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 DF9DC129B36 for ; Wed, 3 May 2017 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 116DfG3wjYsR for ; Wed, 3 May 2017 07:50:32 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0114.outbound.protection.outlook.com [104.47.38.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6711F129B83 for ; Wed, 3 May 2017 07:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WDCt6u8Dwe5HIVMUXToaAohEUDIgSLOj6Mjt+RS/3CI=; b=PCpP/YfcB51v9snBVFsITersTzups7YorKmuAQXliuAv4kFOgXQs90hESn9OmYZlQeC/4iHnSSjreug5r9ipevGZ93BckYlVddiULHiE1yyMc0kDEIVWs4sE1OZpggCA+8URoWCKJ8NKTuB9ecCQhC8zm92cfuhZ0rDnp2QFINs= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Wed, 3 May 2017 14:47:53 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.021; Wed, 3 May 2017 14:47:53 +0000 From: Mike Bishop To: "Salz, Rich" , "Eggert, Lars" , "IETF QUIC WG" Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Topic: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Index: AQHSw+h0UvPKGWYvsUKaLwDx0YPN4KHiiaCAgAAmXxA= Date: Wed, 3 May 2017 14:47:53 +0000 Message-ID: References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8080:63a8:4dd8:eba1:329b:9cc7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:5KFaYc2uExrmay0ydp5bKiUcCh6bAnFtp3Ln1aNwdUVxmf7fJXf79LAln2lYgc4zbcjte9WGHmwYH6cMtWUmiJIEE9jTP+cbaBRLmFnoOJ954FKBHrZS4sHdqbqNFL9BUadL4lAnv6xnb/OINqngesu/PJH5+1SnpqZlgmKErfDNcQwVkwgK/OYTZUJvQ88Fh1rBYBBv+YM363x0GqP79GA6vYCqSv+MDPP5qQYUkynQXI+xctaCzTdM0FUfuSJy1jZCLR6Sr1jyOvVW19L1Yops2BXHEu8wrEvWaB9L8xpAqYsgpAUs+I7ukHzxw95hyB6iRwd52xBS3aUonTEwFW1jxkIVF3gx4hqwU59ujV4= x-ms-office365-filtering-correlation-id: 4108d5f1-5246-4725-6042-08d49233611f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2706; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(13464003)(377454003)(3280700002)(7736002)(305945005)(74316002)(3660700001)(6506006)(2950100002)(6116002)(102836003)(8676002)(5660300001)(81166006)(229853002)(2906002)(50986999)(122556002)(76176999)(7696004)(8990500004)(53936002)(38730400002)(8936002)(86362001)(10290500003)(9686003)(6246003)(478600001)(10090500001)(55016002)(54356999)(77096006)(6436002)(86612001)(5005710100001)(189998001)(25786009)(99286003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 14:47:53.2813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:50:34 -0000 The biggest one (and I don't know if OpenSSL has it) is the ability to get = the actual bytes that TLS wants to send, rather than having the library own= the socket and try to send by itself. With NSS, apparently you need to pa= ss it a fake socket and grab the bytes that it tries to send, which is a bi= t of a pain. SChannel's model just returns byte buffers to the caller, and= it's their job to then transport them, which is mostly what's needed here. Then there's the ability to add an extension for the QUIC parameters. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Wednesday, May 3, 2017 5:29 AM To: Eggert, Lars ; IETF QUIC WG Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC? > wondering which open-source TLS > implementations are suitable for providing the required TLS 1.3=20 > functionality over UDP. Specifically, for a C implementation. If there are API's that OpenSSL would need to provide, please let me know (= ideally within a month) and we will work to provide them. From nobody Wed May 3 08:26:24 2017 Return-Path: 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 A8860129B15 for ; Wed, 3 May 2017 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 X0Gxh0NamQBf for ; Wed, 3 May 2017 08:26:08 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 AB67F129B23 for ; Wed, 3 May 2017 08:23:27 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v43FMXYY012629; Wed, 3 May 2017 16:23:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=aAtlkM6WRP04z81m3cCSJW4o7eVivJKotDZ0mo8tX0o=; b=F9gg59UOcZgLQZzessdLjSYFwxxaQ1TyinUhMww77U43poLE8NPDEEsL7QcJchGioKUm wZQJn9VQ9ZWkzgUjSWICLSLO/xkCs5LtQk6Jwbq1WgPEtUY0/8axKcNIYhzsVkaAVwjf 2bv/YMOhgCeKzqwXJXxKAZf46FFr1HhFmUIjZXJ7BuD6uIoxsHIsI25682zKuqvEYVmf s9XJLFrpIGrCak16kNHovCpzODFdsPflLfFi65ySpOyDhJy59tYYFrkM63p29dllpUlO sRuQz0I5A4IzLXU8cZet/ZTmksbjftBlaspVNCM4OLJ8L33PSemw2nJ6H3aVlCR3U4Uj ow== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2a72my3v84-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 16:23:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v43FLGoV026361; Wed, 3 May 2017 11:23:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a72m918tw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 May 2017 11:23:24 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 10:23:22 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 3 May 2017 10:23:22 -0500 From: "Salz, Rich" To: Mike Bishop , "Eggert, Lars" , IETF QUIC WG Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Topic: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Index: AQHSw+h0UvPKGWYvsUKaLwDx0YPN4KHiiaCAgAAmXxCAAApK4A== Date: Wed, 3 May 2017 15:23:22 +0000 Message-ID: <22ba6c1d9ea44420be3de06ecef56e6c@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.217] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030284 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705030284 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:26:10 -0000 > The biggest one (and I don't know if OpenSSL has it) is the ability to ge= t the > actual bytes that TLS wants to send, rather than having the library own t= he > socket and try to send by itself. With NSS, apparently you need to pass = it a > fake socket and grab the bytes that it tries to send, which is a bit of a= pain. > SChannel's model just returns byte buffers to the caller, and it's their = job to > then transport them, which is mostly what's needed here. Yes, it can be done using a "fake BIO" which is the OpenSSL I/O abstractio= n; you can read/write memory. It's also not terrible convenient. =20 > Then there's the ability to add an extension for the QUIC parameters. This we have, and it's in better shape :) From nobody Wed May 3 09:10:17 2017 Return-Path: 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 B20F91242EA for ; Wed, 3 May 2017 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 0H-LgRjgqGi1 for ; Wed, 3 May 2017 09:10:13 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8325128B88 for ; Wed, 3 May 2017 09:07:53 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k11so87293886ywb.1 for ; Wed, 03 May 2017 09:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tlxcj4FcrJrFt00GAcWd6Ja0u/NSsb1qhtnNC5oq0Ys=; b=XiDkNrZT+mjpgfNFlK10IWsH2uDPelwzFjF2n7SkW4k4mjivcOgu0paiGDkgnMh2Ys Fq2T7UpuOe5Sc9saY1hpo0QPHrpXLFDJ0pgLbk1b/Ae7zuow1Qo5qkNTGgGGdfhrc+IJ d09yM/D/OsrHMpICqvmWIJwAfSwW0Rc+Fpwlw9YNPIM9Yi7mkxmC3TI69NdCKYf0C95y FEUXVyzbUuY3+Bemtz/dSnGDi3laO2LWWwH6GT+zDUzYtLgbhV96vHQI/UEoPOsRPDfs NBmpT9JFjtaxW/XZ/ashxG5FIJ+cbNEdY77YMEUwdet5Rb3fOPVlg4m+inxL5fhQl0r4 v33w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tlxcj4FcrJrFt00GAcWd6Ja0u/NSsb1qhtnNC5oq0Ys=; b=prqGx/WCr8Z/d5Ptv05lf+YmqNxk9lw2btzdgekUwyT7wq5uNmN06TJML/SmRGw4Of Sp+L1yIm1jj2Rclp7FXY4w4j+g/4KClbGkhUPlhivQmMPQJfN5KbUyPdVV+b38mucwL7 /2ft0VicDTWsa0OUHvFz1uws+jNLKeW+MWoOSrsuXWOhY6VtaXXU65wfc+ZKq+FTtnJD XZMda8fipXQuzXPTT7jqvTTrsAPwEaHO4c1XBDORbq9XUxZyVDMp0g8yA5MZ99BkXtc1 LwxT13jenwiDkS5bA27bpgO9S0iQ9Mq9/44GR+L7o9800sVqbxSrEQGHN43u6AW2EORY pG6Q== X-Gm-Message-State: AN3rC/49epLxccPGjn5Sf54zgJQQyo15AwL6UjDURQaaKQD9Wk6KuxX3 YK1sKCdgDXKcKxaownkcKZK3SOQfOA== X-Received: by 10.13.212.65 with SMTP id w62mr28698563ywd.24.1493827673090; Wed, 03 May 2017 09:07:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 3 May 2017 09:07:12 -0700 (PDT) In-Reply-To: References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Wed, 3 May 2017 09:07:12 -0700 Message-ID: Subject: Re: Open-source TLS 1.3 with an API suitable for QUIC? To: Mike Bishop Cc: "Salz, Rich" , "Eggert, Lars" , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114fc7d8cfcea8054ea0db31 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:10:15 -0000 --001a114fc7d8cfcea8054ea0db31 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 7:47 AM, Mike Bishop wrote: > The biggest one (and I don't know if OpenSSL has it) is the ability to get > the actual bytes that TLS wants to send, rather than having the library own > the socket and try to send by itself. With NSS, apparently you need to > pass it a fake socket and grab the bytes that it tries to send, which is a > bit of a pain. Yeah, but it's pretty straightforward. See: http://searchfox.org/nss/source/gtests/ssl_gtest/test_io.h#53 SChannel's model just returns byte buffers to the caller, and it's their > job to then transport them, which is mostly what's needed here. > > Then there's the ability to add an extension for the QUIC parameters. > Right. We would need to add that. We haven't added that to NSS, but it's not cpmplicated -Ekr > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Salz, Rich > Sent: Wednesday, May 3, 2017 5:29 AM > To: Eggert, Lars ; IETF QUIC WG > Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC? > > > wondering which open-source TLS > > implementations are suitable for providing the required TLS 1.3 > > functionality over UDP. Specifically, for a C implementation. > > If there are API's that OpenSSL would need to provide, please let me know > (ideally within a month) and we will work to provide them. > > --001a114fc7d8cfcea8054ea0db31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 7:47 AM, Mike Bishop <Michael.Bishop= @microsoft.com> wrote:
The biggest one (and I don't know if OpenSSL has it) is = the ability to get the actual bytes that TLS wants to send, rather than hav= ing the library own the socket and try to send by itself.=C2=A0 With NSS, a= pparently you need to pass it a fake socket and grab the bytes that it trie= s to send, which is a bit of a pain.=C2=A0

= Yeah, but it's pretty straightforward. See:


SChannel'= ;s model just returns byte buffers to the caller, and it's their job to= then transport them, which is mostly what's needed here.

Then there's the ability to add an extension for the QUIC parameters.

Right. We would need to add that. We hav= en't added that to NSS, but it's not cpmplicated

-Ekr
=C2=A0

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Salz, Rich
Sent: Wednesday, May 3, 2017 5:29 AM
To: Eggert, Lars <lars@netapp.com= >; IETF QUIC WG <quic@ietf.org&g= t;
Subject: RE: Open-source TLS 1.3 with an API suitable for QUIC?

> wondering which open-source TLS
> implementations are suitable for providing the required TLS 1.3
> functionality over UDP. Specifically, for a C implementation.

If there are API's that OpenSSL would need to provide, please let me kn= ow (ideally within a month) and we will work to provide them.


--001a114fc7d8cfcea8054ea0db31-- From nobody Wed May 3 14:58:31 2017 Return-Path: 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 3C9701271DF for ; Wed, 3 May 2017 14:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OFopcFXEgdDi for ; Wed, 3 May 2017 14:58:28 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4950128D16 for ; Wed, 3 May 2017 14:57:02 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id h4so1395641lfj.3 for ; Wed, 03 May 2017 14:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wSf41EuErkHDlxi12crBxCG2dk3iZqwS/Z4PZFiioVE=; b=QiJYH6yuc/ZdJ3TF149uKkIsmkBxy0zT246SuhthrdVoIxOS6T80abDPHQasn/nvb/ 4Y4kSp5AaOgYM0RK/quBQjJEzqvl9nZbfWOX78AxBpnYBNXq2Pj+nMMF1bzrpcDyHZs9 UClUPhMP7MeB+chkLqFnYqYB2G+Hs6L+QlCcsWNH4c5sY/073JUf28jScQRzJncaV/Q2 zUZsboyr6Z5529hy03fboySEWFjrBY56xVVQQq2gIS2G/hy8CGF5iA9XP0LoeQcXl9X0 H5HlOyu/nEVG15Ib5sogenUPLiAA40+b6mkWfc8CtnM7povvV9HaoKKtVkEKsvDP5Yhl fK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wSf41EuErkHDlxi12crBxCG2dk3iZqwS/Z4PZFiioVE=; b=csQB1ZDq9PyFHJjoi1MM3W+Ofvb2Jrfq2tU959tSSIo+Fx5nxl8f2J8P7OEOzF2dJc X/DVE9vIkqOCrG6XyXnj6dmGINnYEyW/o/k9/WHFnx3+GhFchzwDTXqtcyOmUWoP1PZ9 ZpQhCCTVVasZ/YaL3gXySESqErqg+/T7LaTKeEsBRBDXtaUmi+Gol8EeIkkojr0w6ZdO L+GisNEm15JRntX77XKjQL3+klRYgDRWtNzQuSO2MKyXAz9we7sgEH/TWD0g2hz63cJ6 0wSKjPB1VUVgPNkHzDcCDdP6ZVDq37L/yJT2LDHnybMO8RxYRAExA5X0MYNCotARTHwu TY+Q== X-Gm-Message-State: AN3rC/7KPeDTUSSnnLu+KTKlKM458EmTX/eKg2XASvKcqZfzdmv3oJqx IUbDIrGO7quPTO3e8Aw9UFwRZ4VvQjYk X-Received: by 10.46.8.26 with SMTP id 26mr13625961lji.128.1493848620974; Wed, 03 May 2017 14:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 14:56:59 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Thomson Date: Thu, 4 May 2017 07:56:59 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Eric Rescorla Cc: Brian Trammell , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:58:29 -0000 On 4 May 2017 at 00:40, Eric Rescorla wrote: > In EncryptedExtensions, the client sends V = HKDF(K, ). I think that Christian's idea works well enough. This one requires an impossibility :) From nobody Wed May 3 15:02:02 2017 Return-Path: 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 1DE8912947F for ; Wed, 3 May 2017 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 S-w0GXRdtrfT for ; Wed, 3 May 2017 15:01:58 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C8E129524 for ; Wed, 3 May 2017 15:00:02 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l135so514391ywb.2 for ; Wed, 03 May 2017 15:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aVuOx1VBgCOUdWFlugcx9g0rnQGYoSKQt/pSJErEWOc=; b=fGpQUk7lxIlHBGzzcB6ptu/pRIPUcPOODMon2t9j54Y2X7mGdACkY9TyPe8TY39Bk5 G2re5eZ3+0Scv5+PROF1kwDMCeK6gVa8J1qbj4p4U0QuhaQ434xgw3vM5zI9+rBQi1Pe MzmtXj7WYrPnb60S1TYCQVTtoE2O+QwvTsDR/727+1SAJF9A+o7Fjma2jVT7XyUQ2/Ql ZJqX5Z1bqeyQY96exIaLod/GgfR+OXrCWAlRDRqOEZYtwOiPE8yoovdshSlgQRqUscWo NfU3DfkjCgyLwsDsfZnILKrvW6IiY2decO/QQJYXX8swZxiB+3XPPwMCCBQNL5mh2Piq gePQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aVuOx1VBgCOUdWFlugcx9g0rnQGYoSKQt/pSJErEWOc=; b=r+ASTN1nlU99dQ1cUXvomvCigH8c80Ta4Jmfr/jVf3bAXUSET36FqTE/X7fBTVhEcV iqP1aOzLF7AwnEckkvJNZFk5iCnpI4yUg+qB8cAfFkNRJvr8s/ynEgbAWRzFWxANQdD7 mwN1PIEkxh5rsu1ShnZ+EBaC488+Q4bKvn/LSRYKVb9TXb0vyCaUhaD76JKto0EGTQa/ FmBLFyS+yB+O79kb/I7j2xQK2YQrkPmFBh0zQ7HxTpHSiUCIWIAGJUxFFzEETjl4nmpA 8YZez7kwODUYMpUzd+Tb5H4MemaOAHIZCe0LeBujrd8E1yhW9Vz0RcQdTecXAfo7IUN/ jWdA== X-Gm-Message-State: AN3rC/4+ugXbETEVDqPOhZ8E4Fyv64RwWu6GA3v6cL6va6LG+3HH24p3 9terHUeHd2N34wYCZN6P74scVIAsMg== X-Received: by 10.13.255.199 with SMTP id p190mr14703576ywf.312.1493848801968; Wed, 03 May 2017 15:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 3 May 2017 14:59:21 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Eric Rescorla Date: Wed, 3 May 2017 14:59:21 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c087eea30baae054ea5c721 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:02:00 -0000 --94eb2c087eea30baae054ea5c721 Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 2:56 PM, Martin Thomson wrote: > On 4 May 2017 at 00:40, Eric Rescorla wrote: > > In EncryptedExtensions, the client sends V = HKDF(K, ). > > I think that Christian's idea works well enough. This one requires an > impossibility :) > Why is this an impossibility? -Ekr --94eb2c087eea30baae054ea5c721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2017 at 2:56 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 4 May 2017 at 00:40, Eric Rescorla <ekr@rtfm.com> wrote:
> In EncryptedExtensions, the client sends V =3D HKDF(K, <conn-id>= ).

I think that Christian's idea works well enough.=C2=A0 This one = requires an
impossibility :)

Why is this an impossi= bility?

-Ekr
=C2=A0

--94eb2c087eea30baae054ea5c721-- From nobody Wed May 3 15:46:02 2017 Return-Path: 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 03826126C26 for ; Wed, 3 May 2017 15:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EasAklqEWS1h for ; Wed, 3 May 2017 15:46:00 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC3C1243F3 for ; Wed, 3 May 2017 15:45:59 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id j1so932423lfh.2 for ; Wed, 03 May 2017 15:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G6VKdkA1L9AJKMBEPIV0ACL/Ci9HrGu262XJ1q2qZVY=; b=tTDpMUGbWBOiHNp6GZrQtgWbA51xYGq9/zsEMEISNJTupID7oo3fhFGyJ2LESiY8GP uFScOtZfrqtkZsgcC/f20G3MqOrQ0ozyMosy7st4FWFnGzZOsEYjgf0GHGuhpX0A2neV SU2b0TtFEegM+c0Z5zrvwfgVd8vuu1pCdUCDs+nBxWSJ+XXF+P4FY+g1+etYEx4jJUxN qIF8Cim9W3CwJ8ThhYwerJS+YQx2uSbdSL3SHqpwy7dmr5MfdjVcI5tPIVji+1L9WbP6 FepGnNT6lVFcElR/ho6WE5zW/91LkRnDTREPAAkcP46xtVJ0DarQm6NBapblN2zQUIxA no3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G6VKdkA1L9AJKMBEPIV0ACL/Ci9HrGu262XJ1q2qZVY=; b=PJX1D8F8nVpgK6U0/HZXH61h+9+zDicRd6Bdbkmjtu/dRza3PI/1th0Yj569MwqDR5 H3fnFiqzkfY2MJ2Eu5NP+QA/2fEuCLo6ec2bSSUgwREKZV5+uT4YEN0r7FEAv8LO3fnc djedOCLI2KiaSflCGtPJnIslF/S7UqJ1ja5W8Dn0VpojgoUEpEIMuQkN5advzp+w/EO5 Ch97aiGJt7slcckD9cJtygK0LgLZU6ya/RgFxYZYsjPQ14BwmRk8ei6wnW2C8tzfvapZ L424JOzoOYJ7FtHqqeVTpLQhbEc7RI3tvFMBg9N8uX2OCULEpKG4IQXjfwgVUnxtuzvc lvmw== X-Gm-Message-State: AN3rC/6A7hdIGHPBzD/96liG0sJOnJEhmNSeEbtgkxabd2ZcBzNa7+7G Th97HmwvN0NR6rb8nNamxrpdVSy5Qw== X-Received: by 10.46.8.26 with SMTP id 26mr13691613lji.128.1493851557973; Wed, 03 May 2017 15:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 15:45:57 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Thomson Date: Thu, 4 May 2017 08:45:57 +1000 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Eric Rescorla Cc: Brian Trammell , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:46:01 -0000 On 4 May 2017 at 07:59, Eric Rescorla wrote: > On Wed, May 3, 2017 at 2:56 PM, Martin Thomson > wrote: >> >> On 4 May 2017 at 00:40, Eric Rescorla wrote: >> > In EncryptedExtensions, the client sends V = HKDF(K, ). >> >> I think that Christian's idea works well enough. This one requires an >> impossibility :) > > > Why is this an impossibility? The client doesn't send EncryptedExtensions. Maybe you meant exactly what Christian said and the V is sent by the server? From nobody Wed May 3 15:48:14 2017 Return-Path: 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 39DE1126C2F for ; Wed, 3 May 2017 15:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 hqI49vcEUUNQ for ; Wed, 3 May 2017 15:48:02 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5AA126C7A for ; Wed, 3 May 2017 15:48:02 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id 8so976526ybw.1 for ; Wed, 03 May 2017 15:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cy8cUgmNn8ni9qVc7euPkQzpe8rALU3cjOrE44z2Jbg=; b=p3YhmW3KazU/KM5aIRpNpGEf0AihfrPvUsMZ/x7I4DC/0dDvlz7e+V/ken04cJx0ss p/V0dA8hldIkKnBSFeHNBSqXiviIBI8fjpQrs3kN3vXPtSUPpVM06s7yxFdol2Y0FbLp Ot53XTU3y3eF/yah48PMXbYgQYOn3X4Hzww/oKcLMk6Lz1TUmp1NArWME0UjqQ71Bcl1 SGTPPEkZwzufGkMKlxqhsw7bHg7RKY+30FbI5k4hPR4cgIt60FAjfgjLx7Wx0GPj3NuZ kBR907Li8f41GTIOhzG39J2+TsjP1LPuB5swnR66TWZi3N2jme2ZVkaTkzCziqMArgAD uWAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cy8cUgmNn8ni9qVc7euPkQzpe8rALU3cjOrE44z2Jbg=; b=rEiANEOSC0EaScJmDk5WzVMSvjORN+6yxFwr1EgcL+MQ+M7FMlMlkY8KIxxX8yWcCI xS0Q1F2nboPZHMrO2d/9m5OgqTayF4SmTiWnfk0gSKm8ltIf3GVz4/E6THCM5zkPvJQZ L82amJXgVlzEqPfUGC2vkbGyabfmUTmFMHZUnYocN0mTMhLyXMtTX9fSnrRKBx3J0IAc 8uPsjD+OIpe6a6mUPs9LunnKtxA2yKPvpW2UjW+5oTTyWhM9sR//Wub7bqIoupmTSocj oBm89rhIjdEb7mgQzyDyMyDu8yuDu0tkO47WdAiQ960U2i18FAkqJ9E5cMWRV1h0Ij0J rQJw== X-Gm-Message-State: AN3rC/7+J+FvqiPfOf8b6OeIOd+nl9IVmTbCqNgloyCmO7C6eKx9A9nv CaKw2NiJ5+dtrOSq5BEDBSWgLyVZtA== X-Received: by 10.37.215.15 with SMTP id o15mr32785196ybg.119.1493851681260; Wed, 03 May 2017 15:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 3 May 2017 15:47:20 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Eric Rescorla Date: Wed, 3 May 2017 15:47:20 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Martin Thomson Cc: Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c09dc36cfe265054ea6729c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:48:03 -0000 --94eb2c09dc36cfe265054ea6729c Content-Type: text/plain; charset=UTF-8 Yes, I meant the server. -Ekr On Wed, May 3, 2017 at 3:45 PM, Martin Thomson wrote: > On 4 May 2017 at 07:59, Eric Rescorla wrote: > > On Wed, May 3, 2017 at 2:56 PM, Martin Thomson > > > wrote: > >> > >> On 4 May 2017 at 00:40, Eric Rescorla wrote: > >> > In EncryptedExtensions, the client sends V = HKDF(K, ). > >> > >> I think that Christian's idea works well enough. This one requires an > >> impossibility :) > > > > > > Why is this an impossibility? > > The client doesn't send EncryptedExtensions. Maybe you meant exactly > what Christian said and the V is sent by the server? > --94eb2c09dc36cfe265054ea6729c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I meant the server.

-Ekr


= On Wed, May 3, 2017 at 3:45 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 4 May 2017 at 07:59, Eric Rescorla <ekr@rtfm.com> wrote:
> On Wed, May 3, 2017 at 2:56 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 4 May 2017 at 00:40, Eric Rescorla <ekr@rtfm.com> wrote:
>> > In EncryptedExtensions, the client sends V =3D HKDF(K, <co= nn-id>).
>>
>> I think that Christian's idea works well enough.=C2=A0 This on= e requires an
>> impossibility :)
>
>
> Why is this an impossibility?

The client doesn't send EncryptedExtensions.=C2=A0 Maybe you mea= nt exactly
what Christian said and the V is sent by the server?

--94eb2c09dc36cfe265054ea6729c-- From nobody Wed May 3 23:09:52 2017 Return-Path: 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 802B7129BAA for ; Wed, 3 May 2017 23:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 j4sc_p29BIJL for ; Wed, 3 May 2017 23:09:48 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBE5129BA2 for ; Wed, 3 May 2017 23:09:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,286,1491289200"; d="asc'?scan'208";a="186385358" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx142-out.netapp.com with ESMTP; 03 May 2017 22:54:20 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 May 2017 23:08:44 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 3 May 2017 23:08:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mBBWftoBXPcM+ul7byUEs85OPOj8D0agEKilopOVpuk=; b=l+Af2zjSv/ZBo13LBmTo3j7u+zfcW4I0o051Pvkb2wWhtbem1QslRRaSFcyfNTGyOHAKqMmAv2iURE8P7ppIbqtPKg3DHXl5309RXGB/+UEgT1DXBQa6QeYwSDsRJ6ccyob/R4ZpaPO/o5/yghmoQISzHRSo2gd1G8n49imQs+s= Received: from BY2PR06MB1765.namprd06.prod.outlook.com (10.163.33.19) by BY2PR06MB1766.namprd06.prod.outlook.com (10.163.33.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 06:08:44 +0000 Received: from BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) by BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) with mapi id 15.01.1061.021; Thu, 4 May 2017 06:08:44 +0000 From: "Eggert, Lars" To: Mike Bishop CC: "Salz, Rich" , IETF QUIC WG Subject: Re: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Topic: Open-source TLS 1.3 with an API suitable for QUIC? Thread-Index: AQHSw+h0/vLwJjrcKkeKu/Qa/TsJk6HiidCAgAAm24CAAQFHgA== Date: Thu, 4 May 2017 06:08:44 +0000 Message-ID: <5F5912AC-80F4-46EB-924B-F97657CEFA4B@netapp.com> References: <3F1D7623-C8CD-4B1F-96BC-31AC90B4C14E@netapp.com> <49e395dc4c6f47b7908f57ba06d18c40@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR06MB1766; 7:oUaBPEI1Jvy+4c11x9c4+85U1nMQAzhCaQKLKYGB6yVNhA1LGHmpfHz1xakJuCdz04kSeIZOuFwFpEH77aaM1fmH1fEy/3QYq8uYY9pCvVzkJB+aOMvXD5E2F6A3X7KaVtL7priZ0gIhyVMikBEOyTOIgE4kvTfN2MNWQE8W+0BJCvFEJ2S/jwIes/yDyLG899G7Q2RJh28ge91635vEM9nccRmWYPIWyWyUUITqN28u9Ag6+a3fkFodDtMdCQm9qtJghAQbRjFNRad3B0aRDr3tPSOzNjhqnhs26SDN3HpsLsg04dAbT79dSRC6s2YJFC8j73iR87RutnnCPSthhA== x-ms-office365-filtering-correlation-id: d0e60699-18f4-4596-02a9-08d492b4051b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR06MB1766; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(6072148); SRVR:BY2PR06MB1766; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB1766; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(24454002)(377424004)(6246003)(229853002)(305945005)(6436002)(53546009)(50986999)(7736002)(57306001)(38730400002)(76176999)(77096006)(6486002)(66066001)(53936002)(478600001)(81166006)(33656002)(54906002)(99286003)(6506006)(189998001)(6512007)(8676002)(6116002)(50226002)(8666007)(110136004)(8936002)(102836003)(3846002)(86362001)(36756003)(2421001)(3660700001)(2950100002)(99936001)(5660300001)(82746002)(6916009)(1511001)(25786009)(122556002)(83716003)(3280700002)(2900100001)(4326008)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB1766; H:BY2PR06MB1765.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_C867A3A9-3995-412F-80DF-6602BC918403"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 06:08:44.2056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB1766 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 06:09:49 -0000 --Apple-Mail=_C867A3A9-3995-412F-80DF-6602BC918403 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-5-3, at 16:47, Mike Bishop wrote: > The biggest one (and I don't know if OpenSSL has it) is the ability to = get the actual bytes that TLS wants to send, rather than having the = library own the socket and try to send by itself. exactly. And - since I'm trying to reduce memory copies - I'd like to = pass TLS the buffers and have it operate on them, ideally in place. Lars --Apple-Mail=_C867A3A9-3995-412F-80DF-6602BC918403 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlkKxWsACgkQVLXDCb9w wVdnrQ/9EsFyIhlONdnhpdeKg5oe/Cne7D+QFBt4GjB6508L6EAzfN+GNBtgFXYy Bf5l4rloc8OYZ5Jw5frwlqBDJEU27hrEKz2Kf1NhtlOuR7D1wbZZaXqIgN5Qd8Tr E851nGk5dl3mbZNhXFXMx+N3D6B+ox+PU7CJTWbncPtHxVBEdcEzUwx7YCaeUofZ rWdixL0VDis85wq3vQ/I7gm/OsWwkkp0jm8j0Y/4EaKZReeoQnk/+HNqm8QJpC1o Hxzz8HczofC/glM38M4g8Xzy6q4gYGWf6xBnSdBqXkfgHND/2exRJ34IP0RfJoJs 3ZYB1MriPcJxEUoBI05mOXdh2rsOvOoybnwBkd+hA01WqseU+NMdZ2mCYfbbjKXs SNoEpr4A/svPIoBFgMHvG1/ML1Up5dLuRmcUAQ/uFS8iiuvEq+QhPD00ZBpuo1He UbfoqS422oRZ0N4XoFV5DqPY4zuH8L2v1OHLMdTaeCW+k9xHzb5x7AL1Ju+xeVgc 5Sa2vjT/dVcwfwk7f96T2vOuKScwzA27QNY0WsU0PPHhQTyn0Laj4iF49sEPDK3x XezjL/6Gfpzq8AYqMXmCHFR1OXgSw5AZ2oCMdy9iQlmNW0QaXczyk2B4kM5UeG06 IJy1Z+AfvetBipph8Fs44QUPLQ4OjNvFotpu/+3Hr9ojPCvovkg= =koi2 -----END PGP SIGNATURE----- --Apple-Mail=_C867A3A9-3995-412F-80DF-6602BC918403-- From nobody Thu May 4 00:38:01 2017 Return-Path: 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 35427129534 for ; Thu, 4 May 2017 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nRgFkI68yzCv for ; Thu, 4 May 2017 00:37:57 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49664129BC6 for ; Thu, 4 May 2017 00:37:57 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e64so3801961pfd.1 for ; Thu, 04 May 2017 00:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NBolvHcIjTmXC7MaqIh37cxLWl2pmPV742voGLAMO1E=; b=c5GVxUNHhH7o/RutarbHFIIKnUHviUA7TUZLyptrljzKGWutNQFxFlPiAOV3aw1GAp ns2XFwg3hvsM3aogKvDYTaS9rvda/PsYZ+90eY1E/oxnWbGM+39lvfeqc2zpzsX471EP OajsWv1zcNtGgpjzKuH3s7g6//xCVTpClrYtLX3O7fiZgBI23bTyOBH2Vb/85GPvKyW3 sWGwNOKwInrBFgw/WTWu+hCcSKUw/JjRkvNhW8CymCwxHMg32qxl9gwT17MJHXE2GUVF 6PRTlDSSUaNGtnZWaoiKXub4jCHJIrjlBN+i5z9+M4st1DqMvKT1Uhb/axP3PLVcuCsb G+fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NBolvHcIjTmXC7MaqIh37cxLWl2pmPV742voGLAMO1E=; b=hI6Hx0689+ZuD48nE6PsXJUFrcQJFXb+CS9F6ztWYpkZi8a0YwWKMomZEDKyMWJTxE +JTE/DIKO2B5PcijoI9TYSjpxGerfb/gByxbDzOEOaXSdUdMHpbVRQlEh2NlpKCTXQQW PpO6pEKCk4l2GYm1J812eDH3roEHTaZ2jb9BGyGdeMzdTS3CVYQzNbgrRV1yxP7MqhM7 ra38yAPKrRcjtIrSsjjKhP4GBGepL/ZX4WUwI5s3Ylwt7RMQK0qeIDy/h4MzPrnnOH9M 3GFWFBSHuo2bBeITCrbfGwo+dY0L2FnaQSe9rGzjm84diDmoro470ugFMWJtUK2QTLOZ 7tqw== X-Gm-Message-State: AN3rC/78cLGUBZr/YroWJ7XVX+QD2qRs56fwk7gPyNwBL6dc4a+gKJ/x cpYs0LOXALc32PWDGCcXLvKakadxn3fn X-Received: by 10.98.216.134 with SMTP id e128mr8996420pfg.79.1493883476666; Thu, 04 May 2017 00:37:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.74 with HTTP; Thu, 4 May 2017 00:37:56 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 4 May 2017 00:37:56 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary=001a11467bd2f6cc3d054eadd98b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 07:38:00 -0000 --001a11467bd2f6cc3d054eadd98b Content-Type: text/plain; charset=UTF-8 I commented on the PR, but echoing it here as well -- I think this is a very nice set of improvements. On your alt designs: The server has no way of ensuring that the Client Cleartext packet contains the server's chosen connection ID. A bold client could start a connection with a random (or if nefarious, a targeted) connection ID with a Client Cleartext packet, defeating one of the purposes of server-chosen connection IDs. I'll argue for two things to change. (i) I think we should make both the changes you propose -- that a Client Initial packet be sent right after both Version Negotiation and Stateless Retry packets. (ii) 0-RTT packets MUST contain the same connection ID as in the client's most recent handshake packet to make it possible for load balancers to work with them. With these changes, a server treats all Client Initial packets similarly, in that it responds to them with a new server-chosen connection ID. Load balancers treat all Client Initial, Client Cleartext, and 0-RTT packets as containing a client-chosen connection ID, and other packets as containing server-chosen connection IDs. One of the purposes of this change is to enable a server to direct a client towards a particular server via the connection ID in a Version Negotiation or a Stateless Retry packet. A server can still do that by generating a connection ID that it knows will hash to the right server. Basically, load balancers will use two functions for hashing connection ID -- C() to hash client-chosen connection IDs and S() for server-chosen ones. On a VN or SR packet, the server needs to generate and send a connection ID so that C(connection ID) sends the retrying client to the desired server. This allows a server to redirect while also allowing the server infrastructure to not trust that a client is doing the right thing. On Wed, May 3, 2017 at 3:43 AM, Martin Thomson wrote: > Issue: https://github.com/quicwg/base-drafts/issues/442 > > I've heard quite a few concerns about the current design for server > selection of the connection ID. The primary concern is that the > choice of final connection ID is made on the same flight as the server > handshake messages - the same flight where the server is required to > commit non-trivial state and computation resources to the connection. > > The current design is actually anathema to certain load balancer > designs. If the node that receives a packet wants to get rid of it > before sending the final server flight, the load balancer can no > longer route statelessly. > > The server folks I've spoken to want to pick a connection ID during > both version negotiation and stateless reject/address validation. > This allows them to do trivial or at least lightweight processing on > the node that receives the first packet AND steer the packet to the > right node. > > > I'm proposing that we move to a special "first client packet" approach > rather than a "last server handshake packet" approach. This allows > servers to identify which packet has a client-selected connection ID > and create special logic for that. > > > Issue: https://github.com/quicwg/base-drafts/pull/482# > discussion_r114445062 > > The second problem is one that arises from stateless rejects. A few > people observed that there is a disconnect between what the server > sends in a stateless reject and what it subsequently sends. > > For instance, the server can't generate a stateless reject then send > subsequent packets with the expected packet numbers. The reason: it > might need to generate multiple stateless reject packets in response > to multiple handshake attempts from a client. It can't save the > packet number it chose in the cookie it sends because that would mean > sending different values for the same octets on stream 0 and clients > could get confused by that. > > Also, it was previously necessary to resort to shenanigans at the > server after a stateless reject. The second ClientHello will start at > a non-zero offset on stream 0, but the server will effectively have > never received that data. That means pretending that the data was > received and delivered already, but then being able to validate the > offset and back out the change if validation fails. > > > All in all, that's more special handling than is ideal. Jana proposed > resetting the transport side of things when this happens. That means > resetting the stream 0 offset and not getting bent out of shape when > the server chooses a non-contiguous packet number. That seems like a > reasonable idea, and I'm proposing a new cleartext message type for > that so that it can be explicit when the server is doing this. That > message comes with its own special treatment (it is used for > HelloRetryRequest only, and HelloRetryRequest has to use it, it has to > be one packet). > > This externalizes some of the server costs for stateless rejects, and > it adds another special case packet type. Neither of which I'm > entirely happy about, but it seems like a reasonable compromise. > > > These are two separate issues, but they are intermingled in annoying > ways, so I have a single draft PR for both changes: > > https://github.com/quicwg/base-drafts/pull/493 > > There is a question in the PR about two alternative designs: > > 1. Require the client to send an initial packet after version > negotiation on the basis that version negotiation is a complete > do-over. > > 2. Maybe also after a stateless reject, which would mean that all > packets containing the ClientHello would use that "initial" type. That > would mean that only the initial type would have packet size > restrictions, which is nice. > > I think that these could be an improvement, but I'd like to hear from > server folks. The cost here is that after version negotiation and > maybe also a stateless reject, you would route the packet from the > client as if it were a client-selected connection ID. I'm not sure > how much that matters. What you do get is up to three opportunities > to reroute a client (during version negotiation, optionally during > stateless reject, and during the handshake). > > --001a11467bd2f6cc3d054eadd98b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I commented on the PR, but echoing it here as well -- I th= ink this is a very nice set of improvements.

On you= r alt designs: The server has no way of ensuring that the Client Cleartext = packet contains the server's chosen connection ID. A bold client could = start a connection with a random (or if nefarious, a targeted) connection I= D with a Client Cleartext packet, defeating one of the purposes of server-c= hosen connection IDs.

I'll argue for two thing= s to change. (i) I think we should make both the changes you propose -- tha= t a Client Initial packet be sent right after both Version Negotiation and = Stateless Retry packets. (ii) 0-RTT packets MUST contain the same connectio= n ID as in the client's most recent handshake packet to make it possibl= e for load balancers to work with them.

With these= changes, a server treats all Client Initial packets similarly, in that it = responds to them with a new server-chosen connection ID. Load balancers tre= at all Client Initial, Client Cleartext, and 0-RTT packets as containing a = client-chosen connection ID, and other packets as containing server-chosen = connection IDs.

One of the purposes of this change= is to enable a server to direct a client towards a particular server via t= he connection ID in a Version Negotiation or a Stateless Retry packet. A se= rver can still do that by generating a connection ID that it knows will has= h to the right server. Basically, load balancers will use two functions for= hashing connection ID -- C() to hash client-chosen connection IDs and S() = for server-chosen ones. On a VN or SR packet, the server needs to generate = and send a connection ID so that C(connection ID) sends the retrying client= to the desired server. This allows a server to redirect while also allowin= g the server infrastructure to not trust that a client is doing the right t= hing.


On Wed, May 3, 2017 at 3:43 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
Issue: https://github.com/quicwg/base-d= rafts/issues/442

I've heard quite a few concerns about the current design for server
selection of the connection ID.=C2=A0 The primary concern is that the
choice of final connection ID is made on the same flight as the server
handshake messages - the same flight where the server is required to
commit non-trivial state and computation resources to the connection.

The current design is actually anathema to certain load balancer
designs.=C2=A0 If the node that receives a packet wants to get rid of it before sending the final server flight, the load balancer can no
longer route statelessly.

The server folks I've spoken to want to pick a connection ID during
both version negotiation and stateless reject/address validation.
This allows them to do trivial or at least lightweight processing on
the node that receives the first packet AND steer the packet to the
right node.


I'm proposing that we move to a special "first client packet"= approach
rather than a "last server handshake packet" approach.=C2=A0 This= allows
servers to identify which packet has a client-selected connection ID
and create special logic for that.


Issue: https://github.com/quicwg= /base-drafts/pull/482#discussion_r114445062

The second problem is one that arises from stateless rejects.=C2=A0 A few people observed that there is a disconnect between what the server
sends in a stateless reject and what it subsequently sends.

For instance, the server can't generate a stateless reject then send subsequent packets with the expected packet numbers.=C2=A0 The reason: it might need to generate multiple stateless reject packets in response
to multiple handshake attempts from a client.=C2=A0 It can't save the packet number it chose in the cookie it sends because that would mean
sending different values for the same octets on stream 0 and clients
could get confused by that.

Also, it was previously necessary to resort to shenanigans at the
server after a stateless reject.=C2=A0 The second ClientHello will start at=
a non-zero offset on stream 0, but the server will effectively have
never received that data.=C2=A0 That means pretending that the data was
received and delivered already, but then being able to validate the
offset and back out the change if validation fails.


All in all, that's more special handling than is ideal.=C2=A0 Jana prop= osed
resetting the transport side of things when this happens.=C2=A0 That means<= br> resetting the stream 0 offset and not getting bent out of shape when
the server chooses a non-contiguous packet number.=C2=A0 That seems like a<= br> reasonable idea, and I'm proposing a new cleartext message type for
that so that it can be explicit when the server is doing this.=C2=A0 That message comes with its own special treatment (it is used for
HelloRetryRequest only, and HelloRetryRequest has to use it, it has to
be one packet).

This externalizes some of the server costs for stateless rejects, and
it adds another special case packet type.=C2=A0 Neither of which I'm entirely happy about, but it seems like a reasonable compromise.


These are two separate issues, but they are intermingled in annoying
ways, so I have a single draft PR for both changes:

=C2=A0 =C2=A0https://github.com/quicwg/base-draft= s/pull/493

There is a question in the PR about two alternative designs:

1. Require the client to send an initial packet after version
negotiation on the basis that version negotiation is a complete
do-over.

2. Maybe also after a stateless reject, which would mean that all
packets containing the ClientHello would use that "initial" type.= That
would mean that only the initial type would have packet size
restrictions, which is nice.

I think that these could be an improvement, but I'd like to hear from server folks.=C2=A0 The cost here is that after version negotiation and
maybe also a stateless reject, you would route the packet from the
client as if it were a client-selected connection ID.=C2=A0 I'm not sur= e
how much that matters.=C2=A0 What you do get is up to three opportunities to reroute a client (during version negotiation, optionally during
stateless reject, and during the handshake).


--001a11467bd2f6cc3d054eadd98b-- From nobody Thu May 4 02:05:52 2017 Return-Path: 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 D4453129BCD for ; Thu, 4 May 2017 02:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HuN49Rmei_4p for ; Thu, 4 May 2017 02:05:49 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D1212420B for ; Thu, 4 May 2017 02:05:49 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id j1so4175246lfh.2 for ; Thu, 04 May 2017 02:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6icRgIUKp0uthArw0IgTRIJIIkTH4vD1x6Lo6Q2vJak=; b=NumikGqjZT5rzdT8Fqvsj1NqmGFcsO68sbMGRwDYIK5X8nw6QPeJOa6LCtZkvaIM2S p0ky5DxPkAWJijAkmSZwi9aQF5KrWiKL9KRptAFgcAWyh3eC7s5d8XdWJw1Pc8MMM2J2 EbYWhCQdL1Hkb3S+V7pAxhX0myQhAuLSzCvbzQv3Js/njVEji7l3aAUXD7olwmOYH9TR QsL8zPUUerz4vMnfg8hOE1BldxmxeKrbKjQ/+KFnVdgjo/VHL8gfw3i9BjG7d+OTglyd 7Kip5RnhZACRMWyZOkn+L6TAycG51WnG8pf6itAYyzJp3xYjr03G7PoFC1VChXx8otfJ fc+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6icRgIUKp0uthArw0IgTRIJIIkTH4vD1x6Lo6Q2vJak=; b=ZIgwtCOM7tB7oeA9D+g6AQ8CzZw4hAAuLg+OVvDPJzb/iia31StLco52vY3aUxYTAC QopNT8sK+q8Ijo9nRe6PUKwYysL91GnxL2SZ4i0L7FbCOR2CKDaJHuUi/Q1T+Jn/Vpbn xjoYqbN4Zac+QaTT73MzqWCrwfhCIxVjnX/rHd3KJ0NjHOYOtEva54D/UK1tQmR44Voz Ih64Gy/mbkwqKG+sFDP3qTikfgNqlSRVeXEIii9k31D4lohlmevHFxRw16beug/CV173 2fVEGPSUBqoG7Qpr8BIR3YqpPapuTXS9CyE6sRX5FW64i2FQN3a+MUwVXFi9baHmNk8A 1obw== X-Gm-Message-State: AN3rC/5OaumZGwzCj5kXJw0BnzlRcBZWPnrQY1KfEFUaVc0fiDm+Cgs1 oooQeIg0FOfyQ8xPw6HJGzyrLdL5rQ== X-Received: by 10.25.31.14 with SMTP id f14mr12174530lff.43.1493888747344; Thu, 04 May 2017 02:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 4 May 2017 02:05:46 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 19:05:46 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar , Subodh Iyengar , "Lubashev, Igor" , Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:05:51 -0000 On 4 May 2017 at 17:37, Jana Iyengar wrote: > One of the purposes of this change is to enable a server to direct a client > towards a particular server via the connection ID in a Version Negotiation > or a Stateless Retry packet. A server can still do that by generating a > connection ID that it knows will hash to the right server. Basically, load > balancers will use two functions for hashing connection ID -- C() to hash > client-chosen connection IDs and S() for server-chosen ones. On a VN or SR > packet, the server needs to generate and send a connection ID so that > C(connection ID) sends the retrying client to the desired server. This > allows a server to redirect while also allowing the server infrastructure to > not trust that a client is doing the right thing. This convinced me. I'd like to hear from Kazuho, Igor, and Subodh about whether this works for them. I don't see why it wouldn't, but I don't know their infrastructure. From nobody Thu May 4 04:04:33 2017 Return-Path: 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 88C4412EA54 for ; Thu, 4 May 2017 04:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7sHsQUwSCtp6 for ; Thu, 4 May 2017 04:04:20 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E951294F4 for ; Thu, 4 May 2017 04:04:18 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id r17so5732560lfg.0 for ; Thu, 04 May 2017 04:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XdF1VsqR2JUXYJw9Rozu1n1a/4uD6SKc/Zkm5X9BWJI=; b=ZkbQbYKiUBZJvVvgsFAkoFinJTbERkFJXapap0xru2ULpVMByi/xnk2Esc5pElcEGp 3DxhD2L8ucrMvnW7hP+LaPoKG2rbwmciHdkn5s/fQaPOVgAFkdNZnb3tsh5BiNueS+dz 9zzD4gB+8u30uE49EdcPttK9MFsyYm5nAI8gEBuWkooQikUe14jnqDI0/xjbE0OgttfW nR4J9qIzkuL9G2w3aiqIzyCcSVwqU+OJV6iY3M5q+WoSfFTiVRLiiD5reCn64MqEfmaX xmw/a1rtBVg+WDk4UAWh606o9YwOzs8zTPS7LPBdDvNvzGuebTexgH/DgMm/xLLgUaY6 WSUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XdF1VsqR2JUXYJw9Rozu1n1a/4uD6SKc/Zkm5X9BWJI=; b=MBRu4xH0AFa5IqmxzDhEEfYkn0c5POfRcdvRUXcM2qzcHmq78mlcuLbQnTdoCdhyV0 OtJuz0e3cScwtO2jtt1pQK2G9B716pzJ47mAh9nquZ5SgF4dYbxnJIzjftQWpbu4DUC+ sFpEl6uweJShxg+OsS7KbXsQatVD72UihdQc7WbCtzpeDWOktSjg8C450r7yTF7aSFib 9brMyQoy6kbVVdlTwOTyLhUEnETBwMMee6afFgMGjJOVolnNKiExNOw1/iF8hg6i6AOO TubH1/8JrQiEZQLYKZcllrYuPiPP/h/BYvZ1mV6v3vJ/ewuYYrW7FChmioCiMRUVKv1F Kxag== X-Gm-Message-State: AN3rC/4PYa4Yu29tynNcTKfGEcAzQ2oDBNMdHYX8mokz4IJ1b7jZStSu boV7GHU+fkszpBaMr68uiykZ+CDPDw== X-Received: by 10.25.160.147 with SMTP id j141mr12353498lfe.19.1493895856711; Thu, 04 May 2017 04:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 4 May 2017 04:04:16 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 May 2017 21:04:16 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar , Subodh Iyengar , "Lubashev, Igor" , Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 11:04:32 -0000 I have written up the proposed change and updated the PR. https://github.com/quicwg/base-drafts/pull/493 >From my commit message, here's the summary: * Client Initial packets are always a complete reset at the transport layer, always contain a ClientHello, are always padded to the minimum size, and include a randomized packet number unless they are a retransmission. STREAM frames in these packets always start at an offset of 0, even if the cryptographic handshake is continued. All necessary data has to fit into a single packet; it can't span several. The server can propose a new connection ID in response to Client Initial packets (giving the server up to three re-routing options). * Server Stateless Retry packets cause the client to start over, retaining only cryptographic handshake state. The contents of this also can't span two packets. This includes a server-proposed connection ID and an echo of the client packet number. This is because the server can't be expected to remember what it chose when it sends subsequent packets. * Version Negotiation packets also cause a reset. This has the same rules for connection ID and packet number as the Server Stateless Retry. * Client Cleartext and Server Cleartext contain the other handshake messages. These aren't really special in any way. On 4 May 2017 at 19:05, Martin Thomson wrote: > On 4 May 2017 at 17:37, Jana Iyengar wrote: >> One of the purposes of this change is to enable a server to direct a client >> towards a particular server via the connection ID in a Version Negotiation >> or a Stateless Retry packet. A server can still do that by generating a >> connection ID that it knows will hash to the right server. Basically, load >> balancers will use two functions for hashing connection ID -- C() to hash >> client-chosen connection IDs and S() for server-chosen ones. On a VN or SR >> packet, the server needs to generate and send a connection ID so that >> C(connection ID) sends the retrying client to the desired server. This >> allows a server to redirect while also allowing the server infrastructure to >> not trust that a client is doing the right thing. > > This convinced me. I'd like to hear from Kazuho, Igor, and Subodh > about whether this works for them. I don't see why it wouldn't, but I > don't know their infrastructure. From nobody Thu May 4 10:23:31 2017 Return-Path: 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 A916812943C for ; Thu, 4 May 2017 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 SMCX46jIJp6X for ; Thu, 4 May 2017 10:23:28 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A29129471 for ; Thu, 4 May 2017 10:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3wJhgy18Ctz15MPF; Thu, 4 May 2017 19:23:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMaYvbpfGBfH; Thu, 4 May 2017 19:23:25 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 4 May 2017 19:23:25 +0200 (CEST) Subject: Re: Proposed changes to cleartext packets To: Martin Thomson , Jana Iyengar , Subodh Iyengar , "Lubashev, Igor" , Kazuho Oku References: Cc: QUIC WG From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <43411cd3-4b10-7a74-e7f8-6487fd48b8f8@tik.ee.ethz.ch> Date: Thu, 4 May 2017 19:23:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:23:30 -0000 Quick question, and maybe I lost the context here, but On 04.05.2017 13:04, Martin Thomson wrote: > * Client Initial packets are always a complete reset at the transport > layer, always contain a ClientHello, are always padded to the minimum > size, and include a randomized packet number unless they are a > retransmission. how can you do a retransmit if you cleared all transport state? Mirja From nobody Thu May 4 13:49:36 2017 Return-Path: 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 4652F1287A7 for ; Thu, 4 May 2017 13:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cWiOXIS1f49L for ; Thu, 4 May 2017 13:49:34 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FA712702E for ; Thu, 4 May 2017 13:49:33 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id q1so21342422qkd.2 for ; Thu, 04 May 2017 13:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EkizsOCl6BIA+Z7dTkUFA5qWTlvpYayTEUV7Wd7Psoo=; b=AXDBH8172uU9TV/WK/ONkF334PJZ0pyTZ0kopKy2zeaF4YHMseVfGT4A2TNLn+Cotw hHOUjUm1hy0tLYeh/2rGLgR2YTdT+gi8AYo6YvVbnG7XXYhk4ycVGLiY4htPZ9kVabK8 hk1c6nAGlKJ49J5RTJVh9bO4Z8fw1YE6DjXlKmM85NJavH0jV8yc0311xV+Ebkq9bdmP p0WDbGIVn7LLhzV1uglSHWqioSEwPkOli0IzApZBWNCHFEIjLkJSq2bRa1iujan9Vz9+ qgkne7TPnNDkcv0DTnY2VoBFQYzA4kgRFEhEmkdoxV1vkeV/CZMjoJkP0cZfle03NKNH 1q7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EkizsOCl6BIA+Z7dTkUFA5qWTlvpYayTEUV7Wd7Psoo=; b=rH5oA88tJPpDe+YTnak4ajzIZ3UfPhLHSgBa6BAvslA/hYN9fQCKcbKqI2feaP2xUP cGuxnWhom3QlxIsc0c/KLViPIWuZ+iIjl0AHhfh8zE9MhvMJ/jh1PqvyAcGxeWiwdN0r sKD1J4rb6QAu9jPCNT/HovNCHF4P+UorbRHTiBrwLZDkUQE+Trh1wQmiMMYtRQCATMuy Egw5nZ7gqDYJfka8cGJVHUkL11oGctD7ohK93Pj8gjvjSYX6i4ds9UrlVPpe9tbgpVZp /IcmEt3YSUNL5ViPSXfTd+wGBuNcEfKWpM1M8oGM1Cz90aMLFBf4ruHMHw0/ATr+lTAy u5eA== X-Gm-Message-State: AN3rC/4i0UKBqOswWiDGUbmmyrQLYhvFnaBPZEKiv7yoG/Pich5vrwTe CLDSU90lgS1RsJMiIeUakq33FMdPew== X-Received: by 10.233.239.65 with SMTP id d62mr9399022qkg.119.1493930973003; Thu, 04 May 2017 13:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.157 with HTTP; Thu, 4 May 2017 13:49:02 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 4 May 2017 13:49:02 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c033d78f703a3054eb8e8d3 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 20:49:35 -0000 --94eb2c033d78f703a3054eb8e8d3 Content-Type: text/plain; charset=UTF-8 On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar wrote: > (ii) 0-RTT packets MUST contain the same connection ID as in the client's > most recent handshake packet to make it possible for load balancers to work > with them. > I may be misunderstanding something, but I don't see the advantage of using the same connection ID as in the most recent handshake packet over using any of the Connection IDs that a server has provided (presuming that the change that allows a list to be returned for use in connection migration goes forward). Presumably, any of the server supplied will work through load balancers to reach the right server (or the server is implicitly okay with stateless operation). To me, at least, it would make for easier client logic if it always used the next one in the list whether it was migrating a connection because of a known network change or using 0-RTT because of a period where the transport wasn't up. It also might improve privacy, if linking flow state across 0-RTT restarts is a concern. Am I missing a harm in using one of the later connection IDs, if they were supplied? regards, Ted --94eb2c033d78f703a3054eb8e8d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar <jri@google.co= m> wrote:
(ii) 0-RTT packets MU= ST contain the same connection ID as in the client's most recent handsh= ake packet to make it possible for load balancers to work with them.

I may be misunde= rstanding something, but I don't see the advantage of using the same co= nnection ID as in the most recent handshake packet over using any of the Co= nnection IDs that a server has provided (presuming that the change that all= ows a list to be returned for use in connection migration goes forward).=C2= =A0 Presumably, any of the server supplied will work through load balancers= to reach the right server (or the server is implicitly okay with stateless= operation).

To me, at least, it wo= uld make for easier client logic if it always used the next one in the list= whether it was migrating a connection because of a known network change or= using 0-RTT because of a period where the transport wasn't up.=C2=A0 I= t also might improve privacy, if linking flow state across 0-RTT restarts i= s a concern.

Am I missing a harm in= using one of the later connection IDs, if they were supplied?

regards,

Ted

--94eb2c033d78f703a3054eb8e8d3-- From nobody Thu May 4 16:23:07 2017 Return-Path: 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 6965E12025C for ; Thu, 4 May 2017 16:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ohMLC0Vp9wRg for ; Thu, 4 May 2017 16:23:03 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657DE1287A3 for ; Thu, 4 May 2017 16:23:03 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id o3so15926042pgn.2 for ; Thu, 04 May 2017 16:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXBJxGUYi8ZAMWV3/QklAVslvW5IoxT1a4tS/XYuoXk=; b=lLgsKMeVaPv7YsqKPvL6alSg5bBHP1f/qz9/rRfWwSjPiEbszil0jS69b/vptjtTV1 gXewVGMAO4Mmm+AdKikCb+ERQGEa+v5S26OgApJDCeqxa548Ruktn7n53dmCgMAe+2ml Ycnx9GH7cCdRqaFsacS5xCRiT3WE4KXJYrgYF8WbjqdbALuaZNnaSao0CxOnzp18H8IO ZjJHfX9ZRkwPFbr6gwlbHEVpPDlR/CUVIBNCmgL6ZI3mcWqH74LUjxJzGifLsG3evwfw eOtJGJbB61NmiLCVTLYRQ+OVYO7/iUGcuvuH6FKiXoDtdvN/JnloUPCOP8Xsykt4NoRl JnAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXBJxGUYi8ZAMWV3/QklAVslvW5IoxT1a4tS/XYuoXk=; b=uUT4JJcX4iig3qRM/4Xaz2eM+vvzqHBBhMlWlgtSSfNvLzW2YGWfO32smkgXLzj9in xmk3b+2CWQD5DFHZSGiKHEWFIJ4LVhcMLSHnXUsKnBJ24nImAGxzuBNp5gmlPk2gGZEX UCL3Y/1QvF2DyxzTQ3fAG3dwbjErLCUkReq/rkuIWM7qTIT9sWPFXfaSZc/Pzw4K7xUt zl3R8gQIBurUGj6CuPZoI2afXPQHyDJNZcHtTmj+OvkGMAdEmn8GB9Xu7BHWxsHlLTy8 k5YweFIuRaB5u6uuNufzYd1rT90we/j6+qy78Wn1sJ9myQgBHjIlxVlR1eU4HL814O/i Mxtg== X-Gm-Message-State: AN3rC/7dUs70JwMLvMBqMlxo4sf+Jj138oHy3OscxR3dhNVYYgHX5S6I 41t2IH7JTXp4fFLJuAeiuWtEeWVzQGKr X-Received: by 10.99.50.66 with SMTP id y63mr26927623pgy.41.1493940182843; Thu, 04 May 2017 16:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Thu, 4 May 2017 16:23:02 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 4 May 2017 16:23:02 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Ted Hardie Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary=001a114d7d58ea43be054ebb0d71 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 23:23:05 -0000 --001a114d7d58ea43be054ebb0d71 Content-Type: text/plain; charset=UTF-8 After some discussion with Ryan and some thinking, I'm going to end up arguing against my previous self (whee!). I'll also suggest a few modifications. 1. Sending server-proposed connection ID on only Stateless Retry: I don't think a new connection ID on a Version Negotiation (VN) packet is particularly useful. Specifically, the issue that I believe this was expected to solve (Subodh and/or Kazuho should confirm) was if a server does not support the client's requested version but knows of a different server that does, it should be able to redirect the client to the correct server by sending an appropriate connection ID on the VN packet. This cannot work because the VN packet would contain the client's chosen version and would therefore be ignored by the client (as it should be.) A server can send a Stateless Retry (SR) packet with a server-chosen connection ID when shedding load to a different server. If this is the only case that needs supporting, a client's use of the server-chosen ID in a subsequent Client Cleartext packet can be verified by simply adding the server-chosen ID in the cookie that is sent with the Retry packet. 2. Co-ordinating connection ID change mechanisms: This mechanism (and the previous one in the current spec) have both the server and the client changing connection IDs -- the server does it during handshake and the client does it after it receives one or more NEW_CONNECTION_ID frames. I think we can make this simpler (both in protocol and impl) with only the client initiating this change by sending a packet with a server-chosen connection ID first. If the client were the only one initiating the change, this would allow the server to not care about doing any changes mid-connection, and it could simply use the connection ID in the largest received packet as the outgoing one. This implies that the server somehow signals the new connection ID to the client during handshake, which the client MUST use on all 1-RTT encrypted packets (since we are designing for a server-side load balancer, we can allow the server to send 1-RTT encrypted packets with the client-chosen connection IDs to accomodate the 0.5RTT case.) We can achieve this signaling in one of two ways: (ii) The server sends a NEW_CONNECTION_ID frame bundled in the ServerHello packet, but there are corner cases with and without bundling that might make it tricky. Additionally, the NEW_CONNECTION_ID frame sent along with the ServerHello could just be the general one sent for a migration event, and this would be ambiguous signaling. We could fix that by adding a bit next to each connection ID, but then this bit is unused for all but the first connection ID. (i) The server sends a new connection ID as a transport param in the ServerHello, instead of splitting NEW_CONNECTION_ID frame elements into two types. NEW_CONNECTION_ID continues to carry IDs for future use. Explicitly indicating the new connection ID gives the client an explicit correlator, which is better than assuming that the 4-tuple will only carry packets for this connection. Since the server also needs to convey this new connection ID in a Stateless Retry, an SR packet could carry a NEW_CONNECTION_ID frame. This leaves us with two protocol mechanisms for carrying a new connection ID: transport param and NEW_CONNECTION_ID. If we ditch the transport param, then it's two types of connection IDs within a NEW_CONNECTION_ID frame, which seems equivalent. A nice side-effect is that a server that is happy with client-chosen connection IDs simply does not send this param / frame during handshake. If this discussion above makes sense, we would need to: (i) stick with the packet types in the previous version of this patch, and (ii) decide and add a mechanism for conveying connection ID to client on handshake. Thoughts? On Thu, May 4, 2017 at 1:49 PM, Ted Hardie wrote: > On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar wrote: > >> (ii) 0-RTT packets MUST contain the same connection ID as in the client's >> most recent handshake packet to make it possible for load balancers to work >> with them. >> > > I may be misunderstanding something, but I don't see the advantage of > using the same connection ID as in the most recent handshake packet over > using any of the Connection IDs that a server has provided (presuming that > the change that allows a list to be returned for use in connection > migration goes forward). Presumably, any of the server supplied will work > through load balancers to reach the right server (or the server is > implicitly okay with stateless operation). > > To me, at least, it would make for easier client logic if it always used > the next one in the list whether it was migrating a connection because of a > known network change or using 0-RTT because of a period where the transport > wasn't up. It also might improve privacy, if linking flow state across > 0-RTT restarts is a concern. > > Am I missing a harm in using one of the later connection IDs, if they were > supplied? > > regards, > > Ted > > --001a114d7d58ea43be054ebb0d71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After some discussion with Ryan and some thinking, I'm= going to end up arguing against my previous self (whee!). I'll also su= ggest a few modifications.

1. Sending server-proposed co= nnection ID on only Stateless Retry:=C2=A0

I don&#= 39;t think a new connection ID on a Version Negotiation (VN) packet is part= icularly useful. Specifically, the issue that I believe this was expected t= o solve (Subodh and/or Kazuho should confirm) was if a server does not supp= ort the client's requested version but knows of a different server that= does, it should be able to redirect the client to the correct server by se= nding an appropriate connection ID on the VN packet. This cannot work becau= se the VN packet would contain the client's chosen version and would th= erefore be ignored by the client (as it should be.) A server can send a Sta= teless Retry (SR) packet with a server-chosen connection ID when shedding l= oad to a different server. If this is the only case that needs supporting, = a client's use of the server-chosen ID in a subsequent Client Cleartext= packet can be verified by simply adding the server-chosen ID in the cookie= that is sent with the Retry packet.=C2=A0

2. Co-o= rdinating connection ID change mechanisms:=C2=A0

T= his mechanism (and the previous one in the current spec) have both the serv= er and the client changing connection IDs -- the server does it during hand= shake and the client does it after it receives one or more NEW_CONNECTION_I= D frames. I think we can make this simpler (both in protocol and impl) with= only the client initiating this change by sending a packet with a server-c= hosen connection ID first. If the client were the only one initiating the c= hange, this would allow the server to not care about doing any changes mid-= connection, and it could simply use the connection ID in the largest receiv= ed packet as the outgoing one.

This implies that the server somehow = signals the new connection ID to the client during handshake, which the cli= ent MUST use on all 1-RTT encrypted packets (since we are designing for a s= erver-side load balancer, we can allow the server to send 1-RTT encrypted p= ackets with the client-chosen connection IDs to accomodate the 0.5RTT case.= ) We can achieve this signaling in one of two ways:
(ii) The serv= er sends a NEW_CONNECTION_ID frame bundled in the ServerHello packet, but t= here are corner cases with and without bundling that might make it tricky. = Additionally, the NEW_CONNECTION_ID frame sent along with the ServerHello c= ould just be the general one sent for a migration event, and this would be = ambiguous signaling. We could fix that by adding a bit next to each connect= ion ID, but then this bit is unused for all but the first connection ID.
(i) The server sends a new connection ID as a transport = param in the ServerHello, instead of splitting NEW_CONNECTION_ID frame elem= ents into two types. NEW_CONNECTION_ID continues to carry IDs for future us= e.

Explicitly indicating the new connection ID giv= es the client an explicit correlator, which is better than assuming that th= e 4-tuple will only carry packets for this connection. Since the server als= o needs to convey this new connection ID in a Stateless Retry, an SR packet= could carry a NEW_CONNECTION_ID frame.

This leave= s us with two protocol mechanisms for carrying a new connection ID: transpo= rt param and NEW_CONNECTION_ID. If we ditch the transport param, then it= 9;s two types of connection IDs within a NEW_CONNECTION_ID frame, which see= ms equivalent.

A nice side-effect is that a server= that is happy with client-chosen connection IDs simply does not send this = param / frame during handshake.

If this discussion= above makes sense, we would need to:
(i) stick with the packet t= ypes in the previous version of this patch, and
(ii) decide and a= dd a mechanism for conveying connection ID to client on handshake.

Thoughts?

On Thu, May 4, 2017 at 1:49 PM, Ted Hardie <ted.ie= tf@gmail.com> wrote:
On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar <= span dir=3D"ltr"><jr= i@google.com> wrote:
(ii) 0-RTT= packets MUST contain the same connection ID as in the client's most re= cent handshake packet to make it possible for load balancers to work with t= hem.

I may be misunderstanding something, but I don't see the advantage of= using the same connection ID as in the most recent handshake packet over u= sing any of the Connection IDs that a server has provided (presuming that t= he change that allows a list to be returned for use in connection migration= goes forward).=C2=A0 Presumably, any of the server supplied will work thro= ugh load balancers to reach the right server (or the server is implicitly o= kay with stateless operation).

To m= e, at least, it would make for easier client logic if it always used the ne= xt one in the list whether it was migrating a connection because of a known= network change or using 0-RTT because of a period where the transport wasn= 't up.=C2=A0 It also might improve privacy, if linking flow state acros= s 0-RTT restarts is a concern.

Am I= missing a harm in using one of the later connection IDs, if they were supp= lied?

regards,

Ted


--001a114d7d58ea43be054ebb0d71-- From nobody Thu May 4 16:30:25 2017 Return-Path: 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 7A59A126D05 for ; Thu, 4 May 2017 16:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eqAkHNtvHibp for ; Thu, 4 May 2017 16:30:19 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E214A1243F3 for ; Thu, 4 May 2017 16:30:18 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id j1so16395028lfh.2 for ; Thu, 04 May 2017 16:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XKIQqc81VIkh0unouMerbi2sq+PGQ44Ph5kr0KwSB9c=; b=kai2wlEZmowI2oeLamxGUOXNlakvtZRrgQnZc7V3aH/Do6MA1aljcfIgi/dZlvblyk ZpqvvEc96TK1qd9k+L2JccoFuwE3hdi5G1lihXeJv1A3pLRwaoWC51mG/1nqzAk1V5E/ XRZ2Wo31IXxCTbiAgiJJbntI7dys6lieGt6IcU7V0Gci7foj58zGgy209LnVOq1q/BlG 0SwWMBrdxCHgKGip1Xz1mYzKiwb8dK0y6U1PlGZSXWrX3e0SoPRMQMQYmFlqo7tx1uxU gEDS2NVAbo9vYWq1pbN2IPGIl9+SuCcnlk/nfkYRSKKVcSbcggFcoCqEGRVIeDhBDM5l SpBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XKIQqc81VIkh0unouMerbi2sq+PGQ44Ph5kr0KwSB9c=; b=p2q/OVNB0pFYXYL0BrCksjmiBREm/zNSQcQIcqhzt6GwZMbVLpbTFg1tODGqPnFQwa IB1n4eVYubSKBxHJyHiGdakmEnlnudGvF1GUb5gVbxcePtbS66sXMFdJJCOoNtz1ZfnD ROfN2FzL0v99/Xtxq+BngW1PdDnUWDPFa/1OZQYKofIUlOaiLU44IW6Wwc7rJCd41JT4 hWSJE4zJgtyYWWpPgE1rYlMBozO4qw/sSBLaJG8aXA//PJhDYMPKIR+4/h6x0LscvgxD j2wERN2MXWzfYV4ayfWrEN84uq94sL99065hDPW12PHfurtzHPROQOEEUmyD/eJ/fMEN j/7w== X-Gm-Message-State: AN3rC/6EC96LRjJw4lBTRLdpVdLfEwQPBGfAXxK9M/9BG/A60+ByvJNe pDfW4qg86zz6J26EE4q+POvEk+pM6g== X-Received: by 10.25.212.19 with SMTP id l19mr14739136lfg.169.1493940617282; Thu, 04 May 2017 16:30:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 4 May 2017 16:30:16 -0700 (PDT) In-Reply-To: <43411cd3-4b10-7a74-e7f8-6487fd48b8f8@tik.ee.ethz.ch> References: <43411cd3-4b10-7a74-e7f8-6487fd48b8f8@tik.ee.ethz.ch> From: Martin Thomson Date: Fri, 5 May 2017 09:30:16 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Jana Iyengar , Subodh Iyengar , "Lubashev, Igor" , Kazuho Oku , QUIC WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 23:30:20 -0000 On 5 May 2017 at 03:23, Mirja K=C3=BChlewind wrote: > how can you do a retransmit if you cleared all transport state? The idea here is that you reset transport state when you receive Version Negotiation or Server Stateless Retry. When you send the next Client Initial packet, that needs to be retransmitted. (Note that you can't reset absolutely everything. You probably want to keep the RTT estimate and any congestion signals you have managed to eke out.) From nobody Thu May 4 16:41:48 2017 Return-Path: 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 0DEAF127136 for ; Thu, 4 May 2017 16:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 zIMyS9HZwlHn for ; Thu, 4 May 2017 16:41:44 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBDC127077 for ; Thu, 4 May 2017 16:41:44 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e64so14483354pfd.1 for ; Thu, 04 May 2017 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vcZV52h+erV/BDMoy0386Z5aMplXw4S9JX7nJLiMnP0=; b=S41vVM+nCOrAdD/LyniD1Z8IO8mJZTibAOGFlu/PAaodG3beQhO8gw5FoV7XIFwD6z ZuU1mLVw73LKVgeQQETQi86PPgoAUAx4VZEb+QDT+ce/W7pHPEXZi5mUQqo/csoxxTEB dxCNtjsbcFcUVUcEWYfLATZ3E0aZep7Oj1UXIPUoabrRYQdq0uM8LW/G+By6iWHNGJ6U mHV2Ffw9zZWFffcFtDcojLUpwcsOty6N9ikV9QPZg4dW6plchee1NupObq2VzXlSjJiD 5yZ1VkgWIXMYJc5bIR9x9ngOF3Nu0HeKNH1LGI/hNXmqJ+H+3WQ4oJv74pJzn2+ftlZy d1ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vcZV52h+erV/BDMoy0386Z5aMplXw4S9JX7nJLiMnP0=; b=P5pBrU7vHXvbwzEUFWLpouZkaUJcEIzxszLcr05DnfgPNnE3M/H0+etkO0z21+8S0x 2ZuaheA7LHFVwdxMosjH4BbtO/p2S75eT7fZNCTtu0rWkUqWzxoufBJHmlcyNnoJRXma UBvrmUZ6ky+iKrtzFH8wSL6sBVq65tsdFRe3WQgNQq4wbTxpqBTEllbj2wJVYMOAlcbO KXArepMs8poNNLJHzTk+UkbrfRro1zD97o2jqiPd2sr+BZPw45Dj7xlG81uJWdYejqMw rN4dyQRwNmoNlmB4hwsD6KeI3qyesqOMmf2D6JBp7HZqX01RbzK+ZMZY6U1qV4SBmJd7 kdTg== X-Gm-Message-State: AN3rC/7SfkKuzTC6OM7ddFahAVYlcJrD2khwHmBy3TwvKVlSBGf/qFWC dDGORPWG9+Y5YPwytehp3tKZQKuA1jLN X-Received: by 10.84.204.8 with SMTP id a8mr60370302ple.4.1493941303794; Thu, 04 May 2017 16:41:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Thu, 4 May 2017 16:41:43 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 4 May 2017 16:41:43 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Ted Hardie Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c14896cbab2fb054ebb5097 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 23:41:46 -0000 --94eb2c14896cbab2fb054ebb5097 Content-Type: text/plain; charset=UTF-8 On Thu, May 4, 2017 at 1:49 PM, Ted Hardie wrote: > On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar wrote: > >> (ii) 0-RTT packets MUST contain the same connection ID as in the client's >> most recent handshake packet to make it possible for load balancers to work >> with them. >> > > I may be misunderstanding something, but I don't see the advantage of > using the same connection ID as in the most recent handshake packet over > using any of the Connection IDs that a server has provided (presuming that > the change that allows a list to be returned for use in connection > migration goes forward). Presumably, any of the server supplied will work > through load balancers to reach the right server (or the server is > implicitly okay with stateless operation). > > To me, at least, it would make for easier client logic if it always used > the next one in the list whether it was migrating a connection because of a > known network change or using 0-RTT because of a period where the transport > wasn't up. It also might improve privacy, if linking flow state across > 0-RTT restarts is a concern. > > Am I missing a harm in using one of the later connection IDs, if they were > supplied? > This design is only for the transition from a client-chosen to a server-chosen connection ID, and not for subsequent ID changes... does that make sense? The requirement you highlighted accomodates load balancers that use different hashing algorithms on client-chosen vs server-chosen connection IDs. For instance, a load balancer might use simple ECMP hashing of the client-chosen connection IDs and treat server-chosen connection IDs as containing structure or routing information. Changing the connection ID on an externally visible transition allows such load balancers to use the different hashing algorithms correctly on the connection IDs. - jana > regards, > > Ted > > --94eb2c14896cbab2fb054ebb5097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 4, 2017 at 1:49 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:
On Thu, May 4, 2017 at 12:37 AM, Jana Iyengar <jri@google.com>= wrote:
(ii) 0-RTT packets MUST contain the s= ame connection ID as in the client's most recent handshake packet to ma= ke it possible for load balancers to work with them.
=

I may be misunderstanding= something, but I don't see the advantage of using the same connection = ID as in the most recent handshake packet over using any of the Connection = IDs that a server has provided (presuming that the change that allows a lis= t to be returned for use in connection migration goes forward).=C2=A0 Presu= mably, any of the server supplied will work through load balancers to reach= the right server (or the server is implicitly okay with stateless operatio= n).

To me, at least, it would make = for easier client logic if it always used the next one in the list whether = it was migrating a connection because of a known network change or using 0-= RTT because of a period where the transport wasn't up.=C2=A0 It also mi= ght improve privacy, if linking flow state across 0-RTT restarts is a conce= rn.

Am I missing a harm in using on= e of the later connection IDs, if they were supplied?

This design is only for the transition from a cl= ient-chosen to a server-chosen connection ID, and not for subsequent ID cha= nges... does that make sense? The requirement you highlighted accomodates l= oad balancers that use different hashing algorithms on client-chosen vs ser= ver-chosen connection IDs. For instance, a load balancer might use simple E= CMP hashing of the client-chosen connection IDs and treat server-chosen con= nection IDs as containing structure or routing information. Changing the co= nnection ID on an externally visible transition allows such load balancers = to use the different hashing algorithms correctly on the connection IDs.=C2= =A0

- jana

=C2=A0
regards,

Ted


--94eb2c14896cbab2fb054ebb5097-- From nobody Thu May 4 17:09:25 2017 Return-Path: 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 3EE4212778E for ; Thu, 4 May 2017 17:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZZ_NaLHbSNTk for ; Thu, 4 May 2017 17:09:22 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EAA126D46 for ; Thu, 4 May 2017 17:09:22 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h4so16702027lfj.3 for ; Thu, 04 May 2017 17:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XrlwFwSCGc+yALZmUSKbS3phbjttQudpbNf0YOuzMXs=; b=Q5mEM+wkxEuhismNDUKdhaivOvZAvyvmkE0zg2gfa6JlFIqwtVzw2+mnHioOoqeW6z 3pKVphkI85iwHcf2lojr1/xB/WgYmD86wNeDYqukBOuojAqInpD9SyI/AYnVVTb0LN63 6ZNdzsdBSIND1ACpApslmUuqA6Pu/yX0h2hpFyeYtuFQcAGoF05z0OY64JBF4ay/SOeA Z+Rwe5hC4ffNtZShlwYU5BeQ0NDeI2LR7A2v7eGn08pV9CgTQO6aWjkGF9wKXAnzb/UE 93FRehUKU3RjkvpMMu04GQTKGbyKDLqSxKpwPDMIie13zoAch5dhWVYPTn1a3aCXnk33 xTtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XrlwFwSCGc+yALZmUSKbS3phbjttQudpbNf0YOuzMXs=; b=WD6YNeyqJIJ4PCL7bzMO2uzWttg9I19fg0CggIemRBRyfGsxvLJtUf7hR1qfVVxz3b 41r9RTeoRcWcZ9GN4QjcYomw8kVYYeS5BX0O3r6FGlB1qsgXQTyfRs2yPZzfwPrjnbor 35LlzK866Qc73i62cz3vjyES1brR+fkvGxVVEWpagvK/sUTdOLeKMhSHdPKrC9AQuFGO +4A34iatiprxJyAzG1EbWy2u0FxV4HMyLLU08mKoaqoH/aT6YrjjKd7iKnZmed3dENU/ QKQn6XZPysMolToDToTSnHDqSKdb0d32Y2qR8RKvGpM7TYjebeN3aWFuYjvNkYnwGJLQ N6uQ== X-Gm-Message-State: AN3rC/64QCCzK86Fs4VAGm4zVoT8Bdm1IC7ZU5ix45FauM2V2I1qVpjX 82EiTnsiNp8FxSamp1yY7Q73brM9Sg== X-Received: by 10.25.158.147 with SMTP id h141mr16099117lfe.130.1493942960367; Thu, 04 May 2017 17:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 4 May 2017 17:09:19 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 5 May 2017 10:09:19 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 00:09:24 -0000 I don't think that either suggestion works particularly well. I'll explain below. On 5 May 2017 at 09:23, Jana Iyengar wrote: > I don't think a new connection ID on a Version Negotiation (VN) packet is > particularly useful. Specifically, the issue that I believe this was > expected to solve (Subodh and/or Kazuho should confirm) was if a server does > not support the client's requested version but knows of a different server > that does, it should be able to redirect the client to the correct server by > sending an appropriate connection ID on the VN packet. I believe that this was one of the cases that was identified. And you are correct that a stateless reject is the only way to do what was intended here. Either the version negotiation packet includes the client's chosen version and is ignored, or it doesn't match the version that the other server will ultimately advertise. BTW, I've opened an issue for documenting how a server cluster might be upgraded (and rolled back): https://github.com/quicwg/base-drafts/issues/504 The use case you are missing is one where the server receives an unsupported version AND it wants to send the client to another server. One reason you might want to do that is to avoid a second round trip. I'll concede that is a little unlikely given the potential need for address validation, so it's a pretty minor gain, but a gain nonetheless. Can you demonstrate something that we would lose by allowing the server to propose a connection ID here? The gain might be small, but I'm not seeing any downside to allowing it. > This mechanism (and the previous one in the current spec) have both the > server and the client changing connection IDs -- the server does it during > handshake and the client does it after it receives one or more > NEW_CONNECTION_ID frames. I think we can make this simpler (both in protocol > and impl) with only the client initiating this change by sending a packet > with a server-chosen connection ID first. Let me try to restate your proposal. You would have the entire handshake complete with the same connection ID, then switch to a different connection ID once the handshake completes. A stateless reject would be allowed to cause re-routing. I'm not sure that I understand the advantages that this design has. You claim that it reduces the number of mechanisms to two, but I think that you end up with three because you need to use a transport parameter. (FWIW, the current writeup essentially only has two mechanisms: NEW_CONNECTION_ID and server handshake packets, though I'll concede that there might be three of those). It has essentially the same properties as what I've written up, but it's more complicated in several ways. The NEW_CONNECTION_ID frame implies a packet number gap. With client authentication, the server might receive encrypted packets before the handshake completes. If we take ekr's pull request for NEW_CONNECTION_ID, the server can't know what the gap is without receiving the handshake packets. This would create more exceptions for what can be sent in the clear, which requires more care. If, as proposed, we allow multiple new connection IDs to be sent in the same frame, we wouldn't want that to happen here, so that's another new special case to test. That suggests a transport parameter might be a better design, but we don't send transport parameters in the HelloRetryRequest. We'd lose confidentiality for those unless we created a new set of rules for what transport parameters can be sent in a HelloRetryRequest. That generates more special rules. I think that you raise an important point here: > Changing the connection ID on an externally visible transition allows such load balancers to use the different hashing algorithms correctly on the connection IDs. The current proposal has equally simple rules: if packet[0] == 0x82 or packet[0] == 0x86: routing = client_selected else: routing = server_selected That is, Client Initial and 0-RTT get routing as though the client chose the ID. You would instead have us switch the test to packet[0] & 0x80 == 0x80 and packet[0] != 0x87 and packet[0] != 0x88, that is every long form packet except the 1-RTT ones. I don't see any advantage there. From nobody Thu May 4 20:17:03 2017 Return-Path: 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 D6248127369 for ; Thu, 4 May 2017 20:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wtai_bKMXSmR for ; Thu, 4 May 2017 20:17:01 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C5B127599 for ; Thu, 4 May 2017 20:17:00 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id f102so47129940ioi.2 for ; Thu, 04 May 2017 20:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XnXbBI8trlEmtxiwBvj099bukwglldJr/9CEFqYJ34M=; b=a6C+TWMuNtHCqaO4a0BF6eubJHGL34atPs7HjUvWxhdyiulP5K2I9dR5fLdyBXOwWc +Y//tA0AheYrxDbhZ4Ccm60rRIOPicVPIDdGqwl5zK5FmV/uBpulINucGEbz+PbV1s+U 7buT+aCAgyX6D+A3i5vcgyaanDNL73Syk5l+DE4iewWbbSI4gbkAJK5XAwt9uGdTC+Ok dhJvi1ibXL1vJ/GrtxMkvX8urBJjzdIKUd5Or2PYlzP03TyBiegBMC5XmOOOS11Dfscl kGuMWrg7F5+1IxC8DE+7NE3TPWHiEn8QzxHG1cZphu8r4q6a7Uqxqwe1oQEdO+rpwH/H Uh6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XnXbBI8trlEmtxiwBvj099bukwglldJr/9CEFqYJ34M=; b=WX3Xwb7vZjwkFXqH9s0q0aWPWZPqiHfq3yEsMk22C3PJ45CWev1yOnRTsmq94V2VAn oNnu4X1kuecz4gzm+GtQ3lan4OEpSAumStct1+EFiwo3QYL/yp3XJtfRqC2bWQISmptZ gxBf9V0ew0dT11UihGm5YGI6Wp4Sfy4Wd9o3E/S2TBU99OR5GcBsmpLd2/JLktJiFlE5 sV9pZzIeHY8BopgKzmkGXw3wQ6YOjyAeELwOrO3UKYdD7FKbJrzpjv5x6FMIEDZqsXLK 1crjN/c575eNz9EfAaC4MDKr9cEkLzx5vo/4r2Ri18GGke+f7SH5mQswPien07IBZIDv Fe8Q== X-Gm-Message-State: AN3rC/4oT/CB58H/Aw1wR+ZFGG0pZKBqRHW6DItkf817P5/UyKS4n2N/ dGHeI327ra8JkXN3X3v8ttCTInTyng== X-Received: by 10.157.80.162 with SMTP id b34mr14942394oth.172.1493954219411; Thu, 04 May 2017 20:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.35.196 with HTTP; Thu, 4 May 2017 20:16:58 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Duke Date: Thu, 4 May 2017 20:16:58 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Eric Rescorla Cc: Martin Thomson , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary=f4030435b5308f0e60054ebe5280 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 03:17:03 -0000 --f4030435b5308f0e60054ebe5280 Content-Type: text/plain; charset=UTF-8 I've finally been able to process this thread. This problem has so many dimensions that we should definitely discuss in Paris. TL;DR I think signals to middleboxes are important, and I endorse MT's mechanism but with the proof sent in the clear. I have concerns about how this might work without connection IDs or with a changing connection ID, if some of the MAYs and SHOULDs aren't observed, client-generated public resets, etc. Once we agree on general approach we can interrogate those issues. In my opinion, the logic of this signal extends to also doing #353 and replacing CONNECTION_CLOSE with a public reset. ************* There are numerous different tradeoffs we discuss above, but reasoning from first principles about middleboxes may answer all of these questions. I propose the following assertions: 1. Middleboxes will do stuff to connections that requires state. 2. There will have to be some sort of idle timeout to clean up that state, because stuff happens. 3. It is desirable to QUIC endpoints that those timeouts be as long as possible. Premature state teardown will, at the very least, mess up whatever the middlebox is trying to optimize, and at worst it will break the connection (e.g. a firewall may not accept packets if it hasn't seen the Client Hello.) 4. Middlebox vendors and operators will institute longer timeouts if they have a *reasonable chance* of being gracefully notified of connection close. 5. On-path observers should not be able to generate (spoof) valid public resets to middleboxes. >From these points, we should strive to maximize the likelihood of the middlebox seeing and validating the public reset, but it's OK if it misses it in certain corner cases. I propose that MT's mechanism, with the proof sent in the clear and extended to events where Google-QUIC sends CONNECTION_CLOSE, meets this test. It's true that path changes and path failure will prevent delivery of this signal. But this is not terribly different from the balance of events that we see with TCP. As for an explicit "path close, connection still open" message, I wouldn't object to this but I don't see it as necessary, nor do I think it likely that endpoints would bother to send them. Martin Duke On Wed, May 3, 2017 at 3:47 PM, Eric Rescorla wrote: > Yes, I meant the server. > > -Ekr > > > On Wed, May 3, 2017 at 3:45 PM, Martin Thomson > wrote: > >> On 4 May 2017 at 07:59, Eric Rescorla wrote: >> > On Wed, May 3, 2017 at 2:56 PM, Martin Thomson < >> martin.thomson@gmail.com> >> > wrote: >> >> >> >> On 4 May 2017 at 00:40, Eric Rescorla wrote: >> >> > In EncryptedExtensions, the client sends V = HKDF(K, ). >> >> >> >> I think that Christian's idea works well enough. This one requires an >> >> impossibility :) >> > >> > >> > Why is this an impossibility? >> >> The client doesn't send EncryptedExtensions. Maybe you meant exactly >> what Christian said and the V is sent by the server? >> > > --f4030435b5308f0e60054ebe5280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've finally been able to process this thread. Th= is problem has so many dimensions that we should definitely discuss in Pari= s.

TL;DR I think signals to middleboxes are import= ant, and I endorse MT's mechanism but with the proof sent in=C2=A0the c= lear. I have concerns about how this might work without connection IDs or w= ith a changing connection ID, if some of the MAYs and SHOULDs aren't ob= served, client-generated public resets, etc. Once we agree on general appro= ach we can interrogate those issues.

In my opinion= , the logic of this signal extends to also doing #353 and replacing CONNECT= ION_CLOSE with a public reset.

*************
=

There are numerous different tradeoffs we discuss above= , but reasoning from first principles about middleboxes may answer all of t= hese questions. I propose the following assertions:

1. Middleboxes will do stuff to connections that requires state.

2.=C2=A0There will have to be some sort of idle timeout to= clean up that state, because stuff happens.

3. It= is desirable to QUIC endpoints that those timeouts be as long as possible.= Premature state teardown=C2=A0will, at the very least, mess up whatever th= e middlebox is trying to optimize, and at worst it will break the connectio= n (e.g. a firewall may not accept packets if it hasn't seen the Client = Hello.)

4. Middlebox vendors and operators will in= stitute longer timeouts if they have a *reasonable chance* of being gracefu= lly notified of connection close.

5. On-path obser= vers should not be able to generate (spoof) valid public resets to middlebo= xes.

From these points, we should strive to maximi= ze the likelihood of the middlebox=C2=A0seeing and=C2=A0validating the publ= ic reset, but it's OK if it misses it in certain corner cases. I propos= e that MT's mechanism, with the proof sent in the clear and extended to= events where Google-QUIC sends CONNECTION_CLOSE, meets this test. It's= true that path changes and path failure will=C2=A0prevent delivery of this= signal. But this is not terribly different from the balance of events that= we see with TCP.

As for an explicit "path cl= ose, connection still open" message, I wouldn't object to this but= I don't see it as necessary, nor do I think it likely that endpoints w= ould bother to send them.

Martin Duke
<= div class=3D"gmail_extra">
On Wed, May 3, 201= 7 at 3:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Yes, I meant the server.

=
-Ekr


On Wed, May 3, 2= 017 at 3:45 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 4 May 2017 at 07:59,= Eric Rescorla <ekr@rt= fm.com> wrote:
> On Wed, May 3, 2017 at 2:56 PM, Martin Thomson <martin.thomson@gmail.com>=
> wrote:
>>
>> On 4 May 2017 at 00:40, Eric Rescorla <ekr@rtfm.com> wrote:
>> > In EncryptedExtensions, the client sends V =3D HKDF(K, <co= nn-id>).
>>
>> I think that Christian's idea works well enough.=C2=A0 This on= e requires an
>> impossibility :)
>
>
> Why is this an impossibility?

The client doesn't send EncryptedExtensions.=C2=A0 Maybe you mea= nt exactly
what Christian said and the V is sent by the server?


--f4030435b5308f0e60054ebe5280-- From nobody Fri May 5 10:53:56 2017 Return-Path: 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 3A98C1286CA for ; Fri, 5 May 2017 10:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IK_JyQEYuJyH for ; Fri, 5 May 2017 10:53:52 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098D9129B09 for ; Fri, 5 May 2017 10:53:52 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id p24so17573011ioi.0 for ; Fri, 05 May 2017 10:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BMWJwZlXyY7haILYSi/Q0OIRvnJFiEIP8GDs2UwO+kY=; b=Am/oniHwHOKuJDcYN7nxiHCxWlogbQ2X7s8vPLhTQPKyGq0FRdeyfKCZA7xe5gxMQH 8Qos3xkTE1eS92axma5zOum1RGGwUcKTaJVObrD3monXa42mkMG3xStrdGaT+FS2bbU5 zgBpRnyHYSGhRb4uoOEmbzi7UC2NF0RaLj6f0zSE1PRIKI67fvSKWG967RTrsJXLE/Le TMrizkkcDw4jCFvzxhPVhUqzTIAxoj3gOCqUEuACdba8crb5Of/6lPjWCYURqSki6g18 YTnOPQjTU3vR5/1dVz4XdN5xNRgrutfrdIJ6YHtlNH9DAYCMpwn6zzEYa/JhvOXiowrg LAHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BMWJwZlXyY7haILYSi/Q0OIRvnJFiEIP8GDs2UwO+kY=; b=flGiXp1AbuDFbZTTvYcalg6Ppm4Xpv4rc5kxCCykroDP6PuS1Y/LFGP1DLkXmhL/Xz Kg1fq6qg4fSV96Su3dHkMcbRduNXJzKHQUyPLl4zUd18/K7KWBw3WXsh9qVPE1g+Y5h5 1MrSq3/dBNGL9pMExs8t4kVecnyGeaBNKurqvTymKH7mZd0CAFLSAOUSlLIvxRT4sFOY Iwdt4cX0LKyGHoQYFgXKpgYgPRvlw6vtT1vn+t+I8nnQeNu7OhwCn5O4Y+YFjG4OUQu9 QFycpXT3Oc85f1zAf0bnfjESu2Fc+7MRd2fAHbiYnMYdcJBrFn1YAMNIF3G2ULAYSvmz 4EdQ== X-Gm-Message-State: AN3rC/53e/75Vo/Opc7PQ6nS2ICbcKVc54nBVyasldMcoPEUi/wC+bgG 7NR5S4OAK6msl9CS+C55r/WYY2T5sw== X-Received: by 10.157.49.68 with SMTP id v4mr13189126otd.131.1494006831330; Fri, 05 May 2017 10:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.35.196 with HTTP; Fri, 5 May 2017 10:53:50 -0700 (PDT) In-Reply-To: References: <4228d9b3-2b37-e007-221a-e76ba4529ea3@huitema.net> <758fd6da-0f7e-a941-dfb5-590020484ce6@huitema.net> From: Martin Duke Date: Fri, 5 May 2017 10:53:50 -0700 Message-ID: Subject: Re: Updated Public Reset authentication patch To: Eric Rescorla Cc: Martin Thomson , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary=001a113d164e793c66054eca92e2 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:53:54 -0000 --001a113d164e793c66054eca92e2 Content-Type: text/plain; charset=UTF-8 Reading through again, I think what I'm actually arguing for is ekr's PR #20 instead, since a verifier in the clear is the key distinction between the two as far as I can tell. On Thu, May 4, 2017 at 8:16 PM, Martin Duke wrote: > I've finally been able to process this thread. This problem has so many > dimensions that we should definitely discuss in Paris. > > TL;DR I think signals to middleboxes are important, and I endorse MT's > mechanism but with the proof sent in the clear. I have concerns about how > this might work without connection IDs or with a changing connection ID, if > some of the MAYs and SHOULDs aren't observed, client-generated public > resets, etc. Once we agree on general approach we can interrogate those > issues. > > In my opinion, the logic of this signal extends to also doing #353 and > replacing CONNECTION_CLOSE with a public reset. > > ************* > > There are numerous different tradeoffs we discuss above, but reasoning > from first principles about middleboxes may answer all of these questions. > I propose the following assertions: > > 1. Middleboxes will do stuff to connections that requires state. > > 2. There will have to be some sort of idle timeout to clean up that state, > because stuff happens. > > 3. It is desirable to QUIC endpoints that those timeouts be as long as > possible. Premature state teardown will, at the very least, mess up > whatever the middlebox is trying to optimize, and at worst it will break > the connection (e.g. a firewall may not accept packets if it hasn't seen > the Client Hello.) > > 4. Middlebox vendors and operators will institute longer timeouts if they > have a *reasonable chance* of being gracefully notified of connection close. > > 5. On-path observers should not be able to generate (spoof) valid public > resets to middleboxes. > > From these points, we should strive to maximize the likelihood of the > middlebox seeing and validating the public reset, but it's OK if it misses > it in certain corner cases. I propose that MT's mechanism, with the proof > sent in the clear and extended to events where Google-QUIC sends > CONNECTION_CLOSE, meets this test. It's true that path changes and path > failure will prevent delivery of this signal. But this is not terribly > different from the balance of events that we see with TCP. > > As for an explicit "path close, connection still open" message, I wouldn't > object to this but I don't see it as necessary, nor do I think it likely > that endpoints would bother to send them. > > Martin Duke > > On Wed, May 3, 2017 at 3:47 PM, Eric Rescorla wrote: > >> Yes, I meant the server. >> >> -Ekr >> >> >> On Wed, May 3, 2017 at 3:45 PM, Martin Thomson >> wrote: >> >>> On 4 May 2017 at 07:59, Eric Rescorla wrote: >>> > On Wed, May 3, 2017 at 2:56 PM, Martin Thomson < >>> martin.thomson@gmail.com> >>> > wrote: >>> >> >>> >> On 4 May 2017 at 00:40, Eric Rescorla wrote: >>> >> > In EncryptedExtensions, the client sends V = HKDF(K, ). >>> >> >>> >> I think that Christian's idea works well enough. This one requires an >>> >> impossibility :) >>> > >>> > >>> > Why is this an impossibility? >>> >>> The client doesn't send EncryptedExtensions. Maybe you meant exactly >>> what Christian said and the V is sent by the server? >>> >> >> > --001a113d164e793c66054eca92e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reading through again, I think what I'm actually argui= ng for is ekr's PR #20 instead, since a verifier in the clear is the ke= y distinction between the two as far as I can tell.

On Thu, May 4, 2017 at 8:16 PM, Mar= tin Duke <martin.h.duke@gmail.com> wrote:
I've finally been able to p= rocess this thread. This problem has so many dimensions that we should defi= nitely discuss in Paris.

TL;DR I think signals to = middleboxes are important, and I endorse MT's mechanism but with the pr= oof sent in=C2=A0the clear. I have concerns about how this might work witho= ut connection IDs or with a changing connection ID, if some of the MAYs and= SHOULDs aren't observed, client-generated public resets, etc. Once we = agree on general approach we can interrogate those issues.

In my opinion, the logic of this signal extends to also doing #353= and replacing CONNECTION_CLOSE with a public reset.

*************

There are numerous different trad= eoffs we discuss above, but reasoning from first principles about middlebox= es may answer all of these questions. I propose the following assertions:

1. Middleboxes will do stuff to connections that re= quires state.

2.=C2=A0There will have to be some s= ort of idle timeout to clean up that state, because stuff happens.

3. It is desirable to QUIC endpoints that those timeouts b= e as long as possible. Premature state teardown=C2=A0will, at the very leas= t, mess up whatever the middlebox is trying to optimize, and at worst it wi= ll break the connection (e.g. a firewall may not accept packets if it hasn&= #39;t seen the Client Hello.)

4. Middlebox vendors= and operators will institute longer timeouts if they have a *reasonable ch= ance* of being gracefully notified of connection close.

5. On-path observers should not be able to generate (spoof) valid pub= lic resets to middleboxes.

From these points, we s= hould strive to maximize the likelihood of the middlebox=C2=A0seeing and=C2= =A0validating the public reset, but it's OK if it misses it in certain = corner cases. I propose that MT's mechanism, with the proof sent in the= clear and extended to events where Google-QUIC sends CONNECTION_CLOSE, mee= ts this test. It's true that path changes and path failure will=C2=A0pr= event delivery of this signal. But this is not terribly different from the = balance of events that we see with TCP.

As for an = explicit "path close, connection still open" message, I wouldn= 9;t object to this but I don't see it as necessary, nor do I think it l= ikely that endpoints would bother to send them.

Martin Duke
<= br>
On Wed, May 3, 2017 at 3:47 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:
Yes, I meant the server.

-Ekr


O= n Wed, May 3, 2017 at 3:45 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 4 May= 2017 at 07:59, Eric Rescorla <ekr@rtfm.com> wrote:
> On Wed, May 3, 2017 at 2:56 PM, Martin Thomson <martin.thomson@gmail.com>=
> wrote:
>>
>> On 4 May 2017 at 00:40, Eric Rescorla <ekr@rtfm.com> wrote:
>> > In EncryptedExtensions, the client sends V =3D HKDF(K, <co= nn-id>).
>>
>> I think that Christian's idea works well enough.=C2=A0 This on= e requires an
>> impossibility :)
>
>
> Why is this an impossibility?

The client doesn't send EncryptedExtensions.=C2=A0 Maybe you mea= nt exactly
what Christian said and the V is sent by the server?



--001a113d164e793c66054eca92e2-- From nobody Fri May 5 18:07:03 2017 Return-Path: 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 826E9126D46 for ; Fri, 5 May 2017 18:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 RJ6U7pumrQBQ for ; Fri, 5 May 2017 18:07:00 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFDB12704B for ; Fri, 5 May 2017 18:07:00 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 12so10180597pgc.1 for ; Fri, 05 May 2017 18:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6FWgZ3DXpbaK8qtBAoYx6JzZjspz8Tv4qyuMMphQ0BI=; b=mn1B3oh2cexgJPAIK3RG1GyIjVQ/xmDef+hBSXA3Kd7yhxyO4Q6UK1qBWVv14vwEX5 86XenXomEiFSfgGdaumNQp9NSlHAX4itQysv/VOaLICkpK3n+a6JL4lOfe/gg97d5gIL XOBDkUU/ZkMavUAYYk0hWXCNqmMhfmE0KpEEmC0mTr9vabpgjMx7c8iaDVoR/BQD2FyY 5l1sXQJkypQ8lKQLmxJx8fFtbFWP/HM9Kzqmech96poe9jT9loTQj6hIKO6p4P8fNWFF J2yafuIClIPCPMwu7mbCw1P4mY8dxFHOlnKHfWRqxhp2LAd4bOQwji81VXChee2xdKHp MTOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6FWgZ3DXpbaK8qtBAoYx6JzZjspz8Tv4qyuMMphQ0BI=; b=BplmyGCxk595MEBTv1jGl9tRTjBF9MsjQdP4covbpBdW0XG5bfTddLu7IOhh9CKz9u w8X5XnjUei4bF+g9rXNSH9o33M1uZT6xbXYNECjqwb/UcYKrTmNpgv+o9wIV+jsMdT1/ GmAzBhLJE4leJ32lAjm9UkACog/MXeaFuAiLy4D59F0XWRmRKxDITqlDRQxwKMCqSSZO Gny03BA6r6qeYw8WapsgXvtin7a3pQcB51OFTarDLUxq/C5rDSOeBdGKA6UvqH7iyM2F PsH3rqs2fZiv+qhZUS7k6aIvZElmKlgec78Dot3pyoDFuSlfqvrvahxmhGoGCUyBSK+O 4cZA== X-Gm-Message-State: AN3rC/6wUw0in9CFVI3RDKJs7fSbVVXmsDuMfcbOP3Ib1H+h8jNU46Fz yBJM1fWyOjigaAKHOx24tvR3PhWw5k/945dhJw== X-Received: by 10.84.217.203 with SMTP id d11mr14468865plj.141.1494032819842; Fri, 05 May 2017 18:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Fri, 5 May 2017 18:06:58 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 5 May 2017 18:06:58 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , QUIC WG Content-Type: multipart/alternative; boundary=f403045ccd5e82aeff054ed09ffb Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 01:07:02 -0000 --f403045ccd5e82aeff054ed09ffb Content-Type: text/plain; charset=UTF-8 On Thu, May 4, 2017 at 5:09 PM, Martin Thomson wrote: > I don't think that either suggestion works particularly well. I'll > explain below. > > On 5 May 2017 at 09:23, Jana Iyengar wrote: > > I don't think a new connection ID on a Version Negotiation (VN) packet is > > particularly useful. Specifically, the issue that I believe this was > > expected to solve (Subodh and/or Kazuho should confirm) was if a server > does > > not support the client's requested version but knows of a different > server > > that does, it should be able to redirect the client to the correct > server by > > sending an appropriate connection ID on the VN packet. > > I believe that this was one of the cases that was identified. And you > are correct that a stateless reject is the only way to do what was > intended here. Either the version negotiation packet includes the > client's chosen version and is ignored, or it doesn't match the > version that the other server will ultimately advertise. BTW, I've > opened an issue for documenting how a server cluster might be upgraded > (and rolled back): https://github.com/quicwg/base-drafts/issues/504 > > The use case you are missing is one where the server receives an > unsupported version AND it wants to send the client to another server. > One reason you might want to do that is to avoid a second round trip. > I'll concede that is a little unlikely given the potential need for > address validation, so it's a pretty minor gain, but a gain > nonetheless. > So an example would be: Client sends CHLO in QUICv2 Server only speaks QUICv1, and wants to shed load to another that speaks QUICv1 Server sends VN with Connection ID that leads client to other server on retry This will be a super rare case: VN itself should be rare to begin with, given Alt-Svc. Within that probability, this is a server that wants to shed load and knows which server to shed to. And for those connections, we're saving 1 RTT. This one RTT will be amortized if there are subsequent connections, since subsequent connections should learn about the new version and not incur the VN delay. This optimization is super unlikely to affect performance for applications or for servers. Can you demonstrate something that we would lose by allowing the > server to propose a connection ID here? The gain might be small, but > I'm not seeing any downside to allowing it. I don't think we should add complexity to optimize an RTT for super rare cases. If we could do it for no cost, that's fine. But I don't think it makes sense to consider a design that gets limited because of this rare case. The fewer places that we have code doing the same or similar things, the better, so if there's a mechanism that works well for the rest of the cases and VN fits in seamlessly, then sure, let's do it. > This mechanism (and the previous one in the current spec) have both the > > server and the client changing connection IDs -- the server does it > during > > handshake and the client does it after it receives one or more > > NEW_CONNECTION_ID frames. I think we can make this simpler (both in > protocol > > and impl) with only the client initiating this change by sending a packet > > with a server-chosen connection ID first. > > Let me try to restate your proposal. > > You would have the entire handshake complete with the same connection > ID, then switch to a different connection ID once the handshake > completes. A stateless reject would be allowed to cause re-routing > Yes, that's correct. > I'm not sure that I understand the advantages that this design has. > You claim that it reduces the number of mechanisms to two, but I think > that you end up with three because you need to use a transport > parameter. (FWIW, the current writeup essentially only has two > mechanisms: NEW_CONNECTION_ID and server handshake packets, though > I'll concede that there might be three of those). It has essentially > the same properties as what I've written up, but it's more complicated > in several ways. The NEW_CONNECTION_ID frame implies a packet number gap. With client > authentication, the server might receive encrypted packets before the > handshake completes. If we take ekr's pull request for > NEW_CONNECTION_ID, the server can't know what the gap is without > receiving the handshake packets. That's a single bit of information we can add to the frame. This would create more exceptions for what can be sent in the clear, > which requires more care. If, as proposed, we allow multiple new > connection IDs to be sent in the same frame, we wouldn't want that to > happen here, so that's another new special case to test. > So you'd send a transport param in the Server Hello (not in the clear) or a frame. If you're sending the frame in response to an SR, it will not contain any information that you need to be confidential. If you're sending the frame after the ServerHello, it will be encrypted with 1-RTT keys. I don't think you need special rules here. > That suggests a transport parameter might be a better design, but we > don't send transport parameters in the HelloRetryRequest. We'd lose > confidentiality for those unless we created a new set of rules for > what transport parameters can be sent in a HelloRetryRequest. That > generates more special rules. > You'd use a frame. Since HRR is a STREAM frame, and should be a small one, bundling a NEW_CONNECTION_ID frame with it should be relatively easy (in code.) > I think that you raise an important point here: > > > Changing the connection ID on an externally visible transition allows > such load balancers to use the different hashing algorithms correctly on > the connection IDs. > > The current proposal has equally simple rules: > > if packet[0] == 0x82 or packet[0] == 0x86: > routing = client_selected > else: > routing = server_selected > > That is, Client Initial and 0-RTT get routing as though the client chose > the ID. You would instead have us switch the test to packet[0] & 0x80 == 0x80 > and packet[0] != 0x87 and packet[0] != 0x88, that is every long form > packet except the 1-RTT ones. I don't see any advantage there. > That's not right. Your logical expression reduces to: if packet[0] != 0x87 and packet[0] != 0x88: routing = client_selected else: routing = server_selected ... which is the same complexity, but it isn't the correct filter anyways. There's a related problem that I realized with this most recent scheme: Connection ID in 0-RTT packets are ambiguous. If they follow a Client Initial, they're client-chosen, but if they follow a Client Cleartext, they're server-chosen. I think this is a problem in your earlier version too. So that's a bummer. You say you see no advantages. I wrote out the advantages in my previous email, but perhaps you didn't see them? 1. Explicitly indicating the new connection ID gives the client an explicit correlator from the client's ID to the new server one, which is better than assuming that the 4-tuple will only carry packets for this connection. Currently, the client will receive the first server packet with an unknown Connection ID and the only correlator is the fact that it was received on the same 4-tuple that the Client Initial was sent on. If you have multiple connections on the same 4-tuple, there's no explicit correlator. 2. This mechanism (and the previous one in the current spec) have both the server and the client changing connection IDs -- the server does it during handshake and the client does it after it receives one or more NEW_CONNECTION_ID frames. I think we can make this simpler (both in protocol and impl) with only the client initiating this change by sending a packet with a server-chosen connection ID first. If the client were the only one initiating the change, this would allow the server to not care about doing any changes mid-connection, and it could simply use the connection ID in the largest received packet as the outgoing one. These are still valuable if we can have them. I'll think about this and get back on Monday. I think the current mechanism in the PR is sound; I'd like to see if we can address the two issues I mention above. --f403045ccd5e82aeff054ed09ffb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 4, 2017 at 5:09 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:

On 5 May 2017 at 09:23, Jana Iyengar <= jri@google.com> wrote:
> I don't think a new connection ID on a Version Negotiation (VN) pa= cket is
> particularly useful. Specifically, the issue that I believe this was > expected to solve (Subodh and/or Kazuho should confirm) was if a serve= r does
> not support the client's requested version but knows of a differen= t server
> that does, it should be able to redirect the client to the correct ser= ver by
> sending an appropriate connection ID on the VN packet.

I believe that this was one of the cases that was identified.=C2=A0 = And you
are correct that a stateless reject is the only way to do what was
intended here.=C2=A0 Either the version negotiation packet includes the
client's chosen version and is ignored, or it doesn't match the
version that the other server will ultimately advertise.=C2=A0 BTW, I'v= e
opened an issue for documenting how a server cluster might be upgraded
(and rolled back): https://github.com/quicwg/ba= se-drafts/issues/504

The use case you are missing is one where the server receives an
unsupported version AND it wants to send the client to another server.
One reason you might want to do that is to avoid a second round trip.
I'll concede that is a little unlikely given the potential need for
address validation, so it's a pretty minor gain, but a gain
nonetheless.

So an example would be:
Client sends CHLO in QUICv2
Server only speaks QUICv1, an= d wants to shed load to another that speaks QUICv1
Server sends V= N with Connection ID that leads client to other server on retry
<= br>
This will be a super rare case: VN itself should be rare to b= egin with, given Alt-Svc. Within that probability, this is a server that wa= nts to shed load and knows which server to shed to. And for those connectio= ns, we're saving 1 RTT. This one =C2=A0RTT will be amortized if there a= re subsequent connections, since subsequent connections should learn about = the new version and not incur the VN delay. This optimization is super unli= kely to affect performance for applications or for servers.

<= /div>
Can you demonstrate something that we would lose by allowing the
server to propose a connection ID here?=C2=A0 The gain might be small, but<= br> I'm not seeing any downside to allowing it.

=
I don't think we should add complexity to optimize an RTT for supe= r rare cases. If we could do it for no cost, that's fine. But I don'= ;t think it makes sense to consider a design that gets limited because of t= his rare case. The fewer places that we have code doing the same or similar= things, the better, so if there's a mechanism that works well for the = rest of the cases and VN fits in seamlessly, then sure, let's do it.

> This mechanism (and the previous one in the current spec) have both th= e
> server and the client changing connection IDs -- the server does it du= ring
> handshake and the client does it after it receives one or more
> NEW_CONNECTION_ID frames. I think we can make this simpler (both in pr= otocol
> and impl) with only the client initiating this change by sending a pac= ket
> with a server-chosen connection ID first.

Let me try to restate your proposal.

You would have the entire handshake complete with the same connection
ID, then switch to a different connection ID once the handshake
completes.=C2=A0 A stateless reject would be allowed to cause re-routing

Yes, that's correct.
=C2=A0=
I'm not sure that I understand the advantages that this design has.
You claim that it reduces the number of mechanisms to two, but I think
that you end up with three because you need to use a transport
parameter.=C2=A0 (FWIW, the current writeup essentially only has two
mechanisms: NEW_CONNECTION_ID and server handshake packets, though
I'll concede that there might be three of those).=C2=A0 It has essentia= lly
the same properties as what I've written up, but it's more complica= ted
in several ways.
=C2=A0
The NEW_CONNECTION_ID frame implies a packet number gap.=C2=A0 With client<= br> authentication, the server might receive encrypted packets before the
handshake completes.=C2=A0 If we take ekr's pull request for
NEW_CONNECTION_ID, the server can't know what the gap is without
receiving the handshake packets.

That's= a single bit of information we can add to the frame.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> This would create more exceptions for what can be sent in the clear,
which requires more care.=C2=A0 If, as proposed, we allow multiple new
connection IDs to be sent in the same frame, we wouldn't want that to happen here, so that's another new special case to test.

So you'd send a transport param in the Server Hel= lo (not in the clear) or a frame.=C2=A0
If you're sending the= frame in response to an SR, it will not contain any information that you n= eed to be confidential.
If you're sending the frame after the= ServerHello, it will be encrypted with 1-RTT keys.
I don't t= hink you need special rules here.
=C2=A0
That suggests a transport parameter might be a better design, but we
don't send transport parameters in the HelloRetryRequest.=C2=A0 We'= d lose
confidentiality for those unless we created a new set of rules for
what transport parameters can be sent in a HelloRetryRequest.=C2=A0 That generates more special rules.

You'd= use a frame. Since HRR is a STREAM frame, and should be a small one, bundl= ing a NEW_CONNECTION_ID frame with it should be relatively easy (in code.)<= /div>
=C2=A0
I think that you raise an important point here:

> Changing the connection ID on an externally visible transition allows = such load balancers to use the different hashing algorithms correctly on th= e connection IDs.

The current proposal has equally simple rules:

if packet[0] =3D=3D 0x82 or packet[0] =3D=3D 0x86:
=C2=A0 routing =3D client_selected
else:
=C2=A0 routing =3D server_selected

That is, Client Initial and 0-RTT get routing as though the client chose th= e ID.
You would instead have us switch the test to packet[0] & 0x80 =3D=3D 0x= 80
and packet[0] !=3D 0x87 and packet[0] !=3D 0x88, that is every long form packet except the 1-RTT ones.=C2=A0 I don't see any advantage there.

That's not right. Your logical expression reduces to:
if=C2=A0packet[0] !=3D 0x87 and packet[0] !=3D= 0x88:
=C2=A0 routing =3D client_selected
else:
=C2=A0= routing =3D server_selected

... which is the same complexity, but it isn't t= he correct filter anyways. There's a related problem that I realized wi= th this most recent scheme: Connection ID in 0-RTT packets are ambiguous. I= f they follow a Client Initial, they're client-chosen, but if they foll= ow a Client Cleartext, they're server-chosen. I think this is a problem= in your earlier version too. So that's a bummer.

You say you see no advantag= es. I wrote out the advantages in my previous email, but perhaps you didn&#= 39;t see them?=C2=A0

1.=C2=A0Explicitly indica= ting the new connection ID gives the client an explicit correlator from the= client's ID to the new server one, which is better than assuming that = the 4-tuple will only carry packets for this connection.=C2=A0Currently, the client will receive the first se= rver packet with an unknown Connection ID and the only correlator is the fa= ct that it was received on the same 4-tuple that the Client Initial was sen= t on. If you have multiple connections on the same 4-tuple, there's no = explicit correlator.

2.=C2=A0This mechanism (and the previous one in the c= urrent spec) have both the server and the client changing connection IDs --= the server does it during handshake and the client does it after it receiv= es one or more NEW_CONNECTION_ID frames. I think we can make this simpler (= both in protocol and impl) with only the client initiating this change by s= ending a packet with a server-chosen connection ID first. If the client wer= e the only one initiating the change, this would allow the server to not ca= re about doing any changes mid-connection, and it could simply use the conn= ection ID in the largest received packet as the outgoing one.
<= div class=3D"gmail_extra">
These are st= ill valuable if we can have them.=C2=A0
I'll think about this and get back on= Monday. I think the current mechanism in the PR is sound; I'd like to = see if we can address the two issues I mention above.
--f403045ccd5e82aeff054ed09ffb-- From nobody Sun May 7 16:31:11 2017 Return-Path: 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 B946E127ABE for ; Sun, 7 May 2017 16:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3jD68hgyE62l for ; Sun, 7 May 2017 16:31:08 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D3A126C83 for ; Sun, 7 May 2017 16:31:07 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u65so66515085wmu.1 for ; Sun, 07 May 2017 16:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B9hvvrUN372aLxEcrxosMBWskIbIAvoDWcbPcU89xvU=; b=Qhj97GO2SsKwoE/BfQJE5gAqZYixKkv4QFSWjktfW5lYGwY9LMk/1xqTRiUDK4Pr7w agOpgOcPeJpiOccatr6AoKFKWUEGfmziNkzKo2ybeejGkvYvlLRB2IM/msD9kFJLyjPY fP65jfCQBQUSUhCXStxH77dkxuDJJh4ALorP3pmaDaZXtR8VCpOXOTEbbvNO1io8OQ3q jf+yCwp/e11T748heeb+xoKgRzMbcS9q1ZppzEGd7hfwEjrKGjvCPm8U3n6m5Fw0IS2J NJ3qvINb5ILnu9H4K4bTkuBm8uKiC2qDcCJ3EQdOJaQHdCEYfPqYG1QcGGGFCV3JLgMw QJdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B9hvvrUN372aLxEcrxosMBWskIbIAvoDWcbPcU89xvU=; b=QOdBP49MtgeSGMpxByLoBmkBf4uxv+GNmgZjbFzQSbzxJo2S6/xTI2IjDd9YVn7eTO Wpdf6/jnH+3d7tAz6tX3RIOohsj+bpsubNNv0Fy+pXvr12SRYiIRnZVjtLyZuniHb0v0 mwayPUsIC+L5FctXNIZ9F6Fw665JU4xZENAbVHEVhcocysLPy3xAAIITN+cxJp6Y/uJs uvAGWhPkntvkbr/mwjOgzZRgQmBiJMrNQUJz5aqhf5ls6S83GvQ+RZbYPdNePenJ4QtG XhsGGd1kVemcOfKhOvHYV98I8XNFwOuX70XJz8p8vapOPeDBDApaDpGEtko3uG4Ai8t/ UmwA== X-Gm-Message-State: AN3rC/6MGLpjkLjoXyxDE6rHwYgkDgTpHFPMbFhDQESP3/Yq5s4qQCOQ W/8Jy8p7WFjxc4Kzq+6vc120KjrFoA== X-Received: by 10.25.212.19 with SMTP id l19mr21887875lfg.169.1494199866209; Sun, 07 May 2017 16:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Sun, 7 May 2017 16:31:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 8 May 2017 09:31:05 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 23:31:10 -0000 On 6 May 2017 at 11:06, Jana Iyengar wrote: > I don't think we should add complexity to optimize an RTT for super rare > cases. If we could do it for no cost, that's fine. I guess that it's a matter of perspective. I consider the less complex case to be where the server's connection ID is always correct and the server can respond with a new connection ID if the client sends Client Initial. That means that having Version Negotiation contain a server-selected connection ID is the cheap option. >> I'm not sure that I understand the advantages that this design has. >> You claim that it reduces the number of mechanisms to two, but I think >> that you end up with three because you need to use a transport >> parameter. (FWIW, the current writeup essentially only has two >> mechanisms: NEW_CONNECTION_ID and server handshake packets, though >> I'll concede that there might be three of those). It has essentially >> the same properties as what I've written up, but it's more complicated >> in several ways. >> >> >> >> The NEW_CONNECTION_ID frame implies a packet number gap. With client >> authentication, the server might receive encrypted packets before the >> handshake completes. If we take ekr's pull request for >> NEW_CONNECTION_ID, the server can't know what the gap is without >> receiving the handshake packets. > > > That's a single bit of information we can add to the frame. Yep, more complexity. >> You would instead have us switch the test to packet[0] & 0x80 == 0x80>> and packet[0] != 0x87 and packet[0] != 0x88, that is every long form >> packet except the 1-RTT ones. I don't see any advantage there. > > > That's not right. Your logical expression reduces to: > if packet[0] != 0x87 and packet[0] != 0x88: > routing = client_selected > else: > routing = server_selected Read it again, it's not the same. It says everything with long form except those two. Though the point was poorly made: the logic isn't particularly relevant. > ... which is the same complexity, but it isn't the correct filter anyways. > There's a related problem that I realized with this most recent scheme: > Connection ID in 0-RTT packets are ambiguous. If they follow a Client > Initial, they're client-chosen, but if they follow a Client Cleartext, > they're server-chosen. I think this is a problem in your earlier version > too. So that's a bummer. > > You say you see no advantages. I wrote out the advantages in my previous > email, but perhaps you didn't see them? > > 1. Explicitly indicating the new connection ID gives the client an explicit > correlator from the client's ID to the new server one, which is better than > assuming that the 4-tuple will only carry packets for this connection. > Currently, the client will receive the first server packet with an unknown > Connection ID and the only correlator is the fact that it was received on > the same 4-tuple that the Client Initial was sent on. If you have multiple > connections on the same 4-tuple, there's no explicit correlator. OK, that didn't seem like a real advantage to me, just a rearrangement of the furniture. Packets reach the client based on port/IP pairs. > 2. This mechanism (and the previous one in the current spec) have both the > server and the client changing connection IDs -- the server does it during > handshake and the client does it after it receives one or more > NEW_CONNECTION_ID frames. I think we can make this simpler (both in protocol > and impl) with only the client initiating this change by sending a packet > with a server-chosen connection ID first. If the client were the only one > initiating the change, this would allow the server to not care about doing > any changes mid-connection, and it could simply use the connection ID in the > largest received packet as the outgoing one. Yes, my assertion was that this isn't in fact simpler due to the need for special rules during the handshake. If you wanted to talk about how we might, for example, use a different connection ID in each direction, then I might concede that there are advantages in using the frame type. From nobody Mon May 8 18:36:32 2017 Return-Path: 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 2AA1A1294C4 for ; Mon, 8 May 2017 18:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 iR-sN2PAZb0D for ; Mon, 8 May 2017 18:36:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 659FD126C83 for ; Mon, 8 May 2017 18:36:29 -0700 (PDT) Received: from [192.168.1.18] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DE7D622E1F3; Mon, 8 May 2017 21:36:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Consensus Call: A Few More Issues From: Mark Nottingham In-Reply-To: <02E96EDA-53F7-427F-B65E-835E713331B1@mnot.net> Date: Tue, 9 May 2017 11:36:27 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <02E96EDA-53F7-427F-B65E-835E713331B1@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 01:36:31 -0000 These are now marked as has-consensus. Cheers, > On 19 Apr 2017, at 4:08 pm, Mark Nottingham wrote: >=20 > Hello, >=20 > The editors believe that the issues below have been closed by the -02 = drafts (or previous ones); these are the ones that I mentioned as being = missed in the previous round. I *think* they should be = non-controversial, since they're so old. >=20 > Please have a look through them; if there are any resolutions you feel = need more discussion, please request that the issue be reopened. >=20 > Issues that we need to discuss more will be reopened. The remaining = ones will be flagged as `has-consensus.` >=20 > See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). >=20 > These issues (and a few more recent ones that we won't call consensus = on just yet) can be found at: > = >=20 > Cheers, >=20 > #72: Consider eliminating PRIORITY region from HEADERS > #73: PRIORITY and Stream ID space > #146: STREAM frame boundaries > #206: Mismatch between version negotiation in TLS layer and in QUIC = layer -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 8 19:04:21 2017 Return-Path: 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 3E9B31293F5 for ; Mon, 8 May 2017 19:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 NKPToqCbYo4J for ; Mon, 8 May 2017 19:04:17 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD06126C83 for ; Mon, 8 May 2017 19:04:17 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u28so32177840pgn.1 for ; Mon, 08 May 2017 19:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1NbTaJv0cmDw2bmCl0cZrpBYvTXqZHf3/zgWQAadimg=; b=kYBZvI8QQIOLZG+xhwOJ2ox2AzoRVBt4Yin/MMPv/SObdUTSxrypNXFhlkPCSZc8Qw hiSvbKvXpF73LJz1uYg/OqaI7FNp5HGoFqdKauJzKQYQbgT/d7r5+W0nS+e9ga9luTp+ PAUFlftv1COi/fy08It8tOge3Q+jNomTF35GA5YJ6pN9priZp0rngPJQYg341+9Skwg1 pLDsO30UOcKLuYQfipnW1P+3hqmO/D1IQYu7OezY2Xb9ryPWDqC//ryDInu3NcAjH9he heIKFC20BWnh7+yd3+iamkjqxN8Ntljy+48QpdTQ0V1XTM4JNZgiMdWlA6DEZkj5SWgR eaDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1NbTaJv0cmDw2bmCl0cZrpBYvTXqZHf3/zgWQAadimg=; b=dD7e4vdPmmPHBoyvPdIhYkVvafRXv6gakHt9rL38XAPcNioCwekCK8bovt8egWkaFe elIgcq4DIUhdKIVIPmGk434XovzghuZuzTg+WozTDPcxRd3uQyItNo6GFEoHUXEztlwA VGhp6IzP0w9OzT0i3rWNGJ2eTVIIVX8/KnjIFMYzhgEBXKEckoJxZxnt4xhgixnQFkHD e+yvVkTt2+j7lKG3A+fOERuBFd5xuFgz+TiC8i0r2+vzxPVYTAa1EvK57jtlTAxWvW99 zyRCBkMNj+WX4ABjquknTglZY1GzWcqI9SEjUFPYDg9x5KtcSPswPr7d2qYbtOWpFIHD eOFw== X-Gm-Message-State: AN3rC/55fVdw6riGtXj5AfOaA7Lh73jiIoH/o+js7pZ3QXNKlrwJEQ3c nkTzJZRhSrB6Zx0uziSKAlo0gnSvfWrYXf86gQ== X-Received: by 10.84.178.101 with SMTP id y92mr26206689plb.60.1494295456853; Mon, 08 May 2017 19:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:04:16 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 19:04:16 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , QUIC WG Content-Type: multipart/alternative; boundary=94eb2c11ac62e57e5e054f0dc56b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:04:20 -0000 --94eb2c11ac62e57e5e054f0dc56b Content-Type: text/plain; charset=UTF-8 There are two issues that are I brought up; for clarity's sake, I'll limit this discussion to the immediate one. I'm summarizing the two proposals, because it helped clarify my thinking, so I hope it helps others as well. Please correct / add anything you think is incorrect / missing. I'm back in favor of the newer proposal, FWIW, see below. *Proposal #1 (first proposal):* Client sends Client Initial Server sends ServerHello/Stateless Retry/Version Negotiation with new connection ID If server sends SHLO: Client continues with connection, uses server-supplied connection ID Server continues using same connection ID If server sends SR / VN: Client resets connection Client sends Client Cleartext with server-supplied connection ID Server continues using same connection ID. Load balancer rules: Complicated; 0-RTT packets from client following Client Initial carry client-chosen connection ID and those following the Client Cleartext carry server-chosen connection ID. Issues: - no rules specified for the server to verify that the client is indeed using the server's supplied connection ID. - no rules specified for client to verify that the server saw its Client Initial before sending SR/VN. (I see now that the packet number is echoed, but we should turn this into a requirement for the client to verify. This is what I meant by a "correlator" for the client to use to tie the client-chosen ID to the server-chosen one.) *Proposal #2 (newer proposal):* Client sends Client Initial Server sends ServerHello/Stateless Retry/Version Negotiation with new connection ID If server sends SHLO: Client continues with connection, uses server-supplied connection ID Server continues using same connection ID If server sends SR / VN: Client resets connection Client sends Client Initial with server-supplied connection ID #1 (SCID1) Server sends SHLO with new server-chosen connection ID #2 (SCID2). Client continues sending Client Cleartext and 0-RTT packets with SCID1 When SHLO is fully received, client switches to 1-RTT packets and SCID2 Load balancer rules: Simple; 1-RTT packets use server-chosen connection IDs, everything else uses client-chosen IDs (from the load-balancer's point of view, even though SCID1 is actually server-chosen.) Issue (repeating for clarity): - no rules specified for client to verify that the server saw its Client Initial before sending SR/VN. (I see now that the packet number is echoed, but we should turn this into a requirement for the client to verify. This is what I meant by a "correlator" for the client to use to tie the client-chosen ID to the server-chosen one.) Proposal #2 additionally has the value that no rules are required for the server to verify that the client is indeed using the server's supplied connection ID, since the load balancer treats SCID1 as client-chosen anyways. If my understanding is correct, I am back in favor of Proposal #2, because I cannot resolve the load balancer question of 0-RTT packets with Proposal #1. Laying it out like this makes it clearer, and I wonder if some of it can make it into the draft. Currently, the draft does not really specify how a server might use this degree of freedom of specifying server-chosen connection ID in SR packets (especially with load balancing rules the way they are intended to be), and I think it may be valuable to lay out what a server might want to do. Should this go in the applicability draft perhaps? - jana On Sun, May 7, 2017 at 4:31 PM, Martin Thomson wrote: > On 6 May 2017 at 11:06, Jana Iyengar wrote: > > I don't think we should add complexity to optimize an RTT for super rare > > cases. If we could do it for no cost, that's fine. > > I guess that it's a matter of perspective. I consider the less complex > case to be where the server's connection ID is always correct and the > server can respond with a new connection ID if the client sends Client > Initial. That means that having Version Negotiation contain a > server-selected connection ID is the cheap option. > > >> I'm not sure that I understand the advantages that this design has. > >> You claim that it reduces the number of mechanisms to two, but I think > >> that you end up with three because you need to use a transport > >> parameter. (FWIW, the current writeup essentially only has two > >> mechanisms: NEW_CONNECTION_ID and server handshake packets, though > >> I'll concede that there might be three of those). It has essentially > >> the same properties as what I've written up, but it's more complicated > >> in several ways. > >> > >> > >> > >> The NEW_CONNECTION_ID frame implies a packet number gap. With client > >> authentication, the server might receive encrypted packets before the > >> handshake completes. If we take ekr's pull request for > >> NEW_CONNECTION_ID, the server can't know what the gap is without > >> receiving the handshake packets. > > > > > > That's a single bit of information we can add to the frame. > > Yep, more complexity. > > >> You would instead have us switch the test to packet[0] & 0x80 == 0x80>> > and packet[0] != 0x87 and packet[0] != 0x88, that is every long form > >> packet except the 1-RTT ones. I don't see any advantage there. > > > > > > That's not right. Your logical expression reduces to: > > if packet[0] != 0x87 and packet[0] != 0x88: > > routing = client_selected > > else: > > routing = server_selected > > Read it again, it's not the same. It says everything with long form > except those two. Though the point was poorly made: the logic isn't > particularly relevant. > > > ... which is the same complexity, but it isn't the correct filter > anyways. > > There's a related problem that I realized with this most recent scheme: > > Connection ID in 0-RTT packets are ambiguous. If they follow a Client > > Initial, they're client-chosen, but if they follow a Client Cleartext, > > they're server-chosen. I think this is a problem in your earlier version > > too. So that's a bummer. > > > > You say you see no advantages. I wrote out the advantages in my previous > > email, but perhaps you didn't see them? > > > > 1. Explicitly indicating the new connection ID gives the client an > explicit > > correlator from the client's ID to the new server one, which is better > than > > assuming that the 4-tuple will only carry packets for this connection. > > Currently, the client will receive the first server packet with an > unknown > > Connection ID and the only correlator is the fact that it was received on > > the same 4-tuple that the Client Initial was sent on. If you have > multiple > > connections on the same 4-tuple, there's no explicit correlator. > > OK, that didn't seem like a real advantage to me, just a rearrangement > of the furniture. Packets reach the client based on port/IP pairs. > > > 2. This mechanism (and the previous one in the current spec) have both > the > > server and the client changing connection IDs -- the server does it > during > > handshake and the client does it after it receives one or more > > NEW_CONNECTION_ID frames. I think we can make this simpler (both in > protocol > > and impl) with only the client initiating this change by sending a packet > > with a server-chosen connection ID first. If the client were the only one > > initiating the change, this would allow the server to not care about > doing > > any changes mid-connection, and it could simply use the connection ID in > the > > largest received packet as the outgoing one. > > Yes, my assertion was that this isn't in fact simpler due to the need > for special rules during the handshake. > > If you wanted to talk about how we might, for example, use a different > connection ID in each direction, then I might concede that there are > advantages in using the frame type. > --94eb2c11ac62e57e5e054f0dc56b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are two issues that are I brought up; for clarity= 9;s sake, I'll limit this discussion to the immediate one. I'm summ= arizing the two proposals, because it helped clarify my thinking, so I hope= it helps others as well. Please correct / add anything you think is incorr= ect / missing. I'm back in favor of the newer proposal, FWIW, see below= .

Proposal #1 (first proposal):
Client = sends Client Initial
Server sends ServerHello/Stateless Retry/Ver= sion Negotiation with new connection ID

If server = sends SHLO:
Client continues with connection, uses server-supplie= d connection ID
Server continues using same connection ID

If server sends SR / VN:
Client resets connecti= on
Client sends Client Cleartext with server-supplied connection = ID
Server continues using same connection ID.

<= /div>
Load balancer rules: Complicated; 0-RTT packets from client follo= wing Client Initial carry client-chosen connection ID and those following t= he Client Cleartext carry server-chosen connection ID.

=
Issues:
- no rules specified for the server to verify that the clie= nt is indeed using the server's supplied connection ID.
- no = rules specified for client to verify that the server saw its Client Initial= before sending SR/VN. (I see now that the packet number is echoed, but we = should turn this into a requirement for the client to verify. This is what = I meant by a "correlator" for the client to use to tie the client= -chosen ID to the server-chosen one.)

Prop= osal #2 (newer proposal):
Client sends Client Initial
Server sends ServerHello/Stateless Retry/Version Negotiation wi= th new connection ID

If server sends SHLO:
Client continues with connection, uses server-supplied connection ID
Server continues using same connection ID

I= f server sends SR / VN:
Client resets connection
Client= sends Client Initial with server-supplied connection ID #1 (SCID1)
Server sends SHLO with new server-chosen connection ID #2 (SCID2).
Client continues sending Client Cleartext and 0-RTT pa= ckets with SCID1
When SHLO is fully received, client switches to = 1-RTT packets and SCID2

Load balancer rules: Simpl= e; 1-RTT packets use server-chosen connection IDs, everything else uses cli= ent-chosen IDs (from the load-balancer's point of view, even though SCI= D1 is actually server-chosen.)

Issue (repeati= ng for clarity):
- no rules specified for client to verify that t= he server saw its Client Initial before sending SR/VN. (I see now that the = packet number is echoed, but we should turn this into a requirement for the= client to verify. This is what I meant by a "correlator" for the= client to use to tie the client-chosen ID to the server-chosen one.)

Proposal #2 additionally has the value that no= rules are required for the server to verify that the client is indeed usin= g the server's supplied connection ID, since the load balancer treats S= CID1 as client-chosen anyways.

If my underst= anding is correct, I am back in favor of Proposal #2, because I cannot reso= lve the load balancer question of 0-RTT packets with Proposal #1. Laying it= out like this makes it clearer, and I wonder if some of it can make it int= o the draft. Currently, the draft does not really specify how a server migh= t use this degree of freedom of specifying server-chosen connection ID in S= R packets (especially with load balancing rules the way they are intended t= o be), and I think it may be valuable to lay out what a server might want t= o do. Should this go in the applicability draft perhaps?

- jana



On Sun, May 7, 2017 = at 4:31 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 6 May 2017 at= 11:06, Jana Iyengar <jri@google.com> wrote:
> I don't think we should add complexity to optimize an RTT for supe= r rare
> cases. If we could do it for no cost, that's fine.

I guess that it's a matter of perspective. I consider the less c= omplex
case to be where the server's connection ID is always correct and the server can respond with a new connection ID if the client sends Client
Initial.=C2=A0 That means that having Version Negotiation contain a
server-selected connection ID is the cheap option.

>> I'm not sure that I understand the advantages that this design= has.
>> You claim that it reduces the number of mechanisms to two, but I t= hink
>> that you end up with three because you need to use a transport
>> parameter.=C2=A0 (FWIW, the current writeup essentially only has t= wo
>> mechanisms: NEW_CONNECTION_ID and server handshake packets, though=
>> I'll concede that there might be three of those).=C2=A0 It has= essentially
>> the same properties as what I've written up, but it's more= complicated
>> in several ways.
>>
>>
>>
>> The NEW_CONNECTION_ID frame implies a packet number gap.=C2=A0 Wit= h client
>> authentication, the server might receive encrypted packets before = the
>> handshake completes.=C2=A0 If we take ekr's pull request for >> NEW_CONNECTION_ID, the server can't know what the gap is witho= ut
>> receiving the handshake packets.
>
>
> That's a single bit of information we can add to the frame.

Yep, more complexity.

>> You would instead have us switch the test to packet[0] & 0x80 = =3D=3D 0x80>> and packet[0] !=3D 0x87 and packet[0] !=3D 0x88, that i= s every long form
>> packet except the 1-RTT ones.=C2=A0 I don't see any advantage = there.
>
>
> That's not right. Your logical expression reduces to:
> if packet[0] !=3D 0x87 and packet[0] !=3D 0x88:
>=C2=A0 =C2=A0routing =3D client_selected
> else:
>=C2=A0 =C2=A0routing =3D server_selected

Read it again, it's not the same.=C2=A0 It says everything with = long form
except those two.=C2=A0 Though the point was poorly made: the logic isn'= ;t
particularly relevant.

> ... which is the same complexity, but it isn't the correct filter = anyways.
> There's a related problem that I realized with this most recent sc= heme:
> Connection ID in 0-RTT packets are ambiguous. If they follow a Client<= br> > Initial, they're client-chosen, but if they follow a Client Cleart= ext,
> they're server-chosen. I think this is a problem in your earlier v= ersion
> too. So that's a bummer.
>
> You say you see no advantages. I wrote out the advantages in my previo= us
> email, but perhaps you didn't see them?
>
> 1. Explicitly indicating the new connection ID gives the client an exp= licit
> correlator from the client's ID to the new server one, which is be= tter than
> assuming that the 4-tuple will only carry packets for this connection.=
> Currently, the client will receive the first server packet with an unk= nown
> Connection ID and the only correlator is the fact that it was received= on
> the same 4-tuple that the Client Initial was sent on. If you have mult= iple
> connections on the same 4-tuple, there's no explicit correlator.
OK, that didn't seem like a real advantage to me, just a rearran= gement
of the furniture.=C2=A0 Packets reach the client based on port/IP pairs.
> 2. This mechanism (and the previous one in the current spec) have both= the
> server and the client changing connection IDs -- the server does it du= ring
> handshake and the client does it after it receives one or more
> NEW_CONNECTION_ID frames. I think we can make this simpler (both in pr= otocol
> and impl) with only the client initiating this change by sending a pac= ket
> with a server-chosen connection ID first. If the client were the only = one
> initiating the change, this would allow the server to not care about d= oing
> any changes mid-connection, and it could simply use the connection ID = in the
> largest received packet as the outgoing one.

Yes, my assertion was that this isn't in fact simpler due to the= need
for special rules during the handshake.

If you wanted to talk about how we might, for example, use a different
connection ID in each direction, then I might concede that there are
advantages in using the frame type.

--94eb2c11ac62e57e5e054f0dc56b-- From nobody Mon May 8 19:12:44 2017 Return-Path: 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 A5CF2128B8F for ; Mon, 8 May 2017 19:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MHqm-_lQItpz for ; Mon, 8 May 2017 19:12:39 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCBB126C83 for ; Mon, 8 May 2017 19:12:39 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l50so58080803wrc.3 for ; Mon, 08 May 2017 19:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i41bnv13sdFirW0nBQyQG9k/KacRcfnJZU9GO/Mn4Wg=; b=mrESHNe49dAJBMtmVVjDUC5fHlMXp1FvJ67SUQhmLN6AnFukwiqcNXVgdIc7L2nBcf zMHWscIrB8D01A/vlPtkYdSW8UyGHYJZbW0IlhGhBAPAgIzgDO6f9zevtNBNAKGBKVV6 Hh1TlFn/GZ9DUUm+Oz/3W5xtYGWw8NDHcdLqccyDB5hh6GZ0B+TJYMCq/4Pz/cxSYaZ+ EHjRvDuUAl3slluOoD5iYESqp7clMkn8I8aVXXVtA/3PjYjovdc6SyT/nGVT32Fl7u3A o14gKvNza+44ho2vhVI1ce2Un3STl/t+GjkJFmO2iMgjInS+tKSIswtyxVNRiqd4PbO/ 6ofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i41bnv13sdFirW0nBQyQG9k/KacRcfnJZU9GO/Mn4Wg=; b=uEiq7PECJO5X1pNcsyHmqDxV9+tbXFrIEJRTLek6IE77hFSvxdres7FwDPOhg1ipDT 1DHA7rw/FJsbfFs1cTq6uHcyxjSPQ8ew2TLDg37uJiVVV556dy0VwnC1/44Mmzb2gZ8O f6zMmKyxIJEWBAcKs6E1u6bzGxsmc0qCt2fyrFl1ewncp9CvVapsSCwjDq55f2O3rzad h5/YhA7aiHaQRS/H8ruLP7YzFYa/8jMYcNyWn5QwUDGxcYaq96fGlw1h+NQA5A4gIoDp 7VZmlSuzsTOzAKS++qCg0XGXUDAAwT7mikwnJ6cuTF5gs1k3zYLdmvrc3vhvIsuuCLIp 3b8w== X-Gm-Message-State: AODbwcCw4GfDCF98LRLOG/S0CaNc6Th9b+xIbKP+l7VZbLu4YSQagUUV UQ83YROHn3Sv78s7pfK6tdGTjNU9FQ== X-Received: by 10.46.21.15 with SMTP id s15mr7727723ljd.50.1494295957969; Mon, 08 May 2017 19:12:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 19:12:37 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 May 2017 12:12:37 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:12:40 -0000 On 9 May 2017 at 12:04, Jana Iyengar wrote: > Load balancer rules: Complicated; 0-RTT packets from client following Client > Initial carry client-chosen connection ID and those following the Client > Cleartext carry server-chosen connection ID. No, this isn't right. I already agreed to the client using the same connection ID marking 0-RTT packets, the PR right now explicitly requires the client to keep the same connection ID. It looks like the only disagreement here is over a) whether a Version Negotiation packet can include a new server-chosen connection ID, and b) whether the server-chosen connection ID is carried in the connection ID field, in a frame, or in a transport parameter. From nobody Mon May 8 19:18:19 2017 Return-Path: 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 72CEC128B38 for ; Mon, 8 May 2017 19:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Xm4A8DI45mFt for ; Mon, 8 May 2017 19:18:16 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDFC126C83 for ; Mon, 8 May 2017 19:18:16 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e193so19075122pfh.0 for ; Mon, 08 May 2017 19:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Rm7zXM/VWIBu72YjT7h64z6oOy4zFu7WbxflqaGxAg=; b=KYE3xDtYtLakAaGBcMmdQIHof3vvkLcjPA4/6VLrEJYF3yhKBqBPz1RPnZvceLKbLl S3SXRZHs8p7Y9cuQtQHIElwI2BB9lmC65GJ4D9hyxaUnkq95M6nCmePQq1CGbT6NR1ml 9vvvuR82ZE1+WHza1ILQ4oWfukj960uLRWcBVV2GhFe8NO8/MdMEQlIi82FO+0CJdC8E fSm+ydXIOT36+teztgk9ZSw8uugFELtQA+6lePx7BCl6qC8PK2tNH+9ePBEAs1Tqk/0b DIJrvPjnfH+eqPemCkW7V0sbQR1BoIhCkLnpJOC+a2CwoizEWpWSj7rnH1BgEOhkQvWq R7qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Rm7zXM/VWIBu72YjT7h64z6oOy4zFu7WbxflqaGxAg=; b=nDGPKiqOHBUNYr2U8/UJLTx7YAgEmp+eDdsqVkcGYgZpqQgSMPqQHR5U02MCBlyDhw s+FFbojc/AEof6QG2/qalu7x+5bG1lJ12rM+1jDBiQm0pm9dv97j+g5qaPD3FngBOv4R i+Uu8eM76oAEaJr27NuVB0JMmRQpH+lw3FgfeSSLf1vV9AY1+t3Bd/9LwbU8SaaYFyWa j3QFz5r2HbuS5zn3DWbA7RPyaOMIBH84PoxILr4zFYwwWEi7Dt1Z7tmxhknTThc7vzOG Nc1t7qrtJpJu6ba0aRp5KTgIBEk6go/Fn9VXqm50iuVVEwZ7V0NsmNkFCUosVVebYai7 2OjQ== X-Gm-Message-State: AN3rC/7dG/2+pZisX2yIDyvOO0XC4e28BoVjHcTD2/km5JFR97cib/D4 qay5Iyfk/6aH4QKKEe0hNkxecRvkrUat X-Received: by 10.84.204.8 with SMTP id a8mr88305633ple.4.1494296295986; Mon, 08 May 2017 19:18:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:18:14 -0700 (PDT) Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:18:14 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 19:18:14 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c14896ce9ce5a054f0df73a Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:18:17 -0000 --94eb2c14896ce9ce5a054f0df73a Content-Type: text/plain; charset=UTF-8 Did you see proposal #2? On May 8, 2017 7:12 PM, "Martin Thomson" wrote: > On 9 May 2017 at 12:04, Jana Iyengar wrote: > > Load balancer rules: Complicated; 0-RTT packets from client following > Client > > Initial carry client-chosen connection ID and those following the Client > > Cleartext carry server-chosen connection ID. > > > No, this isn't right. I already agreed to the client using the same > connection ID marking 0-RTT packets, the PR right now explicitly > requires the client to keep the same connection ID. > > It looks like the only disagreement here is over a) whether a Version > Negotiation packet can include a new server-chosen connection ID, and > b) whether the server-chosen connection ID is carried in the > connection ID field, in a frame, or in a transport parameter. > --94eb2c14896ce9ce5a054f0df73a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Did you see proposal #2?
=
On May 8, 2017 7:12 PM, "Martin Thomson= " <martin.thomson@gmail= .com> wrote:
= On 9 May 2017 at 12:04, Jana Iyengar <= jri@google.com> wrote:
> Load balancer rules: Complicated; 0-RTT packets from client following = Client
> Initial carry client-chosen connection ID and those following the Clie= nt
> Cleartext carry server-chosen connection ID.


No, this isn't right.=C2=A0 I already agreed to the client using the sa= me
connection ID marking 0-RTT packets, the PR right now explicitly
requires the client to keep the same connection ID.

It looks like the only disagreement here is over a) whether a Version
Negotiation packet can include a new server-chosen connection ID, and
b) whether the server-chosen connection ID is carried in the
connection ID field, in a frame, or in a transport parameter.
--94eb2c14896ce9ce5a054f0df73a-- From nobody Mon May 8 19:22:36 2017 Return-Path: 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 73187128D16 for ; Mon, 8 May 2017 19:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NcD0nnaCPZYn for ; Mon, 8 May 2017 19:22:34 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFB1126C83 for ; Mon, 8 May 2017 19:22:34 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u65so104615472wmu.1 for ; Mon, 08 May 2017 19:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QCfrat2lDXhs2t34/dnErIH0XoGEfTBa+HmvTDhiwdU=; b=jlUFMXNb3IWMlr7EOQgJCHKa6l3yog9t+ByMUzZCANiLMCQTNkba6a+fwL/xWHsYNh uX6KKcPP50TAluxAG2TcGkrlgt8Bh4OyoH3tye+UVB3Gce8O9Lju7FVJ6dlV24p/WAYR GfvhoJMf5W6t1fWQgmMU5kzQ5jL03Ep71P/yGiSLL4YaCQSaZLSpAdTL+lgoM/vV1Z8Q mhzYvhiZQyJR+vSJFi+hRS+CbnH9Ud8UE3YFy16X56WqGhZS+Aybw2blwrRoK6AvSC4m YTapRWawvyO7BDzaQpSM85x6rEjkZU0L/AW1pr/SrwlJWpVKYYvc+30CPI5uthdWZILA rdnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QCfrat2lDXhs2t34/dnErIH0XoGEfTBa+HmvTDhiwdU=; b=ci6HcopvaetodGq7f5o3jC/8wsCBAyViYk5Vzhs57RAYrnMiwA6pO+ENoyB6PU1vrm C4gZzeci9r83rV+1Mp4TCsaOfjUw5gu3MRJ/atAO/b0wUgXby9F74a3J7vNcN1G2f61D ybDUO25mQwe74pSa6vwob5Fpj0QLsG89pcIwm+D7noy19ixeZGhisH8bJi19EjBuR9pS 5R80/lbWenqPfRJ8t5yjrrOvmeLqTiScYckDyMTQ+oFGb7hFMF8qqyR/slAjZY6cHQZw dqGFpVpZFZSNdiIZvFuMRGqYZ8aSt3CWWf/WK4Q8vy37lCR8FzMvd6aEpAGWvm8Ey+E8 mzBw== X-Gm-Message-State: AN3rC/4bnneKdXCQqxUuLF839VPy+SeY7WZS+EEQaMXvLU8DX+Ne0Cmq dtU3hjQhsMElB/6SlkVva3tJHExdvg== X-Received: by 10.25.212.19 with SMTP id l19mr24672151lfg.169.1494296552727; Mon, 08 May 2017 19:22:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 19:22:32 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 May 2017 12:22:32 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:22:35 -0000 On 9 May 2017 at 12:18, Jana Iyengar wrote: > Did you see proposal #2? Ahh, you changed your mind and I missed the /VN bit. Ahh, so we only disagree on when the client switches to using the server selection. That clearly takes any options away regarding how the connection ID is carried. From nobody Mon May 8 19:36:16 2017 Return-Path: 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 3AD7D128D16 for ; Mon, 8 May 2017 19:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 pUaDbnt3iz6y for ; Mon, 8 May 2017 19:36:13 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBB1128BB6 for ; Mon, 8 May 2017 19:36:13 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e193so19254326pfh.0 for ; Mon, 08 May 2017 19:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n5sYif2GB6vZ3GX/Tldt3xIQ4Co59lEdN4jOXEvyB5A=; b=cABUqvjzQmGY2ERltwczaWIiBgKK2x8c4uLMcwZqKEPubWOGRKxrLqciX6h+20A4os yV5uRNbFNGJTgWliPWpos13DT0E87AQtvvmMhRma+ucTp2HYqvxt7RcLOSvPCyndbec8 3qW9Eq9eLuvWNtPyrzl71OJDto5cfeGnugI+A3AJ9V2t4oIJAGsoTQEb7/ZAn0ilSvCI O448dO8wLSCodb47htbB/Kro9CSrkbh6QAqRO5IoHhoL2xdDv+qv29QNvDMl3ExdgAPa RPnSe8II2NWK3gWSATbLXnmrptuw8R8yE8wPtSwGO6avqNyGt6SNkX8wgNkaDgDwNqb1 GZeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n5sYif2GB6vZ3GX/Tldt3xIQ4Co59lEdN4jOXEvyB5A=; b=oHWOfJ5d+TyKSBp3h/gLrFUVo20w2v37eREqC/iBeOn0RoYSZdTgFyr0lAlc2PQ4g/ k6QlgSZ3md8wNnHzbsM7o9aRNjCuTWsvA8OQwGT4vbc1VH7VUphcpmG1vt5H7QkXsGDm EyFFfeJ1zMPNog73XICpo5PpwAu2fZFJMi1yq8oDWQoxSQ2hhE3GlVTj4EBDolrsH006 DWGtM80Enb3TED0YZfE4yQm/KkC0rfaFoQIUlZwh4f51TO3Y8GkUl1lukpqwGTJMK2ZO wAmUFoDg3m7yrAGFZ35RdW+Y370mf4Oe9noLVeq8oZyqfwHcLxLRl36fSDtQWui9kZxf Yh7A== X-Gm-Message-State: AN3rC/7iewwnJyTLPm3uwTEblfyIaO44s+1Ii5wBzEYQstU3FTrMk/cy el5uXQG0JZSjnUr8cq5ngavgDo7sQkon X-Received: by 10.84.142.101 with SMTP id 92mr90049814plw.112.1494297372762; Mon, 08 May 2017 19:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:36:11 -0700 (PDT) Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:36:11 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 19:36:11 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c13f16c1819bb054f0e3839 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:36:14 -0000 --94eb2c13f16c1819bb054f0e3839 Content-Type: text/plain; charset=UTF-8 On May 8, 2017 7:22 PM, "Martin Thomson" wrote: On 9 May 2017 at 12:18, Jana Iyengar wrote: > Did you see proposal #2? Ahh, you changed your mind and I missed the /VN bit. I did change my mind after thinking about load balancer issues a bit more as I've tried to articulate, but I think there was a lot of confusion because of all the different moving parts. Ahh, so we only disagree on when the client switches to using the server selection. That clearly takes any options away regarding how the connection ID is carried. Do we? Assuming that you agree on proposal #2, how would you change proposal #2? --94eb2c13f16c1819bb054f0e3839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 8, 2017 7:22 PM, "Martin Thomson" <martin.thomson@gmail.co= m> wrote:
On 9 May 2017 a= t 12:18, Jana Iyengar <jri@google.com> wrote:
> Did you see proposal #2?

Ahh, you changed your mind and I missed the /VN bit.
=

I did chang= e my mind after thinking about load balancer issues a bit more as I've = tried to articulate, but I think there was a lot of confusion because of al= l the different moving parts.

Ahh, so we only disagree on when the client switches to using the
server selection.=C2=A0 That clearly takes any options away regarding how the connection ID is carried.

Do we? Assuming that you agree on propos= al #2, how would you change proposal #2?

--94eb2c13f16c1819bb054f0e3839-- From nobody Mon May 8 19:41:32 2017 Return-Path: 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 99052128D16 for ; Mon, 8 May 2017 19:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 gHXrkpyjRZYN for ; Mon, 8 May 2017 19:41:29 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3290F128BB6 for ; Mon, 8 May 2017 19:41:29 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u187so36417744pgb.0 for ; Mon, 08 May 2017 19:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tkk4SILoPBv7PomCGknaciCZUeKbnZJSDUWCR0/4FXc=; b=PybZktn5GzkjxrhdsbWluF/JUAsVpgqsKGzKJHESmW1RjT6Gb75EELFT+UI7UbJjdz cT41n131mmRsRL5ZGH7dFX1AznHc4Vnnovcy8O83NgXEPujdV31XkgMPZJeITzf4BwzC KWBCv1Czg4u2sDiBDf98C6mdUcsmV06TcnLiJheSuF+otAPqmAt2fm0NWjzOBt6pFs+y UUmSTAzeZb8N7Y8zJ5XWI2OBhXFM1+51Sb0WQOn5DcSZUMxwunCx8Bwr8nQP9ZIJM1SH 6zAGqBOWK+am2DZLSU19Z9jUIag8/2rd810BFaknkITBb3BfgWhG3vNPvRjubRIfJ8sh /fLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tkk4SILoPBv7PomCGknaciCZUeKbnZJSDUWCR0/4FXc=; b=j+QNHJvkDMYBcaCZcA6LxDt6boGy/2k8EBc6deA+eVzsn3IW2+BFdmYdIFdrSYV1eN 4RW4FvfF7uKu5yhtyyf9n6PW6XQmAnj2K8ZmkUJyNYngFpuMkV7SnqylmTVO6AQx7jgf zl25egBhl39Nbiqd9GINx6ZQgtO5euyD875fWv408tMOP3rctAql6KWfSNVariFej9aX 8lBwcwoC9Ew8s8AkawJFeDQW3UANbRbmV1YuEZjDUu0LKWAgO73TQUMH3Y2tRKQyU9a4 HGe/gbXdh4d/DkQ4eGxVCOpBmSxzYs4fgJ5XdbgU8JkAbIjVSReEi6/2+bhpUXsLdwd9 kirA== X-Gm-Message-State: AN3rC/4EEmVDKoiWQmOEE79x2ReXs33Zhb1fO1FcCUmp/SPQc+fagPL5 b2T6eT1daVUXnoHt58RlnZA30dNcGd6z X-Received: by 10.98.139.206 with SMTP id e75mr26146866pfl.64.1494297688645; Mon, 08 May 2017 19:41:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:41:27 -0700 (PDT) Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 19:41:27 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 19:41:27 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary=f403045cc264ec0d3b054f0e4ac0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 02:41:30 -0000 --f403045cc264ec0d3b054f0e4ac0 Content-Type: text/plain; charset=UTF-8 On May 8, 2017 7:36 PM, "Jana Iyengar" wrote: On May 8, 2017 7:22 PM, "Martin Thomson" wrote: On 9 May 2017 at 12:18, Jana Iyengar wrote: > Did you see proposal #2? Ahh, you changed your mind and I missed the /VN bit. I did change my mind after thinking about load balancer issues a bit more as I've tried to articulate, but I think there was a lot of confusion because of all the different moving parts. Once we agree on this so far, I'd like to bring up the other questions I'm considering. They may not be worth it, but it'll be easier to discuss them once we're on the same page. Ahh, so we only disagree on when the client switches to using the server selection. That clearly takes any options away regarding how the connection ID is carried. Do we? Assuming that you agree on proposal #2, how would you change proposal #2? --f403045cc264ec0d3b054f0e4ac0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 8, 2017 7:36 PM, "Jana Iyengar" <jri@google.com> wrote:


On May 8, 20= 17 7:22 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
On 9 May 2017 at 12:18, Jana Iyengar <jri@google.com> wrote:
> Did you see proposal #2?

Ahh, you changed your mind and I missed the /VN bit.
=

I did= change my mind after thinking about load balancer issues a bit more as I&#= 39;ve tried to articulate, but I think there was a lot of confusion because= of all the different moving parts.

Once we agree on this so f= ar, I'd like to bring up the other questions I'm considering. They = may not be worth it, but it'll be easier to discuss them once we're= on the same page.

<= div dir=3D"auto">
Ahh, so we only disagree on when the client switches to using the
server selection.=C2=A0 That clearly takes any options away regarding how the connection ID is carried.

Do we? Assuming that you agree on = proposal #2, how would you change proposal #2?


--f403045cc264ec0d3b054f0e4ac0-- From nobody Mon May 8 21:05:07 2017 Return-Path: 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 F2DFE12704B for ; Mon, 8 May 2017 21:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zrGUktCVrNTh for ; Mon, 8 May 2017 21:05:03 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDFE120227 for ; Mon, 8 May 2017 21:05:03 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m123so85652598wma.0 for ; Mon, 08 May 2017 21:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CWFMgmrw1jxSyTRhO6FXjSTY6+tXYR7zFScSWVM/znc=; b=V9hcUzk+lAtCv+n+4Rv3euCu/nlA6L2zJK4UgUynKjZqjLsn+bFFcVCq+i4OJs3nw5 EMFeXVANb6l92w8mi0WhBHqzME2yOipVX9q53vHj+uQLTsBs9V+3zz9rtUa7F3EM53fT eznBoGhfr4+sYsi/vCDVteyoXM195S5Hul7n0VEGjnTQgNcr0g76REv2HkaFCfpEkPIT Xy1pyDiKtZxuXEhcKtcrykIXk6XQl3aNVHBArI3vdl8X0WF9szQOlaullS1crd3iqWTm hehUS9z23dlWmMfUbYYGB5xoBtqUY+418t5wJgzZ1t9tvdPIb/rXkS8dmM12dJcM2Bca BRbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CWFMgmrw1jxSyTRhO6FXjSTY6+tXYR7zFScSWVM/znc=; b=bN5eH+cadWTaC95CNJQnCKOVK5gyHKGjOclNxBKxMpiQdbaQcpPAwrGhKvZkRUuUkf QHsq9OFuZEURoFI2yL7+0goGy+u7n2ukrO9+KxxkcuthAiotlbsEg2QUdvfumzzM3sLv yzFom8dTwFb9KSCaM10+QWHT/V1isT6V3q/nIjfqqsWsH0u2jKs3G1nQdtbLv+Hq94UB h4XKUQLG04tdwVZEScXVTqaG5Ghi6a4rumVPEzJC0H6we7YLciXBhfMM2ld5AD21FZCD dcN5zM2rKmyquwBJ4DC9ffo6oEDOCoW5n63ZNNzfgInytaBXnFtJXKj/nrz5v7zj5vcl HHpg== X-Gm-Message-State: AODbwcAUmDGcbyLWEmshZr6x8/c7GLOxGGUQjQDNrDib7oQ1Wuk2hrKH CSMvX4DaWHNj+RJHNSzeUM1qdRdb4UADGbA= X-Received: by 10.25.33.138 with SMTP id h132mr4816245lfh.43.1494302701818; Mon, 08 May 2017 21:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 21:05:01 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 May 2017 14:05:01 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:05:05 -0000 On 9 May 2017 at 12:36, Jana Iyengar wrote: > Ahh, so we only disagree on when the client switches to using the > server selection. That clearly takes any options away regarding how > the connection ID is carried. > > > Do we? Assuming that you agree on proposal #2, how would you change proposal > #2? I don't have enough info, but I think that there might be a problem. Let's say that the server does bump the client twice, either a stateless reject or version negotiation (or both). That way, when the ClientHello that the server will consume properly will have a server-selected connection ID. Then you have the 1-RTT case with rejections: Client Initial, CCID, ClientHello -> <- Stateless Retry or Version Negotiation, SCID1, [HelloRetryRequest] Client Initial, SCID1, ClientHello -> <- Server Cleartext, SCID2, ServerHello (etc) Client Cleartext, SCID1**?, Finished -> 1-RTT Data, SCID2 -> Client Initial, CCID, ClientHello -> <- Server Cleartext, SCID2, ServerHello (etc) Client Cleartext, SCID2**?, Finished -> 1-RTT Data, SCID2 -> The change you propose is on the Client Cleartext line in the "some rejections" case. If I've understood you correctly, rather than use SCID2 here (as included in what I wrote up), you want to keep using SCID1. A few concerns. If this is right, I'm not sure how the server determines that a client change is OK in the "no rejections" case. I'm assuming here that once a server node sends a ServerHello, it really wants to at least be able to ensure that client packets reach that node again. As you said previously, if you have route_c() and route_s() and you only apply route_c() when the client might have chosen the connection ID. Here, you are proposing that we change that logic to use route_c() for all cleartext packets from a client. I'm still not sure what you are trying to gain by the change. Is the intent to ensure that the handshake all ends up in the same place as 0-RTT data? I've been thinking that the first priority would be to ensure that 1-RTT data and the handshake arrive in the same place and that 0-RTT data might take extra effort to send to the right place (but since it is bounded in size, you might reasonably be able to manage that by forwarding or other such horrors). From nobody Mon May 8 22:01:40 2017 Return-Path: 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 EBC56129AB6 for ; Mon, 8 May 2017 22:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RJJEnLEYMzFm for ; Mon, 8 May 2017 22:01:37 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C59127B52 for ; Mon, 8 May 2017 22:01:36 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b84so77219037wmh.0 for ; Mon, 08 May 2017 22:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NwLwY7c/qlCm2ugthNkFXGFA8nJPXPDTL+gQj8Ritjc=; b=fODLfbqnemr+Ko7sR52VHF67UfsloRtOuU49oyVaJwTlHNjB1uUzcr+V7ZNmV/5Tkw zA9xdcB/+Z2WVwBTxmsYzY+NRfsXQQtR+iMstF2H2Ea0/ddPL1Ch0KucizGoF+uWUKi0 bCpW1x8xJCLKfZxisJQdG4zGGJPqLs+QiVo2YG56xi685lyLNJFVwtUQrRH6ZLLhUjSV CmQXjN2zoHs4zIR8mOYAv09HdG2SomdK0ykKl3WqDzMgbiHbSIDafveARgymHFy1OfVX 8xbEofx/UphunnusCu1HsRbMrw+YhIIlfJQYZbm7W6jC0IpYiwEioImLr4+Y2iZdypMK R9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NwLwY7c/qlCm2ugthNkFXGFA8nJPXPDTL+gQj8Ritjc=; b=eNVa5unu3ch+SRjt8sP/a28Q0Np1RfvIGv5E4CwN3vF4Ob/nkywfn5bapPGnOlTmIp Fi2SLMCjYTGNGvKvEYFZHfgeyQb7oa4dEQffdRjCIKsRjrcS2P7dh3kaKN9nq1N3IpEu u5k6g9aMS505VDnUKr21gpOktaasrIJCtP00rbMHitB1ZUu5xTNoG9x6703CI6pQT7zs Lj15qJy276mqkNNl6vrjk7KXN114A1OA538yhKsjo79NE5AIeishCagGeoeu6umlwtQL GNHVtN0asZzbbiYb8eOKD9ruD5xywovk60Mo7wYLBF+zgbimKmiPNlyOtJGVV9isRrf5 BYyQ== X-Gm-Message-State: AODbwcCxVMU6qAvvOyIDfuBFeMme3QK6mQ6c4cZYNl4khkHvr2DUjBfj NBPpi2CfD+XCCpEuKdeUsrzklwbuV+LSb+I= X-Received: by 10.25.33.138 with SMTP id h132mr4911945lfh.43.1494306095258; Mon, 08 May 2017 22:01:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Mon, 8 May 2017 22:01:34 -0700 (PDT) In-Reply-To: References: <0248e010b13d47a8ab8bc86f9b42970e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 9 May 2017 15:01:34 +1000 Message-ID: Subject: Re: Revisiting 0-RTT transport parameter negotiation To: Jana Iyengar Cc: "Lubashev, Igor" , Victor Vasiliev , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 05:01:39 -0000 I've taken the liberty of raising an issue for this, and a PR: https://github.com/quicwg/base-drafts/issues/513 https://github.com/quicwg/base-drafts/pull/512 I've copied the design that TLS uses: the parameters are implicit, just as ALPN is. I don't think that there is any benefit to including the values explicitly other than an increase to the ClientHello size and an extra sanity check. On 18 April 2017 at 15:41, Martin Thomson wrote: > As I said on the other thread, I think that this design isn't quite > right, though the problem is certainly real. > > The TLS design doesn't rely on the client sending the server what it > thinks the values are, it relies on the server remembering. That has > better confidentiality properties, and it is isomorphic with other TLS > 0-RTT behaviour. > > Note that remembering isn't a chore: the client has to remember the > ticket anyway. Now it has to remember the ticket and the server > transport parameters. The server has a choice: it can remember them > or stuff them in the session ticket (or it could decide never to > change them). The difference being that remembering means that you > don't spend critical early bytes on stuff that you know both sides > already know. > > > On 18 April 2017 at 02:32, Jana Iyengar wrote: >> I like this idea, and I support it. Victor -- do you want to generate a PR >> for this or would you like me to? >> >> On Fri, Apr 7, 2017 at 12:57 PM, Lubashev, Igor wrote: >>> >>> Yes, this seems to work and is simple enough. It would also close issue >>> 425. >>> >>> >>> >>> - Igor >>> >>> >>> >>> From: Victor Vasiliev [mailto:vasilvv@google.com] >>> Sent: Friday, April 07, 2017 2:58 PM >>> To: IETF QUIC WG >>> Subject: Revisiting 0-RTT transport parameter negotiation >>> >>> >>> >>> There was a question of what should the client assume about the server's >>> >>> transport parameters in 0-RTT case. As a result of the discussion at the >>> >>> interim, we arrived to the state where client is allowed to assume either >>> the >>> >>> parameters from the previous session, or the default values. Server may >>> choose >>> >>> whatever parameters it wants, and if that's incompatible with client's >>> >>> assumption of server's 0-RTT parameters, the server may reply with an >>> >>> appropriate error or RST_STREAM, after which the client is supposed to >>> retry >>> >>> the connection. >>> >>> >>> >>> I personally find that this solution has "too many joints", as in, it >>> allows >>> >>> implementations a wide variety of behaviors, which in turn requires their >>> peers >>> >>> to accommodate those scenarios. The situation with the initial flow >>> control >>> >>> window is especially awkward. Server might choose to excuse flow control >>> >>> violations until the 1-RTT phase is reached, which requires client to >>> >>> accommodate possible flow control window decrease upon receiving server >>> hello; >>> >>> or it might choose not to excuse them, which requires client to retry by >>> >>> special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after >>> 0-RTT as >>> >>> a retry signal. All of this adds a complexity burden onto >>> implementations, and >>> >>> makes comprehensive interop testing very hard. >>> >>> >>> >>> Instead of the current negotiation scheme outlined in the draft, I propose >>> that >>> >>> we adapt a simple scheme similar to what TLS does with cryptographic >>> parameters >>> >>> and 0-RTT: >>> >>> 1) Client sends its vision of server's assumed parameters in the >>> ClientHello, >>> >>> and is expected to follow them in 0-RTT packets. >>> >>> 2) Server either accepts those parameters, or declines 0-RTT altogether, >>> >>> by discarding the 0-RTT data and following up with a full 1-RTT >>> handshake. >>> >>> If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot >>> be >>> >>> more limited than what it accepted from the client. >>> >>> >>> >>> In this scenario, both the client and the server can use their regular >>> >>> connection handling logic for 0-RTT data, since both the client and the >>> server >>> >>> have a consistent view of server's parameters. This works well when the >>> >>> parameters match expectations (most of the time), it's simple to >>> implement, and >>> >>> it's simple to test. >>> >>> >>> >>> -- Victor. >> >> From nobody Mon May 8 23:05:45 2017 Return-Path: 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 726B0129AE5 for ; Mon, 8 May 2017 23:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2-qy4pWFa4kg for ; Mon, 8 May 2017 23:05:42 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CE91242EA for ; Mon, 8 May 2017 23:05:42 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u28so34926678pgn.1 for ; Mon, 08 May 2017 23:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HyQCN/HbkCc5rYoaHtOI8ZE4yo/qDpG+B+z290xzIL4=; b=bTgRbD+pHf9nDMChFmDuE3P7Xiz2tJxEqtMlyS67utHyffPH3bVOcfnaS2piVUHBCl 2/AHqdYVZ/534We8CDtlrjS29+h3VsVJbmNoFGFlYlYTo3OU4DHgfJ9a0vwpHsBCrTFd fy4GNMLegLR6FiMl3Hy4/5FdAw1osFKCjihF6VDo7A7IxQzcfQZRulVqPs6oDGQHY+GI x+zejH7f7xrJIMl9kZGtxKcWva0RPlezeslTo3DVX4GSTvA7K2sBZBDzjU+31LEnNy/+ ZHli6skvAm3K2YVI1Qp5oeF7NoefBUcUT6mb0VMeqXfcwBWG56V7mQ7CUI6GZ//0Cr6+ B/3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HyQCN/HbkCc5rYoaHtOI8ZE4yo/qDpG+B+z290xzIL4=; b=AxYenpm8vVewQPwQgPiiqYnuqpdKtNJmIlntWK55LZJy0EmySCcbgpjUBrpc3O0B2/ dbUsN9tm/12OgYrfXgU+b9xlfKA0CdNNQHgaWRnq7CX+r0A6n87FnRxz4AEfWoHu1n1Q yFlaEwiHnGOUjIxmUvpGYvgeXha0oGltyhWd6DVJnNLwilfO15H1jivfuhQaqxbCZx4g uEyeiMoUU5qJ2nxsGMR+11mjMrqIBdsxOb0R3opWHLhUPHfanTT4WEf8u9GwlMuEbHxa vDm1y8FYJWawr6H5S1HtEli107DR2xzwnuewF/fxa1vx9zXr5w8GGEnapFEQQbB1eZX5 Mp0w== X-Gm-Message-State: AN3rC/4nfvlEQWjVWS2MPsMeyrQ2DhdhNFeppQvyQJrmq40FDu++Ybkq EtjFfTkL7f13Dy+6Sd9sdBugibAWlCwN X-Received: by 10.98.139.206 with SMTP id e75mr26867415pfl.64.1494309941572; Mon, 08 May 2017 23:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 23:05:40 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 23:05:40 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG , Subodh Iyengar , Kazuho Oku Content-Type: multipart/alternative; boundary=f403045cc2644127bc054f1125f8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 06:05:44 -0000 --f403045cc2644127bc054f1125f8 Content-Type: text/plain; charset=UTF-8 (I'd like Subodh and Kazuho to weigh in, since they were interested in seeing solutions to this problem.) Ah -- you are right of course! I mis-wrote one part, which I'll correct below. Apologies for seeming like I'm pushing a change -- I wasn't. I was partly trying to think through, and partly mis-articulating, and I think what you just wrote helped clear out the final cobwebs in my addled brain. So here's my corrected proposal, and below it is what I now understand to be the proposal in the PR. In summary, either design works for me. I don't have a strong argument for either. Now that I understand, the text fits fine. It might just be me, but if others find this non-trivial to reason about -- not because the text isn't clear, but because this may just be non-trivial -- I wonder if it will help to explain this flow of packets somewhere... perhaps in the Applicability draft? ---------------- *Proposal #2 (newer proposal), my corrections:* Client sends Client Initial Server sends ServerHello/Stateless Retry/Version Negotiation with new connection ID If server sends SHLO: Client continues with connection, uses client-chosen connection-ID for Client Cleartext and 0-RTT packets *(<-- corrected)* Client switches to server-supplied connection ID for 1-RTT packets. *(<-- corrected)* Server continues using same connection ID If server sends SR / VN: Client resets connection Client sends Client Initial with server-supplied connection ID #1 (SCID1) Server sends SHLO with new server-chosen connection ID #2 (SCID2). Client continues sending Client Cleartext and 0-RTT packets with SCID1 When SHLO is fully received, client switches to 1-RTT packets and SCID2 Load balancer rules: Simple; 1-RTT packets use server-chosen connection IDs, everything else uses client-chosen IDs (from the load-balancer's point of view, even though SCID1 is actually server-chosen.) Issue (repeating for clarity): - no rules specified for client to verify that the server saw its Client Initial before sending SR/VN. (I see now that the packet number is echoed, but we should turn this into a requirement for the client to verify. This is what I meant by a "correlator" for the client to use to tie the client-chosen ID to the server-chosen one.) --------------------- I believe what you're saying is, use client-chosen connection ID on 0-RTT, but not on Client Cleartext packets, since Client Cleartext packets are sent only after the client has heard the first ServerHello packet. Which would change the load balancer rules, as you articulated earlier: Client Initial and 0-RTT packets use client-chosen connection IDs, everything else uses server-chosen connection IDs. ---------------- *Proposal in the PR:* Client sends Client Initial Server sends ServerHello/Stateless Retry/Version Negotiation with new connection ID If server sends SHLO: Client continues with connection, uses client-chosen connection-ID for 0-RTT packets Client switches to server-supplied connection ID for Client Cleartext and 1-RTT packets Server continues using same connection ID If server sends SR / VN: Client resets connection Client sends Client Initial with server-supplied connection ID #1 (SCID1) Server sends SHLO with new server-chosen connection ID #2 (SCID2). Client continues sending 0-RTT packets with SCID1 When first packet of SHLO is received, client switches to SCID2 for Client Cleartext and 1-RTT packets Load balancer rules: Simple; Client Initial and Client Cleartext packets use client-chosen connection IDs, everything else uses server-chosen IDs (from the load-balancer's point of view, even though SCID1 is actually server-chosen.) Issue (repeating for clarity): - no rules specified for client to verify that the server saw its Client Initial before sending SR/VN. (I see now that the packet number is echoed, but we should turn this into a requirement for the client to verify. This is what I meant by a "correlator" for the client to use to tie the client-chosen ID to the server-chosen one.) --------------------- On Mon, May 8, 2017 at 9:05 PM, Martin Thomson wrote: > On 9 May 2017 at 12:36, Jana Iyengar wrote: > > Ahh, so we only disagree on when the client switches to using the > > server selection. That clearly takes any options away regarding how > > the connection ID is carried. > > > > > > Do we? Assuming that you agree on proposal #2, how would you change > proposal > > #2? > > I don't have enough info, but I think that there might be a problem. > > Let's say that the server does bump the client twice, either a > stateless reject or version negotiation (or both). That way, when the > ClientHello that the server will consume properly will have a > server-selected connection ID. > > Then you have the 1-RTT case with rejections: > > > Client Initial, CCID, ClientHello -> > <- Stateless Retry or Version Negotiation, SCID1, [HelloRetryRequest] > Client Initial, SCID1, ClientHello -> > <- Server Cleartext, SCID2, ServerHello (etc) > Client Cleartext, SCID1**?, Finished -> > 1-RTT Data, SCID2 -> > > > Client Initial, CCID, ClientHello -> > <- Server Cleartext, SCID2, ServerHello (etc) > Client Cleartext, SCID2**?, Finished -> > 1-RTT Data, SCID2 -> > > > The change you propose is on the Client Cleartext line in the "some > rejections" case. If I've understood you correctly, rather than use > SCID2 here (as included in what I wrote up), you want to keep using > SCID1. > > A few concerns. If this is right, I'm not sure how the server > determines that a client change is OK in the "no rejections" case. > > I'm assuming here that once a server node sends a ServerHello, it > really wants to at least be able to ensure that client packets reach > that node again. As you said previously, if you have route_c() and > route_s() and you only apply route_c() when the client might have > chosen the connection ID. Here, you are proposing that we change that > logic to use route_c() for all cleartext packets from a client. > > I'm still not sure what you are trying to gain by the change. Is the > intent to ensure that the handshake all ends up in the same place as > 0-RTT data? I've been thinking that the first priority would be to > ensure that 1-RTT data and the handshake arrive in the same place and > that 0-RTT data might take extra effort to send to the right place > (but since it is bounded in size, you might reasonably be able to > manage that by forwarding or other such horrors). > --f403045cc2644127bc054f1125f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(I'd like Subodh and Kazuho to weigh in, sin= ce they were interested in seeing solutions to this problem.)

Ah -- you are right of course! I mis-wrote one part, which I&#= 39;ll correct below. Apologies for seeming like I'm pushing a change --= I wasn't. I was partly trying to think through, and partly mis-articul= ating, and I think what you just wrote helped clear out the final cobwebs i= n my addled brain. So here's my corrected proposal, and below it is wha= t I now understand to be the proposal in the PR. In summary, either design = works for me. I don't have a strong argument for either.

=
Now that I understand, the text fits fine. It might just be me, but if= others find this non-trivial to reason about -- not because the text isn&#= 39;t clear, but because this may just be non-trivial -- I wonder if it will= help to explain this flow of packets somewhere... perhaps in the Applicabi= lity draft?

----------------
Proposal #2 (newer proposal), my corrections:
Client se= nds Client Initial
Server sends ServerHello/Stateless Retry/Versi= on Negotiation with new connection ID

If server se= nds SHLO:
Client continues with connection, uses client-chosen co= nnection-ID for Client Cleartext and 0-RTT packets (<-- corrected)=
Client switches to server-supplied connection ID for 1-R= TT packets. (<-- corrected)
Server continues usi= ng same connection ID

If server sends SR / VN:
Client resets connection
Client sends Client Initial with = server-supplied connection ID #1 (SCID1)
Server sends SHLO with n= ew server-chosen connection ID #2 (SCID2).
Client continues sendi= ng Client Cleartext and 0-RTT packets with SCID1
When SHLO is ful= ly received, client switches to 1-RTT packets and SCID2

Load balancer rules: Simple; 1-RTT packets use server-chosen connecti= on IDs, everything else uses client-chosen IDs (from the load-balancer'= s point of view, even though SCID1 is actually server-chosen.)
Issue (repeating for clarity):
- no rules specified = for client to verify that the server saw its Client Initial before sending = SR/VN. (I see now that the packet number is echoed, but we should turn this= into a requirement for the client to verify. This is what I meant by a &qu= ot;correlator" for the client to use to tie the client-chosen ID to th= e server-chosen one.)
---------------------

<= /div>

I believe what you're saying is, use client-ch= osen connection ID on 0-RTT, but not on Client Cleartext packets, since Cli= ent Cleartext packets are sent only after the client has heard the first Se= rverHello packet. Which would change the load balancer rules, as you articu= lated earlier: Client Initial and 0-RTT packets use client-chosen connectio= n IDs, everything else uses server-chosen connection IDs.

----------------
Proposal in the PR:
Client sends Client Initial
Server sends ServerHello/State= less Retry/Version Negotiation with new connection ID

<= div>If server sends SHLO:
Client continues with connection, uses = client-chosen connection-ID for 0-RTT packets
Client switches to = server-supplied connection ID for Client Cleartext and 1-RTT packets
<= div>Server continues using same connection ID

If s= erver sends SR / VN:
Client resets connection
Client se= nds Client Initial with server-supplied connection ID #1 (SCID1)
= Server sends SHLO with new server-chosen connection ID #2 (SCID2).
Client continues sending 0-RTT packets with SCID1
When first pa= cket of SHLO is received, client switches to SCID2 for Client Cleartext and= 1-RTT packets

Load balancer rules: Simple; Client= Initial and Client Cleartext packets use client-chosen connection IDs, eve= rything else uses server-chosen IDs (from the load-balancer's point of = view, even though SCID1 is actually server-chosen.)

Issue (repeating for clarity):
- no rules specified for client = to verify that the server saw its Client Initial before sending SR/VN. (I s= ee now that the packet number is echoed, but we should turn this into a req= uirement for the client to verify. This is what I meant by a "correlat= or" for the client to use to tie the client-chosen ID to the server-ch= osen one.)
---------------------

=


On Mon, May 8, 2017 at 9:05 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 9 May 2017 at 12:36, Jana Iyengar <jri@google.com> wrote:
> Ahh, so we only disagree on when the client switches to using the
> server selection.=C2=A0 That clearly takes any options away regarding = how
> the connection ID is carried.
>
>
> Do we? Assuming that you agree on proposal #2, how would you change pr= oposal
> #2?

I don't have enough info, but I think that there might be a prob= lem.

Let's say that the server does bump the client twice, either a
stateless reject or version negotiation (or both).=C2=A0 That way, when the=
ClientHello that the server will consume properly will have a
server-selected connection ID.

Then you have the 1-RTT case with rejections:

<some rejections>
Client Initial, CCID, ClientHello ->
=C2=A0 <- Stateless Retry or Version Negotiation, SCID1, [HelloRetryRequ= est]
Client Initial, SCID1, ClientHello ->
=C2=A0 <- Server Cleartext, SCID2, ServerHello (etc)
Client Cleartext, SCID1**?, Finished ->
1-RTT Data, SCID2 ->

<no rejections>
Client Initial, CCID, ClientHello ->
=C2=A0 <- Server Cleartext, SCID2, ServerHello (etc)
Client Cleartext, SCID2**?, Finished ->
1-RTT Data, SCID2 ->


The change you propose is on the Client Cleartext line in the "some rejections" case. If I've understood you correctly, rather than us= e
SCID2 here (as included in what I wrote up), you want to keep using
SCID1.

A few concerns.=C2=A0 If this is right, I'm not sure how the server
determines that a client change is OK in the "no rejections" case= .

I'm assuming here that once a server node sends a ServerHello, it
really wants to at least be able to ensure that client packets reach
that node again.=C2=A0 As you said previously, if you have route_c() and route_s() and you only apply route_c() when the client might have
chosen the connection ID.=C2=A0 Here, you are proposing that we change that=
logic to use route_c() for all cleartext packets from a client.

I'm still not sure what you are trying to gain by the change.=C2=A0 Is = the
intent to ensure that the handshake all ends up in the same place as
0-RTT data?=C2=A0 I've been thinking that the first priority would be t= o
ensure that 1-RTT data and the handshake arrive in the same place and
that 0-RTT data might take extra effort to send to the right place
(but since it is bounded in size, you might reasonably be able to
manage that by forwarding or other such horrors).

--f403045cc2644127bc054f1125f8-- From nobody Mon May 8 23:21:04 2017 Return-Path: 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 7B403129ADD for ; Mon, 8 May 2017 23:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ZA8e4NWo9b-9 for ; Mon, 8 May 2017 23:21:01 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795D31200ED for ; Mon, 8 May 2017 23:21:01 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id e193so21656152pfh.0 for ; Mon, 08 May 2017 23:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UOQ1/zM/N9lx+Fa8dPH9s1Y9KbKQwNYawfxsE94VSZI=; b=IL8Y3tTDIByW10tffZvvti5o94dsYtUyZzIPgJOgjHcmzQoN7q5/Jgu3dcRbSHOKPZ eOkZwpij8LVXMh8Tdw8YELtHf5GWj+8LzEAqWikcXRGqqRQuWCYm92E9vDuwBrHUlZ7G 5LFmxa5j3fm0wp25GS8Us+He0Q5aaaGnkl+D4fFk8MTMZwdhVpHX/P/2D/b0RYHItSUH +/ainZ77Ie/LhUrVxJXUm2Gab9cI0oQXuUHEYbXT8qhEiqLxz/glBSpT9kYLXbvpy/iA kWyBikBEtyRDEFoDgRCoqQGJcCJOvWaNuwfVcqyNXo4TxJrL41wOloCTZMrjYHQKH1ab 3r3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UOQ1/zM/N9lx+Fa8dPH9s1Y9KbKQwNYawfxsE94VSZI=; b=c7PYyTAKIOy+aCGH+gO68pO7afnIrULDy3dOsMVF+m7tYSQnSlsHf1a5JRb6dVggUX wizxkMVPyG0PnunoqCqqmNIVLT18bhISiwHZV+ddShEKu9bc2KJfcN9BH7lrNrAcOy/B OntBvlfJzLFfuPzAaWHcf9NM/a9rj/poWQsJcQuHF7eS1VDLhrrGYWCM17dJV/2Lh/qo IoIrn5n3aWqKABxo3ygtAc9RMz4fXzF3qZRzUP9u+CGYlqaMzG0t7hX35IScIJ+2oTc3 V/jRSJy0DAr6ZiAIrlyToKb1h8Q44KoBwzKl0V5TryWpy5phMlvnOH8AuzTaLJ7xWX1Y T7tw== X-Gm-Message-State: AN3rC/7Og8VxZ2smSgT6pUvmqUBCdwx4SXwBTNB3bZR8eHAHmJy3h3+K Sl5HVQQRGvWLa0z78DzuhXWgb05+/y7r X-Received: by 10.98.139.206 with SMTP id e75mr26935707pfl.64.1494310860784; Mon, 08 May 2017 23:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Mon, 8 May 2017 23:21:00 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 8 May 2017 23:21:00 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG , Subodh Iyengar , Kazuho Oku Content-Type: multipart/alternative; boundary=f403045cc2640b95db054f115cf4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 06:21:03 -0000 --f403045cc2640b95db054f115cf4 Content-Type: text/plain; charset=UTF-8 Let me know if we are on the same page. I'd still like to see if there's anything we can do about localizing connection ID changes to the client, but I think it's probably best if we discuss that separately and not on this PR. On Mon, May 8, 2017 at 11:05 PM, Jana Iyengar wrote: > (I'd like Subodh and Kazuho to weigh in, since they were interested in > seeing solutions to this problem.) > > Ah -- you are right of course! I mis-wrote one part, which I'll correct > below. Apologies for seeming like I'm pushing a change -- I wasn't. I was > partly trying to think through, and partly mis-articulating, and I think > what you just wrote helped clear out the final cobwebs in my addled brain. > So here's my corrected proposal, and below it is what I now understand to > be the proposal in the PR. In summary, either design works for me. I don't > have a strong argument for either. > > Now that I understand, the text fits fine. It might just be me, but if > others find this non-trivial to reason about -- not because the text isn't > clear, but because this may just be non-trivial -- I wonder if it will help > to explain this flow of packets somewhere... perhaps in the Applicability > draft? > > ---------------- > *Proposal #2 (newer proposal), my corrections:* > Client sends Client Initial > Server sends ServerHello/Stateless Retry/Version Negotiation with new > connection ID > > If server sends SHLO: > Client continues with connection, uses client-chosen connection-ID for > Client Cleartext and 0-RTT packets *(<-- corrected)* > Client switches to server-supplied connection ID for 1-RTT packets. *(<-- > corrected)* > Server continues using same connection ID > > If server sends SR / VN: > Client resets connection > Client sends Client Initial with server-supplied connection ID #1 (SCID1) > Server sends SHLO with new server-chosen connection ID #2 (SCID2). > Client continues sending Client Cleartext and 0-RTT packets with SCID1 > When SHLO is fully received, client switches to 1-RTT packets and SCID2 > > Load balancer rules: Simple; 1-RTT packets use server-chosen connection > IDs, everything else uses client-chosen IDs (from the load-balancer's point > of view, even though SCID1 is actually server-chosen.) > > Issue (repeating for clarity): > - no rules specified for client to verify that the server saw its Client > Initial before sending SR/VN. (I see now that the packet number is echoed, > but we should turn this into a requirement for the client to verify. This > is what I meant by a "correlator" for the client to use to tie the > client-chosen ID to the server-chosen one.) > --------------------- > > > I believe what you're saying is, use client-chosen connection ID on 0-RTT, > but not on Client Cleartext packets, since Client Cleartext packets are > sent only after the client has heard the first ServerHello packet. Which > would change the load balancer rules, as you articulated earlier: Client > Initial and 0-RTT packets use client-chosen connection IDs, everything else > uses server-chosen connection IDs. > > ---------------- > *Proposal in the PR:* > Client sends Client Initial > Server sends ServerHello/Stateless Retry/Version Negotiation with new > connection ID > > If server sends SHLO: > Client continues with connection, uses client-chosen connection-ID for > 0-RTT packets > Client switches to server-supplied connection ID for Client Cleartext and > 1-RTT packets > Server continues using same connection ID > > If server sends SR / VN: > Client resets connection > Client sends Client Initial with server-supplied connection ID #1 (SCID1) > Server sends SHLO with new server-chosen connection ID #2 (SCID2). > Client continues sending 0-RTT packets with SCID1 > When first packet of SHLO is received, client switches to SCID2 for Client > Cleartext and 1-RTT packets > > Load balancer rules: Simple; Client Initial and Client Cleartext packets > use client-chosen connection IDs, everything else uses server-chosen IDs > (from the load-balancer's point of view, even though SCID1 is actually > server-chosen.) > > Issue (repeating for clarity): > - no rules specified for client to verify that the server saw its Client > Initial before sending SR/VN. (I see now that the packet number is echoed, > but we should turn this into a requirement for the client to verify. This > is what I meant by a "correlator" for the client to use to tie the > client-chosen ID to the server-chosen one.) > --------------------- > > > > On Mon, May 8, 2017 at 9:05 PM, Martin Thomson > wrote: > >> On 9 May 2017 at 12:36, Jana Iyengar wrote: >> > Ahh, so we only disagree on when the client switches to using the >> > server selection. That clearly takes any options away regarding how >> > the connection ID is carried. >> > >> > >> > Do we? Assuming that you agree on proposal #2, how would you change >> proposal >> > #2? >> >> I don't have enough info, but I think that there might be a problem. >> >> Let's say that the server does bump the client twice, either a >> stateless reject or version negotiation (or both). That way, when the >> ClientHello that the server will consume properly will have a >> server-selected connection ID. >> >> Then you have the 1-RTT case with rejections: >> >> >> Client Initial, CCID, ClientHello -> >> <- Stateless Retry or Version Negotiation, SCID1, [HelloRetryRequest] >> Client Initial, SCID1, ClientHello -> >> <- Server Cleartext, SCID2, ServerHello (etc) >> Client Cleartext, SCID1**?, Finished -> >> 1-RTT Data, SCID2 -> >> >> >> Client Initial, CCID, ClientHello -> >> <- Server Cleartext, SCID2, ServerHello (etc) >> Client Cleartext, SCID2**?, Finished -> >> 1-RTT Data, SCID2 -> >> >> >> The change you propose is on the Client Cleartext line in the "some >> rejections" case. If I've understood you correctly, rather than use >> SCID2 here (as included in what I wrote up), you want to keep using >> SCID1. >> >> A few concerns. If this is right, I'm not sure how the server >> determines that a client change is OK in the "no rejections" case. >> >> I'm assuming here that once a server node sends a ServerHello, it >> really wants to at least be able to ensure that client packets reach >> that node again. As you said previously, if you have route_c() and >> route_s() and you only apply route_c() when the client might have >> chosen the connection ID. Here, you are proposing that we change that >> logic to use route_c() for all cleartext packets from a client. >> >> I'm still not sure what you are trying to gain by the change. Is the >> intent to ensure that the handshake all ends up in the same place as >> 0-RTT data? I've been thinking that the first priority would be to >> ensure that 1-RTT data and the handshake arrive in the same place and >> that 0-RTT data might take extra effort to send to the right place >> (but since it is bounded in size, you might reasonably be able to >> manage that by forwarding or other such horrors). >> > > --f403045cc2640b95db054f115cf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me know if we are on the same page.

I'd still like to see if there's anything we can do about localizi= ng connection ID changes to the client, but I think it's probably best = if we discuss that separately and not on this PR.

On Mon, May 8, 2017 at 11:05 PM= , Jana Iyengar <jri@google.com> wrote:
(I'd like Subodh and Kazuho to wei= gh in, since they were interested in seeing solutions to this problem.)

Ah -- you are right of course! I mis-wrote one part,= which I'll correct below. Apologies for seeming like I'm pushing a= change -- I wasn't. I was partly trying to think through, and partly m= is-articulating, and I think what you just wrote helped clear out the final= cobwebs in my addled brain. So here's my corrected proposal, and below= it is what I now understand to be the proposal in the PR. In summary, eith= er design works for me. I don't have a strong argument for either.
=
Now that I understand, the text fits fine. It might just be = me, but if others find this non-trivial to reason about -- not because the = text isn't clear, but because this may just be non-trivial -- I wonder = if it will help to explain this flow of packets somewhere... perhaps in the= Applicability draft?

----------------
Proposal #2 (newer proposal), my corrections:
Client sends Client Initial
Server sends Server= Hello/Stateless Retry/Version Negotiation with new connection ID
=
If server sends SHLO:
Client continues with= connection, uses client-chosen connection-ID for Client Cleartext and 0-RT= T packets (<-- corrected)
Client switches to ser= ver-supplied connection ID for 1-RTT packets. (<-- corrected)<= /i>
Server continues using same connection ID

If server sends SR / VN:
Client resets con= nection
Client sends Client Initial with server-supplied connecti= on ID #1 (SCID1)
Server sends SHLO with new server-chosen connect= ion ID #2 (SCID2).
Client continues sending Client Cleartext and = 0-RTT packets with SCID1
When SHLO is fully received, client swit= ches to 1-RTT packets and SCID2

Load balancer rule= s: Simple; 1-RTT packets use server-chosen connection IDs, everything else = uses client-chosen IDs (from the load-balancer's point of view, even th= ough SCID1 is actually server-chosen.)

Issue (repe= ating for clarity):
- no rules specified for client to verify tha= t the server saw its Client Initial before sending SR/VN. (I see now that t= he packet number is echoed, but we should turn this into a requirement for = the client to verify. This is what I meant by a "correlator" for = the client to use to tie the client-chosen ID to the server-chosen one.)
---------------------


I believe what you're saying is, use client-chosen connection I= D on 0-RTT, but not on Client Cleartext packets, since Client Cleartext pac= kets are sent only after the client has heard the first ServerHello packet.= Which would change the load balancer rules, as you articulated earlier: Cl= ient Initial and 0-RTT packets use client-chosen connection IDs, everything= else uses server-chosen connection IDs.

----= ------------
Proposal in the PR:
Client sends Client Initial
Server sends ServerHello/State= less Retry/Version Negotiation with new connection ID

<= div>If server sends SHLO:
Client continues with connection= , uses client-chosen connection-ID for 0-RTT packets
Client switc= hes to server-supplied connection ID for Client Cleartext and 1-RTT packets=
Server continues using same connection ID
=

If server sends SR / VN:
Client resets connec= tion
Client sends Client Initial with server-supplied connection = ID #1 (SCID1)
Server sends SHLO with new server-chosen connection= ID #2 (SCID2).
Client continues sending 0-RTT packets wit= h SCID1
When first packet of SHLO is received, client switches to= SCID2 for Client Cleartext and 1-RTT packets

Load= balancer rules: Simple; Client Initial and Client Cleartext packets use cl= ient-chosen connection IDs, everything else uses server-chosen IDs (from th= e load-balancer's point of view, even though SCID1 is actually server-c= hosen.)

Issue (repeating for clar= ity):
- no rules specified for client to verify that the server s= aw its Client Initial before sending SR/VN. (I see now that the packet numb= er is echoed, but we should turn this into a requirement for the client to = verify. This is what I meant by a "correlator" for the client to = use to tie the client-chosen ID to the server-chosen one.)
---------------------


<= br>
On Mon, May 8, 2017 at 9:05 PM, Martin Thomso= n <martin.thomson@gmail.com> wrote:
On 9 May 2017 at 12:36, Jana Iyengar <jri@google.com> wrote:
> Ahh, so we only disagree on when the client switches to using the
> server selection.=C2=A0 That clearly takes any options away regarding = how
> the connection ID is carried.
>
>
> Do we? Assuming that you agree on proposal #2, how would you change pr= oposal
> #2?

I don't have enough info, but I think that there might be a prob= lem.

Let's say that the server does bump the client twice, either a
stateless reject or version negotiation (or both).=C2=A0 That way, when the=
ClientHello that the server will consume properly will have a
server-selected connection ID.

Then you have the 1-RTT case with rejections:

<some rejections>
Client Initial, CCID, ClientHello ->
=C2=A0 <- Stateless Retry or Version Negotiation, SCID1, [HelloRetryRequ= est]
Client Initial, SCID1, ClientHello ->
=C2=A0 <- Server Cleartext, SCID2, ServerHello (etc)
Client Cleartext, SCID1**?, Finished ->
1-RTT Data, SCID2 ->

<no rejections>
Client Initial, CCID, ClientHello ->
=C2=A0 <- Server Cleartext, SCID2, ServerHello (etc)
Client Cleartext, SCID2**?, Finished ->
1-RTT Data, SCID2 ->


The change you propose is on the Client Cleartext line in the "some rejections" case. If I've understood you correctly, rather than us= e
SCID2 here (as included in what I wrote up), you want to keep using
SCID1.

A few concerns.=C2=A0 If this is right, I'm not sure how the server
determines that a client change is OK in the "no rejections" case= .

I'm assuming here that once a server node sends a ServerHello, it
really wants to at least be able to ensure that client packets reach
that node again.=C2=A0 As you said previously, if you have route_c() and route_s() and you only apply route_c() when the client might have
chosen the connection ID.=C2=A0 Here, you are proposing that we change that=
logic to use route_c() for all cleartext packets from a client.

I'm still not sure what you are trying to gain by the change.=C2=A0 Is = the
intent to ensure that the handshake all ends up in the same place as
0-RTT data?=C2=A0 I've been thinking that the first priority would be t= o
ensure that 1-RTT data and the handshake arrive in the same place and
that 0-RTT data might take extra effort to send to the right place
(but since it is bounded in size, you might reasonably be able to
manage that by forwarding or other such horrors).


--f403045cc2640b95db054f115cf4-- From nobody Tue May 9 00:05:36 2017 Return-Path: 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 89CB4127599 for ; Tue, 9 May 2017 00:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mTNhNyAMOVKN for ; Tue, 9 May 2017 00:05:34 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DE7129B10 for ; Tue, 9 May 2017 00:05:34 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 142so89624560wma.1 for ; Tue, 09 May 2017 00:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/tyRTd41OFn1F92Mxk1ShhIaJSRMdziaM/7EeTJRhEM=; b=ZLjv7usyyz0HTLzahY+Lb4XsFEnB6KSvQADSSU1V6zligv1rbLnbUD1ijcTs2+SH9+ 7fx5idk424OxaFoXxB9lhUdlBCtQ7F/RsjsdTzJ8cf4DcA5PzmpUIEu44ZLWciJz81rT EKK6+FJ7EwNEIZ2GpKyohySwIVS2OIMVcYkwV0W2VScMLdlqxxRmFXhXpTzXCj0H8M+D 2aUAEugdwT38ySEtqBzB8oNZVZJAfunE2JGH2zMDrAIavrv5PnastAvlDRSKEpFeLnKX PeyPvkoqJLD+sEj988zUZ14RvIaHEYUOyEBu5vDRD3kY4Behtf+vl1Uyr6gDo9e8ahP6 z2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/tyRTd41OFn1F92Mxk1ShhIaJSRMdziaM/7EeTJRhEM=; b=r+zVS0wHuSvzo3jO7m2wZNi8kRtRnjcFdYJSIJjjugoXhzbWV2H/x53w5VlJ+nNAgs 4o7Ic83djsSK68ZFVuFfMgFC+xR/x7DO2DsWoJ+0T9le4mlEOMpy1Y+FTr28hoNLAYG8 WI1GmPLUOpBFgTUxN4RA6VAjmvB4e/Wp9SUCs7l8kNhiuaBkFNa7MEN8JRuJmlaDr9Ys hABmQzuwHXfnywjYqCI/FvIFOcnscNpVxcfT9NDe3CsIAWHS15xkrVfO+WnbnLV56S2l bkKD/4ltn/l/4AxkkYWpmIEY1FfrBJGb4MgGT0o5NbhY5fRDxzjor393YUpvvKtLxj2f Xlng== X-Gm-Message-State: AODbwcBv7xTir28G/NpP14uQtsGvqD35cd4DHO6LR1voQSS9uw5t7Reh d6HV40t8JtHY9A39Ql9M4k1LyLjz9g== X-Received: by 10.25.33.138 with SMTP id h132mr5121348lfh.43.1494313532739; Tue, 09 May 2017 00:05:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 9 May 2017 00:05:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 May 2017 17:05:31 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Jana Iyengar Cc: Ted Hardie , IETF QUIC WG , Subodh Iyengar , Kazuho Oku Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:05:35 -0000 On 9 May 2017 at 16:21, Jana Iyengar wrote: > Let me know if we are on the same page. Yep, I think that's the essence of the choice we have in front of us. Both alternatives are relatively simple once we get over the hurdle of actually understanding each other :) From nobody Tue May 9 00:10:36 2017 Return-Path: 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 A5CC0126DD9 for ; Tue, 9 May 2017 00:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 PVZfFDJRrfma for ; Tue, 9 May 2017 00:10:33 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667DB126557 for ; Tue, 9 May 2017 00:10:33 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id m17so15667860pfg.3 for ; Tue, 09 May 2017 00:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ikgCOeLnkDctU0aaKC+xXEK+w2UsT0HbIFUE0xPVA44=; b=P2jQw3PqgY/vMQjUL/fC0htnfl7zEgCDeiKdDmT399MqGKEfUBseg0n8jpg8tH7SSm Hyz6RaIpDysCFsIWpDKkieTS988Hqp/oIMAbUFmvtA9gLf9evRyxI+9/E2CktY/L18uI +l0ig44zNZRL4Dr4cQGv5ROlZP2oT5hfJUwd/8EfMdeMWMXINnn1eqvbOHPxggEL68Uc PQk/L28J1dv7q4duWk7b6U4W4NxuqIyr6mpjHray6OUrCOSwhFTnYGq9n4wOPZRvvGx3 IFi/1ZwJJQSTsnJM1ExDn74m8mQR6vP2tD5GCmom7lmVUM5siyp0JxPu8wDSkLobv7B6 PyMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ikgCOeLnkDctU0aaKC+xXEK+w2UsT0HbIFUE0xPVA44=; b=nGvIMXW32qTcy1+skabUL10KPgVoIFQcwIbxYhMCjXaPBFffCSViCjZN/b0k8kWU7H HKTvcveDJK1kVmbNPlgmMCVEi8wSe1c1f6NNASITFDBzU67agyKE5mGyza6ht9n+PAHs V8FvMrLt/xIkvYKfTXErOmGr3ljNLuU7sP5cYrgUsZ7gqkERZBFdorLLNnXnos9fb0ll MeyIkKaAbiVti4R1deyhm5lsjJ5VnJsv24WTcbLblNpBEdKKT4VuJWcPPi5aNZj+YvpE LFBJBKWT+FvQETiIGrIesGa0a+HMr0fOLf+lwPD8QkhJg9/9dz/emQlHw37UJAqdjE1Y 9DJA== X-Gm-Message-State: AN3rC/4xnd5XAjVnzZDKvdBFYD+XD2PRKRyzH5FbndV/IWB2AODEVZj7 l6s7d9WiLTxVhkbCx4QrUL/wPVxshvbX X-Received: by 10.84.204.8 with SMTP id a8mr89715481ple.4.1494313832981; Tue, 09 May 2017 00:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Tue, 9 May 2017 00:10:32 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 9 May 2017 00:10:32 -0700 Message-ID: Subject: Re: Proposed changes to cleartext packets To: Martin Thomson Cc: Ted Hardie , IETF QUIC WG , Subodh Iyengar , Kazuho Oku Content-Type: multipart/alternative; boundary=94eb2c14896c32fde9054f120d48 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:10:34 -0000 --94eb2c14896c32fde9054f120d48 Content-Type: text/plain; charset=UTF-8 > > Both alternatives are relatively simple once we get over the hurdle of > actually understanding each other :) > We usually get there -- just needed some patience and time... and less bungling :-) --94eb2c14896c32fde9054f120d48 Content-Type: text/html; charset=UTF-8
Both alternatives are relatively simple once we get over the hurdle of
actually understanding each other :)

We usually get there -- just needed some patience and time... and less bungling :-)

--94eb2c14896c32fde9054f120d48-- From nobody Wed May 10 17:22:41 2017 Return-Path: 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 8BCF9129BCE for ; Wed, 10 May 2017 17:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BIIfRwkZU_YZ for ; Wed, 10 May 2017 17:22:38 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FC712946E for ; Wed, 10 May 2017 17:22:37 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l50so8175337wrc.3 for ; Wed, 10 May 2017 17:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=O7gQawwPEiNXwCkKTX2JO/gcZUMjW81pdyBamt2RnKE=; b=FriFOWZ83cSltDlgT8IFImVIu6hBEo+K1l9sxWy57aGl/V95WFVZidU5c9gW/rR2oB IK/5CEdbUzabeWAobmEAP5mwnEfVUViz5YI20EeNM6ycrOtE/cvgzuvoBqVsqHtD63Hv h1mwbG/WnsJfhCtG4KXoScdFwBTtcY9LBPxVZkJdN541ieB3cMVd3IxC/mzweKTyXP6N hNjCfMR0XS+nhMerrv6d1qhJiiCl3wQ/zuCtVM4lv4kHhsJZBQ/1NNd5zw/SVRILmKVB +b7veozm31h9gXsg0X44NBeyPuw6t6iAk9pkfqWMe7srsO0lguhiZF06CtHwDthCHLRw nEVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=O7gQawwPEiNXwCkKTX2JO/gcZUMjW81pdyBamt2RnKE=; b=fgzO171GkkT9guCofUvE61/5HKPJO96VhX3BWDJ4349fMRmPPOg9SXEjZYe3/XdGHw twJqUegyG+yCFJqElekQ1/eDrEbaGxs0i1h3tFdOqQmgbCvcF5wQR7lbggTt0L07HjqC 47vaQJ7+Qc2O1P5ypro/x3/+GxSb2Tjnp6jzzkOEQ4n7VsnilZUv87YURKuEzEvOkuaQ nIUgRMZrt6G1ZrKaGDqZG5+ryXDpSxcv9q0LntHAavhm3faJSb6wObUMBqXPKwJ+LkDE D2EKfVcVcsyBGYi52IPXbJ2WmIU/N5v9YbSFnah8B7dt0dZZcJB10RFOvniqzke+FWu1 nDhQ== X-Gm-Message-State: AODbwcDCYum50Mss8wJz2qR3wl0i+uOgKPoX8JI78DdmLzZHoMVakO/p o6zhc4jAj4JtEhSPABQOfJT+jMYttxeeQzs= X-Received: by 10.46.69.130 with SMTP id s124mr3804151lja.44.1494462155727; Wed, 10 May 2017 17:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 10 May 2017 17:22:34 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 11 May 2017 10:22:34 +1000 Message-ID: Subject: Re: Proposed changes to cleartext packets To: QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 00:22:39 -0000 On 3 May 2017 at 20:43, Martin Thomson wrote: > These are two separate issues, but they are intermingled in annoying > ways, so I have a single draft PR for both changes: > > https://github.com/quicwg/base-drafts/pull/493 After a bunch of discussion, the editors at least agree that this is an improvement. I have just merged this change into the editor's copy. We will put this on the agenda for the interim to discuss with a larger group. From nobody Wed May 10 21:54:15 2017 Return-Path: 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 2091E12EAFB for ; Wed, 10 May 2017 21:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 HIcG3z-fHtR7 for ; Wed, 10 May 2017 21:54:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 95D85126BF6 for ; Wed, 10 May 2017 21:54:11 -0700 (PDT) Received: from [192.168.1.18] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 87B0722E1FA; Thu, 11 May 2017 00:53:52 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Getting to a First Implementation Draft Message-Id: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> Date: Thu, 11 May 2017 14:53:48 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 04:54:14 -0000 Previously, we've mentioned an intention to have a First Implementation = Draft -- that is, an Internet-Draft that we feel is suitable for = implementers to write code to, for the purposes of interoperability = testing and gathering feedback -- shortly after the Paris interim. Due to the size and complexity of HTTP-over-QUIC, implementing all four = drafts for this purpose on a reasonable timeline isn't workable. Instead, the editors have identified a subset of functionality that they = believe will serve as a suitable starting point. See: https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft They've also identified the set of issues that we believe will be = necessary to have proposals for before Paris; see: https://github.com/quicwg/base-drafts/milestone/1 If all goes well, the plan is to have a set of drafts out (very) soon = that do so; then, we can discuss them and the First Implementation Draft = Candidate in the lead-up to and during the Paris interim. After Paris, we'll make any necessary adjustments to the documents and = publish another set, which will be the First Implementation Draft. Please comment / raise concerns / make suggestions on-list.=20 Regards, -- Mark Nottingham https://www.mnot.net/ From janis.coders@gmail.com Thu May 11 04:59:04 2017 Return-Path: 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 4994912EB94 for ; Thu, 11 May 2017 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9YnCp9GKcaxC for ; Thu, 11 May 2017 04:59:03 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB2B129AFC for ; Thu, 11 May 2017 04:57:12 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id f102so19536261ioi.2 for ; Thu, 11 May 2017 04:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=f9h5URp2Q2IjfTTZzpHIJAoAhc9juxguMuM63Mvfyp0=; b=XodFa+EZZsdzw9+CdU1cktEtXkbM9FK8/vJJSjvFuWwEfn3mdZcy4pQIwZuDPy8D9j Wh3UqFxFb1vJPEATzmjxgKmch/FTZNjo8kgi2yCjFLVXQ437YEz7Pg9IbQIx7qFKN+bE +PSRVJUp3gqWgezLv4J3uqP4MYHUq/0FFsIRpSAAX3qihczBFzC4Boa4raclOdVzF9c+ /1Gqp0anx1LYU3eiQcUfYQXYrFNtS/eiO1a1IsT0vWcVUzc+H3tkDRFuSDaYalRS2kbg FJAEMWNMR5jmEQBbiGuoR5FGjvPZGsgeYtKWLK9taHe99ur7JpqK5BybjkCkaDPaAmVk jDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=f9h5URp2Q2IjfTTZzpHIJAoAhc9juxguMuM63Mvfyp0=; b=CM4y6LGHQgxRi4SvokWIxWdm9H4apQxWaHleNjtjXIpi0pZtBLFEy0WNU2IEHD93c/ l/zC5KK3fZTB7UmVQhqupxu9CX7Ow7HdPOA4/rxo1B8ijaMb+NKKvOJGVt/3x5qIFzBd uTW1S5kgVD6kH5Hl1XlDE54ogSm+a+KSMdh9jkVZgD0Y45V4mJ4ZbmWwOFzpYMZWSUTj XQUB6obo9570np37oFrf60V+ayKgZl4tTYwFlCri5q1Xb4NCsoXWQH/CAwLKwy88XW90 4XJEYJ31LL/FBnwVjevqPK8m+a6kk6N4xGdhuWhJRbK8Ic9y2jx4CNinqnBmefwQOT05 n3DA== X-Gm-Message-State: AODbwcBpoj4NFYAXxk/y3iBOqZR89Ym4nIPSER4GpfWoZ3CD1ZdA/7oP 6iHcardWNAJFfHvaCHMObx2w2HUlusJU X-Received: by 10.107.16.142 with SMTP id 14mr4817849ioq.134.1494503831451; Thu, 11 May 2017 04:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.7.70 with HTTP; Thu, 11 May 2017 04:57:11 -0700 (PDT) From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Thu, 11 May 2017 14:57:11 +0300 Message-ID: Subject: Amplification attack using the same connection id? To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 11 May 2017 09:37:46 -0700 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:25:31 -0000 Hi, doesn't the "free to change source-ip and port" feature make server vulnerable to amplification attacks? Imagine that there is ongoing session and client spoofs source address, but sends the same connection-id - and because it knows all the internal states of QUIC, server should accept and respond to the "new spoofed" address (of course it should be in a state where server's response is bigger than request). NOTE that I am talking about state after the ClientInitial has been verified. Are my assumptions correct? If yes, then how could this be prevented? Maybe by re-verifying that client really changed IP/port, but maybe easier would be allowing to switch IP/port only every X seconds. From nobody Thu May 11 09:48:25 2017 Return-Path: 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 4C16B127868 for ; Thu, 11 May 2017 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 RqQ5K3ulQkXs for ; Thu, 11 May 2017 09:48:20 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B86212EB9B for ; Thu, 11 May 2017 09:42:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E35FD43340D; Thu, 11 May 2017 16:42:03 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C74A0433404; Thu, 11 May 2017 16:42:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494520923; bh=MS+GxNwjXXPqPo8Xt1VptkuTpqcFZRq7aCS35lmpFaM=; l=2456; h=To:References:From:Date:In-Reply-To:From; b=bDymD0A+Ctqp02xTHk9OTSrQnE9poOPFrwzT6nhCSLhxCLzHKNw6Il5VcOgHbNKIK 1PBqovqBbio4+SxlRKxYkAdL1FrkR0Bsl5WkET97+gGAL9KQHh/taInPa3MQp5srYt 4vDX2NL5c1jkaDA309qpON4KhXqjIq/Q4vgCwyt4= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8CCCB1FC03; Thu, 11 May 2017 16:42:03 +0000 (GMT) Subject: Re: Amplification attack using the same connection id? To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= , quic@ietf.org References: From: Benjamin Kaduk Message-ID: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> Date: Thu, 11 May 2017 11:42:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------97128E7BE9C4D9FF9983A5BF" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:48:23 -0000 This is a multi-part message in MIME format. --------------97128E7BE9C4D9FF9983A5BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/11/2017 06:57 AM, Jānis Čoders wrote: > Hi, doesn't the "free to change source-ip and port" feature make > server vulnerable to amplification attacks? Imagine that there is > ongoing session and client spoofs source address, but sends the same > connection-id - and because it knows all the internal states of QUIC, > server should accept and respond to the "new spoofed" address (of > course it should be in a state where server's response is bigger than > request). > NOTE that I am talking about state after the ClientInitial has been verified. > Are my assumptions correct? If yes, then how could this be prevented? > Maybe by re-verifying that client really changed IP/port, but maybe > easier would be allowing to switch IP/port only every X seconds. > If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent. -Ben --------------97128E7BE9C4D9FF9983A5BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/11/2017 06:57 AM, Jānis Čoders wrote:
Hi, doesn't the "free to change source-ip and port" feature make
server vulnerable to amplification attacks? Imagine that there is
ongoing session and client spoofs source address, but sends the same
connection-id - and because it knows all the internal states of QUIC,
server should accept and respond to the "new spoofed" address (of
course it should be in a state where server's response is bigger than
request).
NOTE that I am talking about state after the ClientInitial has been verified.
Are my assumptions correct? If yes, then how could this be prevented?
Maybe by re-verifying that client really changed IP/port, but maybe
easier would be allowing to switch IP/port only every X seconds.

If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent.

-Ben
--------------97128E7BE9C4D9FF9983A5BF-- From nobody Thu May 11 09:57:21 2017 Return-Path: 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 4589E12943C for ; Thu, 11 May 2017 09:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 zVtOAPPaZnbL for ; Thu, 11 May 2017 09:57:18 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 60779129B2A for ; Thu, 11 May 2017 09:52:27 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D22D643343B; Thu, 11 May 2017 16:52:26 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id B1F9F433409; Thu, 11 May 2017 16:52:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494521546; bh=BYMM4VR9G7Io15PPpcQRWebAorSmx/tizpulBipyOAk=; l=3439; h=To:References:From:Date:In-Reply-To:From; b=jlGFO+PjV5wo7y4jzO9490OUkJObgvsiEzUZhm9iQhp+cy2SrRJCpjZICVvQRuwA5 XZHwOj0spPHKXvgthtZbJD+CfE1eSVU/HvgnNmXuQo0LKey8o5vFigEZpNXWsqLDjY RwbNWGjKdLa4BD+ZA5SxG26fbXM7H9hPlytyS5+I= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 798191FC72; Thu, 11 May 2017 16:52:26 +0000 (GMT) Subject: Re: Amplification attack using the same connection id? To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= , quic@ietf.org References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> From: Benjamin Kaduk Message-ID: Date: Thu, 11 May 2017 11:52:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> Content-Type: multipart/alternative; boundary="------------85FB89650875371EAC3F08FE" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 16:57:20 -0000 This is a multi-part message in MIME format. --------------85FB89650875371EAC3F08FE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/11/2017 11:42 AM, Benjamin Kaduk wrote: > On 05/11/2017 06:57 AM, Jānis Čoders wrote: >> Hi, doesn't the "free to change source-ip and port" feature make >> server vulnerable to amplification attacks? Imagine that there is >> ongoing session and client spoofs source address, but sends the same >> connection-id - and because it knows all the internal states of QUIC, >> server should accept and respond to the "new spoofed" address (of >> course it should be in a state where server's response is bigger than >> request). >> NOTE that I am talking about state after the ClientInitial has been verified. >> Are my assumptions correct? If yes, then how could this be prevented? >> Maybe by re-verifying that client really changed IP/port, but maybe >> easier would be allowing to switch IP/port only every X seconds. >> > > If the received message does not cryptographically verify as being > sent by the peer, it is dropped and no reply is sent. Rereading your message more carefully, maybe the "internal states of QUIC" is supposed to include the relevant cryptographic material? Some rate limiting of switching (maybe slightly clever to allow multipath or similar schemes where a small set of routes is used interchangeably) is probably advisable for implementations. -Ben --------------85FB89650875371EAC3F08FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/11/2017 11:42 AM, Benjamin Kaduk wrote:
On 05/11/2017 06:57 AM, Jānis Čoders wrote:
Hi, doesn't the "free to change source-ip and port" feature make
server vulnerable to amplification attacks? Imagine that there is
ongoing session and client spoofs source address, but sends the same
connection-id - and because it knows all the internal states of QUIC,
server should accept and respond to the "new spoofed" address (of
course it should be in a state where server's response is bigger than
request).
NOTE that I am talking about state after the ClientInitial has been verified.
Are my assumptions correct? If yes, then how could this be prevented?
Maybe by re-verifying that client really changed IP/port, but maybe
easier would be allowing to switch IP/port only every X seconds.

If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent.

Rereading your message more carefully, maybe the "internal states of QUIC" is supposed to include the relevant cryptographic material?

Some rate limiting of switching (maybe slightly clever to allow multipath or similar schemes where a small set of routes is used interchangeably) is probably advisable for implementations.

-Ben
--------------85FB89650875371EAC3F08FE-- From nobody Thu May 11 11:00:59 2017 Return-Path: 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 BBEC8129AF9 for ; Thu, 11 May 2017 11:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 Wf6okX56NZMP for ; Thu, 11 May 2017 11:00:55 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D2C50129418 for ; Thu, 11 May 2017 10:55:34 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4BHsNwS023437; Thu, 11 May 2017 18:55:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=fmhqzLRbbGMMKo5CP9Ykm6JFttcaWDCzHyjZ8D9NJq4=; b=miFA/y9TSJ6Ln2+WJg4lcOZpGaoop3AhlbFhZo0hfXN828pOUMbkteLhiXgBZBe/6YUO P7KoCA1yg6gi0BMm/jaKQapUKIQNRIlv+zwHGKps+zcielPTuBY5JyeBBS+1oPOMEwi4 z/EXMENQuXnV42D8BuqZsb1e+76i24nClRTgkGGsjw/tupk2Fctf5wVs8SO7gUg0lD9W 4JAvyJ1ujiHEvjkl9XkK4RCPwhHZ5yauC/GdDNtWnTeE+2CIkbZ7LhmGXEoZ66cRXvKY dbY70kfd9uNHRx5brKW/iik8LY/264hGVOLtwiM84zdzXHZWautjUZvq6GHnoOBdDnd9 nw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2absa1b6gd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 18:55:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4BHa38w005510; Thu, 11 May 2017 13:55:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a99tuj657-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 13:55:31 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 10:55:30 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 11 May 2017 13:55:30 -0400 From: "Lubashev, Igor" To: "Kaduk, Ben" , =?utf-8?B?SsSBbmlzIMSMb2RlcnM=?= , "quic@ietf.org" Subject: RE: Amplification attack using the same connection id? Thread-Topic: Amplification attack using the same connection id? Thread-Index: AQHSynTxuyuEZN72KUe2JZ4J3A/+iKHvmS2AgAAC5gD//8mdcA== Date: Thu, 11 May 2017 17:55:29 +0000 Message-ID: <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.230] Content-Type: multipart/alternative; boundary="_000_0be35d73b1044e20b68018db3470760eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110092 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110093 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 18:00:58 -0000 --_000_0be35d73b1044e20b68018db3470760eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gdGhpcyBhdHRhY2sgc3VwcG9zZXMgdGhhdCBhbiBhdHRhY2tlciBoYXMgZXN0YWJsaXNoZWQg YSBRVUlDIGNvbm5lY3Rpb24gYW5kIGlzIHVzaW5nIHRoYXQgY29ubmVjdGlvbuKAmXMgY3J5cHRv Z3JhcGhpYyBtYXRlcmlhbCBmb3IgYSByZWZsZWN0aW9uIGF0dGFjayBvbiBhIHZpY3RpbS4gIEhv d2V2ZXIsIHdvdWxkIG5vdCB0aGUgdmljdGltIHNpbXBseSByZXBseSB3aXRoIGEgUHVibGljIFJl c2V0IChvciBJQ01QIHBvcnQgdW5yZWFjaGFibGUpLCBhbmQgdGhhdCB3b3VsZCBraWxsIHRoaXMg UVVJQyBjb25uZWN0aW9uPyAgSW4gdGhlIGVuZCwgdGhlIGF0dGFja2VyIHdvdWxkIGhhZCBkb25l IGEgbG90IG9mIHdvcmsgZXN0YWJsaXNoaW5nIHRoZSBjb25uZWN0aW9uIGp1c3QgdG8gZ2V0IGEg c2luZ2xlIHJlZmxlY3RlZCBRVUlDIHBhY2tldCB0byB0aGUgdmljdGltLg0KDQoNCi0gICAgICAg ICAgSWdvcg0KDQpGcm9tOiBCZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmJrYWR1a0Bha2FtYWkuY29t XQ0KU2VudDogVGh1cnNkYXksIE1heSAxMSwgMjAxNyAxMjo1MiBQTQ0KVG86IErEgW5pcyDEjG9k ZXJzIDxqYW5pcy5jb2RlcnNAZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IEFtcGxpZmljYXRpb24gYXR0YWNrIHVzaW5nIHRoZSBzYW1lIGNvbm5lY3Rpb24gaWQ/DQoNCk9u IDA1LzExLzIwMTcgMTE6NDIgQU0sIEJlbmphbWluIEthZHVrIHdyb3RlOg0KDQpPbiAwNS8xMS8y MDE3IDA2OjU3IEFNLCBKxIFuaXMgxIxvZGVycyB3cm90ZToNCg0KDQpIaSwgZG9lc24ndCB0aGUg ImZyZWUgdG8gY2hhbmdlIHNvdXJjZS1pcCBhbmQgcG9ydCIgZmVhdHVyZSBtYWtlDQoNCnNlcnZl ciB2dWxuZXJhYmxlIHRvIGFtcGxpZmljYXRpb24gYXR0YWNrcz8gSW1hZ2luZSB0aGF0IHRoZXJl IGlzDQoNCm9uZ29pbmcgc2Vzc2lvbiBhbmQgY2xpZW50IHNwb29mcyBzb3VyY2UgYWRkcmVzcywg YnV0IHNlbmRzIHRoZSBzYW1lDQoNCmNvbm5lY3Rpb24taWQgLSBhbmQgYmVjYXVzZSBpdCBrbm93 cyBhbGwgdGhlIGludGVybmFsIHN0YXRlcyBvZiBRVUlDLA0KDQpzZXJ2ZXIgc2hvdWxkIGFjY2Vw dCBhbmQgcmVzcG9uZCB0byB0aGUgIm5ldyBzcG9vZmVkIiBhZGRyZXNzIChvZg0KDQpjb3Vyc2Ug aXQgc2hvdWxkIGJlIGluIGEgc3RhdGUgd2hlcmUgc2VydmVyJ3MgcmVzcG9uc2UgaXMgYmlnZ2Vy IHRoYW4NCg0KcmVxdWVzdCkuDQoNCk5PVEUgdGhhdCBJIGFtIHRhbGtpbmcgYWJvdXQgc3RhdGUg YWZ0ZXIgdGhlIENsaWVudEluaXRpYWwgaGFzIGJlZW4gdmVyaWZpZWQuDQoNCkFyZSBteSBhc3N1 bXB0aW9ucyBjb3JyZWN0PyBJZiB5ZXMsIHRoZW4gaG93IGNvdWxkIHRoaXMgYmUgcHJldmVudGVk Pw0KDQpNYXliZSBieSByZS12ZXJpZnlpbmcgdGhhdCBjbGllbnQgcmVhbGx5IGNoYW5nZWQgSVAv cG9ydCwgYnV0IG1heWJlDQoNCmVhc2llciB3b3VsZCBiZSBhbGxvd2luZyB0byBzd2l0Y2ggSVAv cG9ydCBvbmx5IGV2ZXJ5IFggc2Vjb25kcy4NCg0KDQoNCklmIHRoZSByZWNlaXZlZCBtZXNzYWdl IGRvZXMgbm90IGNyeXB0b2dyYXBoaWNhbGx5IHZlcmlmeSBhcyBiZWluZyBzZW50IGJ5IHRoZSBw ZWVyLCBpdCBpcyBkcm9wcGVkIGFuZCBubyByZXBseSBpcyBzZW50Lg0KDQpSZXJlYWRpbmcgeW91 ciBtZXNzYWdlIG1vcmUgY2FyZWZ1bGx5LCBtYXliZSB0aGUgImludGVybmFsIHN0YXRlcyBvZiBR VUlDIiBpcyBzdXBwb3NlZCB0byBpbmNsdWRlIHRoZSByZWxldmFudCBjcnlwdG9ncmFwaGljIG1h dGVyaWFsPw0KDQpTb21lIHJhdGUgbGltaXRpbmcgb2Ygc3dpdGNoaW5nIChtYXliZSBzbGlnaHRs eSBjbGV2ZXIgdG8gYWxsb3cgbXVsdGlwYXRoIG9yIHNpbWlsYXIgc2NoZW1lcyB3aGVyZSBhIHNt YWxsIHNldCBvZiByb3V0ZXMgaXMgdXNlZCBpbnRlcmNoYW5nZWFibHkpIGlzIHByb2JhYmx5IGFk dmlzYWJsZSBmb3IgaW1wbGVtZW50YXRpb25zLg0KDQotQmVuDQo= --_000_0be35d73b1044e20b68018db3470760eusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMxMTUxMDM3Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg2MTk4NzIyIDEyMjEz Mzg0NDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPlNvIHRoaXMgYXR0YWNrIHN1cHBvc2VzIHRoYXQgYW4gYXR0YWNrZXIgaGFzIGVzdGFibGlz aGVkIGEgUVVJQyBjb25uZWN0aW9uIGFuZCBpcyB1c2luZyB0aGF0IGNvbm5lY3Rpb27igJlzIGNy eXB0b2dyYXBoaWMgbWF0ZXJpYWwgZm9yIGEgcmVmbGVjdGlvbiBhdHRhY2sgb24NCiBhIHZpY3Rp bS4mbmJzcDsgSG93ZXZlciwgd291bGQgbm90IHRoZSB2aWN0aW0gc2ltcGx5IHJlcGx5IHdpdGgg YSBQdWJsaWMgUmVzZXQgKG9yIElDTVAgcG9ydCB1bnJlYWNoYWJsZSksIGFuZCB0aGF0IHdvdWxk IGtpbGwgdGhpcyBRVUlDIGNvbm5lY3Rpb24/Jm5ic3A7IEluIHRoZSBlbmQsIHRoZSBhdHRhY2tl ciB3b3VsZCBoYWQgZG9uZSBhIGxvdCBvZiB3b3JrIGVzdGFibGlzaGluZyB0aGUgY29ubmVjdGlv biBqdXN0IHRvIGdldCBhIHNpbmdsZSByZWZsZWN0ZWQNCiBRVUlDIHBhY2tldCB0byB0aGUgdmlj dGltLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JZ29y PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQmVuamFtaW4gS2FkdWsgW21haWx0bzpia2FkdWtAYWth bWFpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDExLCAyMDE3IDEyOjUy IFBNPGJyPg0KPGI+VG86PC9iPiBKxIFuaXMgxIxvZGVycyAmbHQ7amFuaXMuY29kZXJzQGdtYWls LmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFtcGxpZmlj YXRpb24gYXR0YWNrIHVzaW5nIHRoZSBzYW1lIGNvbm5lY3Rpb24gaWQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDUvMTEvMjAxNyAxMTo0MiBBTSwg QmVuamFtaW4gS2FkdWsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDA1LzExLzIwMTcgMDY6NTcgQU0sIErEgW5pcyDEjG9kZXJzIHdy b3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhpLCBkb2Vzbid0IHRoZSAm cXVvdDtmcmVlIHRvIGNoYW5nZSBzb3VyY2UtaXAgYW5kIHBvcnQmcXVvdDsgZmVhdHVyZSBtYWtl PG86cD48L286cD48L3ByZT4NCjxwcmU+c2VydmVyIHZ1bG5lcmFibGUgdG8gYW1wbGlmaWNhdGlv biBhdHRhY2tzPyBJbWFnaW5lIHRoYXQgdGhlcmUgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5v bmdvaW5nIHNlc3Npb24gYW5kIGNsaWVudCBzcG9vZnMgc291cmNlIGFkZHJlc3MsIGJ1dCBzZW5k cyB0aGUgc2FtZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbm5lY3Rpb24taWQgLSBhbmQgYmVj YXVzZSBpdCBrbm93cyBhbGwgdGhlIGludGVybmFsIHN0YXRlcyBvZiBRVUlDLDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnNlcnZlciBzaG91bGQgYWNjZXB0IGFuZCByZXNwb25kIHRvIHRoZSAmcXVv dDtuZXcgc3Bvb2ZlZCZxdW90OyBhZGRyZXNzIChvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNv dXJzZSBpdCBzaG91bGQgYmUgaW4gYSBzdGF0ZSB3aGVyZSBzZXJ2ZXIncyByZXNwb25zZSBpcyBi aWdnZXIgdGhhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlcXVlc3QpLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPk5PVEUgdGhhdCBJIGFtIHRhbGtpbmcgYWJvdXQgc3RhdGUgYWZ0ZXIgdGhlIENs aWVudEluaXRpYWwgaGFzIGJlZW4gdmVyaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXJl IG15IGFzc3VtcHRpb25zIGNvcnJlY3Q/IElmIHllcywgdGhlbiBob3cgY291bGQgdGhpcyBiZSBw cmV2ZW50ZWQ/PG86cD48L286cD48L3ByZT4NCjxwcmU+TWF5YmUgYnkgcmUtdmVyaWZ5aW5nIHRo YXQgY2xpZW50IHJlYWxseSBjaGFuZ2VkIElQL3BvcnQsIGJ1dCBtYXliZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmVhc2llciB3b3VsZCBiZSBhbGxvd2luZyB0byBzd2l0Y2ggSVAvcG9ydCBvbmx5 IGV2ZXJ5IFggc2Vjb25kcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSWYgdGhl IHJlY2VpdmVkIG1lc3NhZ2UgZG9lcyBub3QgY3J5cHRvZ3JhcGhpY2FsbHkgdmVyaWZ5IGFzIGJl aW5nIHNlbnQgYnkgdGhlIHBlZXIsIGl0IGlzIGRyb3BwZWQgYW5kIG5vIHJlcGx5IGlzIHNlbnQu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpSZXJlYWRpbmcgeW91ciBtZXNzYWdlIG1vcmUgY2FyZWZ1bGx5LCBtYXliZSB0aGUgJnF1b3Q7 aW50ZXJuYWwgc3RhdGVzIG9mIFFVSUMmcXVvdDsgaXMgc3VwcG9zZWQgdG8gaW5jbHVkZSB0aGUg cmVsZXZhbnQgY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbD88YnI+DQo8YnI+DQpTb21lIHJhdGUgbGlt aXRpbmcgb2Ygc3dpdGNoaW5nIChtYXliZSBzbGlnaHRseSBjbGV2ZXIgdG8gYWxsb3cgbXVsdGlw YXRoIG9yIHNpbWlsYXIgc2NoZW1lcyB3aGVyZSBhIHNtYWxsIHNldCBvZiByb3V0ZXMgaXMgdXNl ZCBpbnRlcmNoYW5nZWFibHkpIGlzIHByb2JhYmx5IGFkdmlzYWJsZSBmb3IgaW1wbGVtZW50YXRp b25zLjxicj4NCjxicj4NCi1CZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_0be35d73b1044e20b68018db3470760eusma1exdag1mb5msgcorpak_-- From nobody Thu May 11 12:06:18 2017 Return-Path: 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 BB80212420B for ; Thu, 11 May 2017 12:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 6AXR6m_C-Und for ; Thu, 11 May 2017 12:06:15 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id C6F3112E04B for ; Thu, 11 May 2017 11:59:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 57B67433441; Thu, 11 May 2017 18:59:33 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 41C17433404; Thu, 11 May 2017 18:59:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1494529173; bh=uRyEZ0yEKjoz5q2TjVVKCMHDlVGvgtmqwrE6cYxSVC8=; l=11600; h=To:References:From:Date:In-Reply-To:From; b=LIUqdfwyxGz9r1PXNZg52w0YkNcdibM6a2cKkzYhto+wxZkkD9jdU99Gor3RvhhxH 9ApLoeimsZfC0puf1/alMPlwXvs57OYWAXst+Knap3qX34qL32ff02b+Rma3Vjtgr2 KQrNW/38WLuaU7Ddnlngsk8Ni+P3nAik9aRxyyks= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F052B1FC02; Thu, 11 May 2017 18:59:32 +0000 (GMT) Subject: Re: Amplification attack using the same connection id? To: "Lubashev, Igor" , =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= , "quic@ietf.org" References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Benjamin Kaduk Message-ID: <6d800009-feff-afd2-6a9d-f936f2cfba9b@akamai.com> Date: Thu, 11 May 2017 13:59:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------5920B80A7B9A070DEEB46912" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:06:17 -0000 This is a multi-part message in MIME format. --------------5920B80A7B9A070DEEB46912 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Would ICMP port unreachable kill the entire connection? I thought we were leaning towards treating that as just a path signal. -Ben On 05/11/2017 12:55 PM, Lubashev, Igor wrote: > > So this attack supposes that an attacker has established a QUIC > connection and is using that connection’s cryptographic material for a > reflection attack on a victim. However, would not the victim simply > reply with a Public Reset (or ICMP port unreachable), and that would > kill this QUIC connection? In the end, the attacker would had done a > lot of work establishing the connection just to get a single reflected > QUIC packet to the victim. > > > > - Igor > > > > *From:*Benjamin Kaduk [mailto:bkaduk@akamai.com] > *Sent:* Thursday, May 11, 2017 12:52 PM > *To:* Jānis Čoders ; quic@ietf.org > *Subject:* Re: Amplification attack using the same connection id? > > > > On 05/11/2017 11:42 AM, Benjamin Kaduk wrote: > > On 05/11/2017 06:57 AM, Jānis Čoders wrote: > > Hi, doesn't the "free to change source-ip and port" feature make > > server vulnerable to amplification attacks? Imagine that there is > > ongoing session and client spoofs source address, but sends the same > > connection-id - and because it knows all the internal states of QUIC, > > server should accept and respond to the "new spoofed" address (of > > course it should be in a state where server's response is bigger than > > request). > > NOTE that I am talking about state after the ClientInitial has been verified. > > Are my assumptions correct? If yes, then how could this be prevented? > > Maybe by re-verifying that client really changed IP/port, but maybe > > easier would be allowing to switch IP/port only every X seconds. > > > > > If the received message does not cryptographically verify as being > sent by the peer, it is dropped and no reply is sent. > > > Rereading your message more carefully, maybe the "internal states of > QUIC" is supposed to include the relevant cryptographic material? > > Some rate limiting of switching (maybe slightly clever to allow > multipath or similar schemes where a small set of routes is used > interchangeably) is probably advisable for implementations. > > -Ben > --------------5920B80A7B9A070DEEB46912 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Would ICMP port unreachable kill the entire connection?  I thought we were leaning towards treating that as just a path signal.

-Ben

On 05/11/2017 12:55 PM, Lubashev, Igor wrote:

So this attack supposes that an attacker has established a QUIC connection and is using that connection’s cryptographic material for a reflection attack on a victim.  However, would not the victim simply reply with a Public Reset (or ICMP port unreachable), and that would kill this QUIC connection?  In the end, the attacker would had done a lot of work establishing the connection just to get a single reflected QUIC packet to the victim.

 

-          Igor

 

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: Thursday, May 11, 2017 12:52 PM
To: Jānis Čoders <janis.coders@gmail.com>; quic@ietf.org
Subject: Re: Amplification attack using the same connection id?

 

On 05/11/2017 11:42 AM, Benjamin Kaduk wrote:

On 05/11/2017 06:57 AM, Jānis Čoders wrote:

Hi, doesn't the "free to change source-ip and port" feature make
server vulnerable to amplification attacks? Imagine that there is
ongoing session and client spoofs source address, but sends the same
connection-id - and because it knows all the internal states of QUIC,
server should accept and respond to the "new spoofed" address (of
course it should be in a state where server's response is bigger than
request).
NOTE that I am talking about state after the ClientInitial has been verified.
Are my assumptions correct? If yes, then how could this be prevented?
Maybe by re-verifying that client really changed IP/port, but maybe
easier would be allowing to switch IP/port only every X seconds.
 


If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent.


Rereading your message more carefully, maybe the "internal states of QUIC" is supposed to include the relevant cryptographic material?

Some rate limiting of switching (maybe slightly clever to allow multipath or similar schemes where a small set of routes is used interchangeably) is probably advisable for implementations.

-Ben


--------------5920B80A7B9A070DEEB46912-- From nobody Thu May 11 12:07:54 2017 Return-Path: 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 0F03412785F for ; Thu, 11 May 2017 12:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de 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 LbnVLwMMqaF7 for ; Thu, 11 May 2017 12:07:39 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (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 E7DFE131496 for ; Thu, 11 May 2017 12:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494529244; l=11676; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=O1rt+59A+pnphey2FxF+O8KI5EP4jTzk7r5PkvNpEZU=; b=Qhbbf0YfBpu1TJoiYTAY4DQrtrSnB/uElsPCrUrWKRMFJgZPArTDFK3RhbArX3sQxD K66o9plw0eilWM3Iomr4K5gQ9H68PqcETcTbRYYCh0QIJQOnGijw19Sh0vyxJmjK4oLs uauskB7uJFmsYjt/0elaNKtP660cXBjaqR+1c= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyFlHe2GL+jtLdH8slG1mXSK9hXJA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:4c5a:1fd9:f74b:d713] ([2001:4dd0:ff67:0:4c5a:1fd9:f74b:d713]) by smtp.strato.de (RZmta 40.6 AUTH) with ESMTPSA id 505da0t4BJ0h35k (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 11 May 2017 21:00:43 +0200 (CEST) Subject: Re: Amplification attack using the same connection id? To: quic@ietf.org References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Roland Zink Message-ID: Date: Thu, 11 May 2017 21:00:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------761C59419427C0748354C51D" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:07:42 -0000 This is a multi-part message in MIME format. --------------761C59419427C0748354C51D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The victim has no state about the connection and probably can't send an authenticated public reset. Does this mean that public resets shouldn't be authenticated? Roland Am 11.05.2017 um 19:55 schrieb Lubashev, Igor: > > So this attack supposes that an attacker has established a QUIC > connection and is using that connection’s cryptographic material for a > reflection attack on a victim. However, would not the victim simply > reply with a Public Reset (or ICMP port unreachable), and that would > kill this QUIC connection? In the end, the attacker would had done a > lot of work establishing the connection just to get a single reflected > QUIC packet to the victim. > > -Igor > > *From:*Benjamin Kaduk [mailto:bkaduk@akamai.com] > *Sent:* Thursday, May 11, 2017 12:52 PM > *To:* Jānis Čoders ; quic@ietf.org > *Subject:* Re: Amplification attack using the same connection id? > > On 05/11/2017 11:42 AM, Benjamin Kaduk wrote: > > On 05/11/2017 06:57 AM, Jānis Čoders wrote: > > Hi, doesn't the "free to change source-ip and port" feature make > > server vulnerable to amplification attacks? Imagine that there is > > ongoing session and client spoofs source address, but sends the same > > connection-id - and because it knows all the internal states of QUIC, > > server should accept and respond to the "new spoofed" address (of > > course it should be in a state where server's response is bigger than > > request). > > NOTE that I am talking about state after the ClientInitial has been verified. > > Are my assumptions correct? If yes, then how could this be prevented? > > Maybe by re-verifying that client really changed IP/port, but maybe > > easier would be allowing to switch IP/port only every X seconds. > > > If the received message does not cryptographically verify as being > sent by the peer, it is dropped and no reply is sent. > > > Rereading your message more carefully, maybe the "internal states of > QUIC" is supposed to include the relevant cryptographic material? > > Some rate limiting of switching (maybe slightly clever to allow > multipath or similar schemes where a small set of routes is used > interchangeably) is probably advisable for implementations. > > -Ben > --------------761C59419427C0748354C51D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The victim has no state about the connection and probably can't send an authenticated public reset. Does this mean that public resets shouldn't be authenticated?

Roland



Am 11.05.2017 um 19:55 schrieb Lubashev, Igor:

So this attack supposes that an attacker has established a QUIC connection and is using that connection’s cryptographic material for a reflection attack on a victim.  However, would not the victim simply reply with a Public Reset (or ICMP port unreachable), and that would kill this QUIC connection?  In the end, the attacker would had done a lot of work establishing the connection just to get a single reflected QUIC packet to the victim.

 

-          Igor

 

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: Thursday, May 11, 2017 12:52 PM
To: Jānis Čoders <janis.coders@gmail.com>; quic@ietf.org
Subject: Re: Amplification attack using the same connection id?

 

On 05/11/2017 11:42 AM, Benjamin Kaduk wrote:

On 05/11/2017 06:57 AM, Jānis Čoders wrote:

Hi, doesn't the "free to change source-ip and port" feature make
server vulnerable to amplification attacks? Imagine that there is
ongoing session and client spoofs source address, but sends the same
connection-id - and because it knows all the internal states of QUIC,
server should accept and respond to the "new spoofed" address (of
course it should be in a state where server's response is bigger than
request).
NOTE that I am talking about state after the ClientInitial has been verified.
Are my assumptions correct? If yes, then how could this be prevented?
Maybe by re-verifying that client really changed IP/port, but maybe
easier would be allowing to switch IP/port only every X seconds.
 


If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent.


Rereading your message more carefully, maybe the "internal states of QUIC" is supposed to include the relevant cryptographic material?

Some rate limiting of switching (maybe slightly clever to allow multipath or similar schemes where a small set of routes is used interchangeably) is probably advisable for implementations.

-Ben


--------------761C59419427C0748354C51D-- From nobody Thu May 11 12:11:04 2017 Return-Path: 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 2A1FF12F24E for ; Thu, 11 May 2017 12:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dQYG7TyKWDjb for ; Thu, 11 May 2017 12:11:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8276C131446 for ; Thu, 11 May 2017 12:03:04 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id o5so49710550ith.1 for ; Thu, 11 May 2017 12:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9334PqJiDdFbz5C+RpiQj1U/yanErMjxpDYzZ0CL1R8=; b=cgD6zUjvvg9Ov8JejKxyNqnqQ6VeY2PgM7fLOmDzf/u302iVxOq+d+/qg73TT9iiRy +2f5r3vEDpZs66QPqYUM9yincGdJ8Jtkjnb0aB1a0e2C9hzLYS+6Wwtsl0OnMsK1QLgR eTs0rzcbUFsq5wePYhL89fedK9neRP2Ug4bX4laYHA7qPA8+NNuZrCYiZJGJuz833BQE pX2ppohLcu1cE2VI19iCdh3/rTcO7iDO0UdATGrCm3eaGahUNKKWCdJzk/3ChDY/sLuM l/EWRtKFIjH9h9Hk1oz3d+MWLr1RAPSUw+jGX47n1pRaDXq48owgZFZCzkQ9qELMOjH5 IQkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9334PqJiDdFbz5C+RpiQj1U/yanErMjxpDYzZ0CL1R8=; b=BJEYFTCYS0ZiuhPY4m6a8HfmYjhucZz3RxEH2vtHJdG0fLsrqXnrS8YB5mvo0WtCNr uVpNk0UHLuCwH9+Y9gOFCon3URDL3A3BDmHcK4MX4VrGDQs+7lbI5T9WnwMGLh3ZtkUE R7ryMwKqi6QfxKKNUFGYX86acWIPvFG2WLpGqXgPvhvgCNPIaMaMtLRKOiwIgLqOlxEE eEft13nyyx1dUA62iSmH/6ip58tQHYfqjLzL8DXcSeIx0YxPNKUkyrxch27zcSiY/Gd+ 75kMaxeDIry+Y3RmZFlH03vdumwnHsOjyAIDKZezlkerQ2i2GnzQTwQYr/uX+yoAN6OV 2a5A== X-Gm-Message-State: AODbwcBe1Fdl0EQwaaits/5hr+S8aNn5Bv1uxYudpfeSPVeErTFQx/2C 2vdUZcNh/rQnxri7O0/ykWrc/1Z/Fw== X-Received: by 10.36.73.82 with SMTP id z79mr390690ita.20.1494529383896; Thu, 11 May 2017 12:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.7.70 with HTTP; Thu, 11 May 2017 12:03:03 -0700 (PDT) In-Reply-To: <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Thu, 11 May 2017 22:03:03 +0300 Message-ID: Subject: Re: Amplification attack using the same connection id? To: "Lubashev, Igor" Cc: "Kaduk, Ben" , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:11:03 -0000 Well the attack will most probably be made on device/host that doesnt use QUIC or doesnt respond with ICMP because of firewall - but the attacks goal is to saturate target's network. What about situation where a protocol which runs over QUIC responds with big data payload (e.g. client asks for HTTP GET and in the last QUIC packet, changes IP. The HTTP layer doesn't know(care) about transport layer and just sends multiple packets to target - probably until non anknowledget window size is full - and as I understand QUIC should resend the packets, because they are not acknowledget. On 11 May 2017 at 20:55, Lubashev, Igor wrote: > So this attack supposes that an attacker has established a QUIC connectio= n > and is using that connection=E2=80=99s cryptographic material for a refle= ction > attack on a victim. However, would not the victim simply reply with a > Public Reset (or ICMP port unreachable), and that would kill this QUIC > connection? In the end, the attacker would had done a lot of work > establishing the connection just to get a single reflected QUIC packet to > the victim. > > > > - Igor > > > > From: Benjamin Kaduk [mailto:bkaduk@akamai.com] > Sent: Thursday, May 11, 2017 12:52 PM > To: J=C4=81nis =C4=8Coders ; quic@ietf.org > Subject: Re: Amplification attack using the same connection id? > > > > On 05/11/2017 11:42 AM, Benjamin Kaduk wrote: > > On 05/11/2017 06:57 AM, J=C4=81nis =C4=8Coders wrote: > > Hi, doesn't the "free to change source-ip and port" feature make > > server vulnerable to amplification attacks? Imagine that there is > > ongoing session and client spoofs source address, but sends the same > > connection-id - and because it knows all the internal states of QUIC, > > server should accept and respond to the "new spoofed" address (of > > course it should be in a state where server's response is bigger than > > request). > > NOTE that I am talking about state after the ClientInitial has been > verified. > > Are my assumptions correct? If yes, then how could this be prevented? > > Maybe by re-verifying that client really changed IP/port, but maybe > > easier would be allowing to switch IP/port only every X seconds. > > > > > If the received message does not cryptographically verify as being sent b= y > the peer, it is dropped and no reply is sent. > > > Rereading your message more carefully, maybe the "internal states of QUIC= " > is supposed to include the relevant cryptographic material? > > Some rate limiting of switching (maybe slightly clever to allow multipath= or > similar schemes where a small set of routes is used interchangeably) is > probably advisable for implementations. > > -Ben --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Thu May 11 12:23:38 2017 Return-Path: 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 CBDD3129C06 for ; Thu, 11 May 2017 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 gV43-lSb1mwc for ; Thu, 11 May 2017 12:23:34 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E6BE8129B5A for ; Thu, 11 May 2017 12:18:16 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4BJCEEj019322; Thu, 11 May 2017 20:18:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=wiUCghnCeEXCulb06VvVGcgdS2qNpqTGuLWTSwCVnPk=; b=CX5sUMVcMhs21211qjQqeueff7PF5unD6CW/ZkEaeK6gXMX+GdntPfv8oc4QnnXrKleI a9Uv0gP0PRwsLbAYCMKGWyPVnSrcANgUyQV7MfLl4Ft/THYQrX+ji3XFn3s2817fcY+R Eu//mNT/eInri0AQZq8ZhubFIc57fttFNYx7SAA/0bCo6Q/FheclcOMadHAP/Af2HRoE TO/385ysOTE2+WROt7h8cKUaqXLiB4yfx6+P1SBYZ10CgbS15oGL6unKqpQVfQQojuCD 0YK7V94td3JmXpnhkNSEjfGQoLan43TVW+0zR8iMwO8QxckuId6Z8wFDCZfzhXI/WquE Fg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2acux80rc1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 20:18:13 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4BJGemg025433; Thu, 11 May 2017 15:18:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2a99tw7386-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 15:18:11 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 15:18:09 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 11 May 2017 15:18:09 -0400 From: "Lubashev, Igor" To: Roland Zink , "quic@ietf.org" Subject: RE: Amplification attack using the same connection id? Thread-Topic: Amplification attack using the same connection id? Thread-Index: AQHSynTxuyuEZN72KUe2JZ4J3A/+iKHvmS2AgAAC5gD//8mdcIAAWjwA///AXzA= Date: Thu, 11 May 2017 19:18:08 +0000 Message-ID: References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.230] Content-Type: multipart/alternative; boundary="_000_ef1de6f866a040d9af815d362c8eb735usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110101 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110101 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:23:37 -0000 --_000_ef1de6f866a040d9af815d362c8eb735usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGxlZ2l0aW1hdGUgcmVhc29ucyB3aHkgYW4gZW5kcG9pbnQgbG9zZXMgc3RhdGUg KGFwcCByZXN0YXJ0LCBmb3IgZXhhbXBsZSkuICBUaGUgZW5kcG9pbnQgdy9vIHN0YXRlIG5lZWRz IHRvIGJlIGFibGUgdG8gdGVsbCB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgY29ubmVjdGlvbiB0aGF0 IGl0IGNhbm5vdCBjb250aW51ZSBhbmQgbXVzdCByZXNldC4gIFRoZSBvbmx5IHByb29mIHRoZSBl bmRwb2ludCB3L28gc3RhdGUgY2FuIG9mZmVyIGlzIHRoYXQgaXQgcmVjZWl2ZWQgYSBwYWNrZXQg dG8gd2hpY2ggaXQgaXMgcmVwbHlpbmcgYnkgaW5jbHVkaW5nIGRhdGEgZGVyaXZlZCBmcm9tIHRo ZSBjb250ZW50cyBvZiB0aGF0IHBhY2tldC4NCg0KDQotICAgICAgICAgIElnb3INCg0KRnJvbTog Um9sYW5kIFppbmsgW21haWx0bzpyb2xhbmRAemlua3MuZGVdDQpTZW50OiBUaHVyc2RheSwgTWF5 IDExLCAyMDE3IDM6MDEgUE0NClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQW1wbGlm aWNhdGlvbiBhdHRhY2sgdXNpbmcgdGhlIHNhbWUgY29ubmVjdGlvbiBpZD8NCg0KDQpUaGUgdmlj dGltIGhhcyBubyBzdGF0ZSBhYm91dCB0aGUgY29ubmVjdGlvbiBhbmQgcHJvYmFibHkgY2FuJ3Qg c2VuZCBhbiBhdXRoZW50aWNhdGVkIHB1YmxpYyByZXNldC4gRG9lcyB0aGlzIG1lYW4gdGhhdCBw dWJsaWMgcmVzZXRzIHNob3VsZG4ndCBiZSBhdXRoZW50aWNhdGVkPw0KDQpSb2xhbmQNCg0KDQoN CkFtIDExLjA1LjIwMTcgdW0gMTk6NTUgc2NocmllYiBMdWJhc2hldiwgSWdvcjoNClNvIHRoaXMg YXR0YWNrIHN1cHBvc2VzIHRoYXQgYW4gYXR0YWNrZXIgaGFzIGVzdGFibGlzaGVkIGEgUVVJQyBj b25uZWN0aW9uIGFuZCBpcyB1c2luZyB0aGF0IGNvbm5lY3Rpb27igJlzIGNyeXB0b2dyYXBoaWMg bWF0ZXJpYWwgZm9yIGEgcmVmbGVjdGlvbiBhdHRhY2sgb24gYSB2aWN0aW0uICBIb3dldmVyLCB3 b3VsZCBub3QgdGhlIHZpY3RpbSBzaW1wbHkgcmVwbHkgd2l0aCBhIFB1YmxpYyBSZXNldCAob3Ig SUNNUCBwb3J0IHVucmVhY2hhYmxlKSwgYW5kIHRoYXQgd291bGQga2lsbCB0aGlzIFFVSUMgY29u bmVjdGlvbj8gIEluIHRoZSBlbmQsIHRoZSBhdHRhY2tlciB3b3VsZCBoYWQgZG9uZSBhIGxvdCBv ZiB3b3JrIGVzdGFibGlzaGluZyB0aGUgY29ubmVjdGlvbiBqdXN0IHRvIGdldCBhIHNpbmdsZSBy ZWZsZWN0ZWQgUVVJQyBwYWNrZXQgdG8gdGhlIHZpY3RpbS4NCg0KDQotICAgICAgICAgIElnb3IN Cg0KRnJvbTogQmVuamFtaW4gS2FkdWsgW21haWx0bzpia2FkdWtAYWthbWFpLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBNYXkgMTEsIDIwMTcgMTI6NTIgUE0NClRvOiBKxIFuaXMgxIxvZGVycyA8amFu aXMuY29kZXJzQGdtYWlsLmNvbT48bWFpbHRvOmphbmlzLmNvZGVyc0BnbWFpbC5jb20+OyBxdWlj QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEFtcGxpZmljYXRp b24gYXR0YWNrIHVzaW5nIHRoZSBzYW1lIGNvbm5lY3Rpb24gaWQ/DQoNCk9uIDA1LzExLzIwMTcg MTE6NDIgQU0sIEJlbmphbWluIEthZHVrIHdyb3RlOg0KDQoNCk9uIDA1LzExLzIwMTcgMDY6NTcg QU0sIErEgW5pcyDEjG9kZXJzIHdyb3RlOg0KDQoNCg0KSGksIGRvZXNuJ3QgdGhlICJmcmVlIHRv IGNoYW5nZSBzb3VyY2UtaXAgYW5kIHBvcnQiIGZlYXR1cmUgbWFrZQ0KDQpzZXJ2ZXIgdnVsbmVy YWJsZSB0byBhbXBsaWZpY2F0aW9uIGF0dGFja3M/IEltYWdpbmUgdGhhdCB0aGVyZSBpcw0KDQpv bmdvaW5nIHNlc3Npb24gYW5kIGNsaWVudCBzcG9vZnMgc291cmNlIGFkZHJlc3MsIGJ1dCBzZW5k cyB0aGUgc2FtZQ0KDQpjb25uZWN0aW9uLWlkIC0gYW5kIGJlY2F1c2UgaXQga25vd3MgYWxsIHRo ZSBpbnRlcm5hbCBzdGF0ZXMgb2YgUVVJQywNCg0Kc2VydmVyIHNob3VsZCBhY2NlcHQgYW5kIHJl c3BvbmQgdG8gdGhlICJuZXcgc3Bvb2ZlZCIgYWRkcmVzcyAob2YNCg0KY291cnNlIGl0IHNob3Vs ZCBiZSBpbiBhIHN0YXRlIHdoZXJlIHNlcnZlcidzIHJlc3BvbnNlIGlzIGJpZ2dlciB0aGFuDQoN CnJlcXVlc3QpLg0KDQpOT1RFIHRoYXQgSSBhbSB0YWxraW5nIGFib3V0IHN0YXRlIGFmdGVyIHRo ZSBDbGllbnRJbml0aWFsIGhhcyBiZWVuIHZlcmlmaWVkLg0KDQpBcmUgbXkgYXNzdW1wdGlvbnMg Y29ycmVjdD8gSWYgeWVzLCB0aGVuIGhvdyBjb3VsZCB0aGlzIGJlIHByZXZlbnRlZD8NCg0KTWF5 YmUgYnkgcmUtdmVyaWZ5aW5nIHRoYXQgY2xpZW50IHJlYWxseSBjaGFuZ2VkIElQL3BvcnQsIGJ1 dCBtYXliZQ0KDQplYXNpZXIgd291bGQgYmUgYWxsb3dpbmcgdG8gc3dpdGNoIElQL3BvcnQgb25s eSBldmVyeSBYIHNlY29uZHMuDQoNCg0KDQpJZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSBkb2VzIG5v dCBjcnlwdG9ncmFwaGljYWxseSB2ZXJpZnkgYXMgYmVpbmcgc2VudCBieSB0aGUgcGVlciwgaXQg aXMgZHJvcHBlZCBhbmQgbm8gcmVwbHkgaXMgc2VudC4NCg0KUmVyZWFkaW5nIHlvdXIgbWVzc2Fn ZSBtb3JlIGNhcmVmdWxseSwgbWF5YmUgdGhlICJpbnRlcm5hbCBzdGF0ZXMgb2YgUVVJQyIgaXMg c3VwcG9zZWQgdG8gaW5jbHVkZSB0aGUgcmVsZXZhbnQgY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbD8N Cg0KU29tZSByYXRlIGxpbWl0aW5nIG9mIHN3aXRjaGluZyAobWF5YmUgc2xpZ2h0bHkgY2xldmVy IHRvIGFsbG93IG11bHRpcGF0aCBvciBzaW1pbGFyIHNjaGVtZXMgd2hlcmUgYSBzbWFsbCBzZXQg b2Ygcm91dGVzIGlzIHVzZWQgaW50ZXJjaGFuZ2VhYmx5KSBpcyBwcm9iYWJseSBhZHZpc2FibGUg Zm9yIGltcGxlbWVudGF0aW9ucy4NCg0KLUJlbg0KDQo= --_000_ef1de6f866a040d9af815d362c8eb735usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDozMTE1MTAzNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTE4NjE5ODcyMiAxMjIxMzM4NDQyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTY7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjEzNjM3NDk1Mjk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi03NzAzODc5NDQgNzUyNTQ2OTA2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTY7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9 IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGVyZSBhcmUgbGVnaXRpbWF0ZSByZWFzb25zIHdoeSBh biBlbmRwb2ludCBsb3NlcyBzdGF0ZSAoYXBwIHJlc3RhcnQsIGZvciBleGFtcGxlKS4mbmJzcDsg VGhlIGVuZHBvaW50IHcvbyBzdGF0ZSBuZWVkcyB0byBiZSBhYmxlIHRvIHRlbGwgdGhlIG90aGVy IHNpZGUgb2YgdGhlDQogY29ubmVjdGlvbiB0aGF0IGl0IGNhbm5vdCBjb250aW51ZSBhbmQgbXVz dCByZXNldC4mbmJzcDsgVGhlIG9ubHkgcHJvb2YgdGhlIGVuZHBvaW50IHcvbyBzdGF0ZSBjYW4g b2ZmZXIgaXMgdGhhdCBpdCByZWNlaXZlZCBhIHBhY2tldCB0byB3aGljaCBpdCBpcyByZXBseWlu ZyBieSBpbmNsdWRpbmcgZGF0YSBkZXJpdmVkIGZyb20gdGhlIGNvbnRlbnRzIG9mIHRoYXQgcGFj a2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5JZ29y PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9sYW5kIFppbmsgW21haWx0bzpyb2xhbmRAemlua3Mu ZGVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAxMSwgMjAxNyAzOjAxIFBNPGJy Pg0KPGI+VG86PC9iPiBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBbXBs aWZpY2F0aW9uIGF0dGFjayB1c2luZyB0aGUgc2FtZSBjb25uZWN0aW9uIGlkPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwPlRoZSB2aWN0aW0gaGFzIG5vIHN0YXRlIGFib3V0IHRoZSBjb25u ZWN0aW9uIGFuZCBwcm9iYWJseSBjYW4ndCBzZW5kIGFuIGF1dGhlbnRpY2F0ZWQgcHVibGljIHJl c2V0LiBEb2VzIHRoaXMgbWVhbiB0aGF0IHB1YmxpYyByZXNldHMgc2hvdWxkbid0IGJlIGF1dGhl bnRpY2F0ZWQ/PG86cD48L286cD48L3A+DQo8cD5Sb2xhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMTEuMDUuMjAxNyB1bSAxOTo1 NSBzY2hyaWViIEx1YmFzaGV2LCBJZ29yOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5TbyB0aGlz IGF0dGFjayBzdXBwb3NlcyB0aGF0IGFuIGF0dGFja2VyIGhhcyBlc3RhYmxpc2hlZCBhIFFVSUMg Y29ubmVjdGlvbiBhbmQgaXMgdXNpbmcgdGhhdCBjb25uZWN0aW9u4oCZcyBjcnlwdG9ncmFwaGlj IG1hdGVyaWFsIGZvciBhIHJlZmxlY3Rpb24gYXR0YWNrIG9uDQogYSB2aWN0aW0uJm5ic3A7IEhv d2V2ZXIsIHdvdWxkIG5vdCB0aGUgdmljdGltIHNpbXBseSByZXBseSB3aXRoIGEgUHVibGljIFJl c2V0IChvciBJQ01QIHBvcnQgdW5yZWFjaGFibGUpLCBhbmQgdGhhdCB3b3VsZCBraWxsIHRoaXMg UVVJQyBjb25uZWN0aW9uPyZuYnNwOyBJbiB0aGUgZW5kLCB0aGUgYXR0YWNrZXIgd291bGQgaGFk IGRvbmUgYSBsb3Qgb2Ygd29yayBlc3RhYmxpc2hpbmcgdGhlIGNvbm5lY3Rpb24ganVzdCB0byBn ZXQgYSBzaW5nbGUgcmVmbGVjdGVkDQogUVVJQyBwYWNrZXQgdG8gdGhlIHZpY3RpbS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQmVuamFtaW4gS2FkdWsgWzxhIGhy ZWY9Im1haWx0bzpia2FkdWtAYWthbWFpLmNvbSI+bWFpbHRvOmJrYWR1a0Bha2FtYWkuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDExLCAyMDE3IDEyOjUyIFBNPGJy Pg0KPGI+VG86PC9iPiBKxIFuaXMgxIxvZGVycyA8YSBocmVmPSJtYWlsdG86amFuaXMuY29kZXJz QGdtYWlsLmNvbSI+Jmx0O2phbmlzLmNvZGVyc0BnbWFpbC5jb20mZ3Q7PC9hPjsNCjxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogQW1wbGlmaWNhdGlvbiBhdHRhY2sgdXNpbmcgdGhlIHNhbWUgY29ubmVjdGlvbiBp ZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNS8x MS8yMDE3IDExOjQyIEFNLCBCZW5qYW1pbiBLYWR1ayB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDUvMTEvMjAxNyAwNjo1 NyBBTSwgSsSBbmlzIMSMb2RlcnMgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwcmU+SGksIGRvZXNuJ3QgdGhlICZxdW90O2ZyZWUgdG8gY2hhbmdlIHNvdXJjZS1p cCBhbmQgcG9ydCZxdW90OyBmZWF0dXJlIG1ha2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZXJ2 ZXIgdnVsbmVyYWJsZSB0byBhbXBsaWZpY2F0aW9uIGF0dGFja3M/IEltYWdpbmUgdGhhdCB0aGVy ZSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9uZ29pbmcgc2Vzc2lvbiBhbmQgY2xpZW50IHNw b29mcyBzb3VyY2UgYWRkcmVzcywgYnV0IHNlbmRzIHRoZSBzYW1lPG86cD48L286cD48L3ByZT4N CjxwcmU+Y29ubmVjdGlvbi1pZCAtIGFuZCBiZWNhdXNlIGl0IGtub3dzIGFsbCB0aGUgaW50ZXJu YWwgc3RhdGVzIG9mIFFVSUMsPG86cD48L286cD48L3ByZT4NCjxwcmU+c2VydmVyIHNob3VsZCBh Y2NlcHQgYW5kIHJlc3BvbmQgdG8gdGhlICZxdW90O25ldyBzcG9vZmVkJnF1b3Q7IGFkZHJlc3Mg KG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Y291cnNlIGl0IHNob3VsZCBiZSBpbiBhIHN0YXRl IHdoZXJlIHNlcnZlcidzIHJlc3BvbnNlIGlzIGJpZ2dlciB0aGFuPG86cD48L286cD48L3ByZT4N CjxwcmU+cmVxdWVzdCkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Tk9URSB0aGF0IEkgYW0gdGFs a2luZyBhYm91dCBzdGF0ZSBhZnRlciB0aGUgQ2xpZW50SW5pdGlhbCBoYXMgYmVlbiB2ZXJpZmll ZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcmUgbXkgYXNzdW1wdGlvbnMgY29ycmVjdD8gSWYg eWVzLCB0aGVuIGhvdyBjb3VsZCB0aGlzIGJlIHByZXZlbnRlZD88bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5NYXliZSBieSByZS12ZXJpZnlpbmcgdGhhdCBjbGllbnQgcmVhbGx5IGNoYW5nZWQgSVAv cG9ydCwgYnV0IG1heWJlPG86cD48L286cD48L3ByZT4NCjxwcmU+ZWFzaWVyIHdvdWxkIGJlIGFs bG93aW5nIHRvIHN3aXRjaCBJUC9wb3J0IG9ubHkgZXZlcnkgWCBzZWNvbmRzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJZiB0aGUgcmVjZWl2ZWQgbWVzc2FnZSBkb2VzIG5vdCBj cnlwdG9ncmFwaGljYWxseSB2ZXJpZnkgYXMgYmVpbmcgc2VudCBieSB0aGUgcGVlciwgaXQgaXMg ZHJvcHBlZCBhbmQgbm8gcmVwbHkgaXMgc2VudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJlcmVhZGluZyB5b3VyIG1lc3NhZ2UgbW9y ZSBjYXJlZnVsbHksIG1heWJlIHRoZSAmcXVvdDtpbnRlcm5hbCBzdGF0ZXMgb2YgUVVJQyZxdW90 OyBpcyBzdXBwb3NlZCB0byBpbmNsdWRlIHRoZSByZWxldmFudCBjcnlwdG9ncmFwaGljIG1hdGVy aWFsPzxicj4NCjxicj4NClNvbWUgcmF0ZSBsaW1pdGluZyBvZiBzd2l0Y2hpbmcgKG1heWJlIHNs aWdodGx5IGNsZXZlciB0byBhbGxvdyBtdWx0aXBhdGggb3Igc2ltaWxhciBzY2hlbWVzIHdoZXJl IGEgc21hbGwgc2V0IG9mIHJvdXRlcyBpcyB1c2VkIGludGVyY2hhbmdlYWJseSkgaXMgcHJvYmFi bHkgYWR2aXNhYmxlIGZvciBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KPGJyPg0KLUJlbjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ef1de6f866a040d9af815d362c8eb735usma1exdag1mb5msgcorpak_-- From nobody Thu May 11 12:27:02 2017 Return-Path: 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 510C01314A4 for ; Thu, 11 May 2017 12:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 SAIuQphsqDiu for ; Thu, 11 May 2017 12:26:58 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E9E6E1314CA for ; Thu, 11 May 2017 12:21:11 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4BJIpBK026536; Thu, 11 May 2017 20:21:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ROOms14dwm+zWgtSwRU5JY6dgEWLYxDdPBCQ13cVnLE=; b=cpsiZQ+OluBfEUIs1mE+D3Q5GjwoLcGHda4tF/dbUSde2OI1NggaA/mVNuH9S8/i4mWK +wfkV7yd57Q9yxR5tketP9YCfcuKH+/0AyO1hEoGDh4hWA485SoT2ETu0rXbEr77e5Aj 595CvgeRIipK4gRdq9+DtixQe2KvXYD+ts2e5qjTjZAUdNlUQwMKjHI3VU9nvbtMZshG xXMMd8kkPR16Yro/DKi0jJqsb8MKfP/P1V2/eqyCQUdpC2Yu/D0a6ypEGilDAcpnTNkP ar9/JojQNSUSyl7AZanyR2KV0H0+4xNGqXToWjkLqvIzaem3ImS1F8O+fP7qSgYg1D/U yQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2acux80ry0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 20:21:09 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4BJGewE008267; Thu, 11 May 2017 15:21:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a99tutcc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 May 2017 15:21:08 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 May 2017 15:21:08 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 11 May 2017 15:21:08 -0400 From: "Lubashev, Igor" To: "Kaduk, Ben" , =?utf-8?B?SsSBbmlzIMSMb2RlcnM=?= , "quic@ietf.org" Subject: RE: Amplification attack using the same connection id? Thread-Topic: Amplification attack using the same connection id? Thread-Index: AQHSynTxuyuEZN72KUe2JZ4J3A/+iKHvmS2AgAAC5gD//8mdcIAAWeWA///CMmA= Date: Thu, 11 May 2017 19:21:08 +0000 Message-ID: <56b889ba6e4142a6b3034d3bd3a1455d@usma1ex-dag1mb5.msg.corp.akamai.com> References: <2a740401-8fb8-4b8a-a8d8-9fe89971f99c@akamai.com> <0be35d73b1044e20b68018db3470760e@usma1ex-dag1mb5.msg.corp.akamai.com> <6d800009-feff-afd2-6a9d-f936f2cfba9b@akamai.com> In-Reply-To: <6d800009-feff-afd2-6a9d-f936f2cfba9b@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.230] Content-Type: multipart/alternative; boundary="_000_56b889ba6e4142a6b3034d3bd3a1455dusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110101 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705110102 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 19:27:00 -0000 --_000_56b889ba6e4142a6b3034d3bd3a1455dusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGFyZSByaWdodC4gIEtpbGxpbmcgdGhlIHBhdGggaXMgdGhlIHByb3BlciB3YXkgb2Ygc3Rh dGluZyB0aGlzLg0KDQpNYXliZSBJIG5lZWQgdG8gY2F0Y2ggdXAsIGJ1dCBJIHdvdWxkIHRoaW5r IHRoYXQgZXN0YWJsaXNoaW5nIGFuIGFkZGl0aW9uYWwgcGF0aCAoYXMgaW4gbXVsdGktcGF0aCkg aXMgYWxzbyBhIG5vbi10cml2aWFsIHByb2Nlc3MgYW5kIHdvdWxkIHJlcXVpcmUgd29yayBvbiB0 aGUgcGF0aCBvZiB0aGUgYXR0YWNrZXIgdG8gZXN0YWJsaXNoIGEgbmV3IHBhdGgsIOKAnG1pZ3Jh dGUgaXTigJ0gYW5kIGhhdmUgaXQga2lsbGVkLg0KDQoNCi0gICAgICAgICAgSWdvcg0KDQoNCkZy b206IEJlbmphbWluIEthZHVrIFttYWlsdG86YmthZHVrQGFrYW1haS5jb21dDQpTZW50OiBUaHVy c2RheSwgTWF5IDExLCAyMDE3IDM6MDAgUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVA YWthbWFpLmNvbT47IErEgW5pcyDEjG9kZXJzIDxqYW5pcy5jb2RlcnNAZ21haWwuY29tPjsgcXVp Y0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEFtcGxpZmljYXRpb24gYXR0YWNrIHVzaW5nIHRoZSBz YW1lIGNvbm5lY3Rpb24gaWQ/DQoNCldvdWxkIElDTVAgcG9ydCB1bnJlYWNoYWJsZSBraWxsIHRo ZSBlbnRpcmUgY29ubmVjdGlvbj8gIEkgdGhvdWdodCB3ZSB3ZXJlIGxlYW5pbmcgdG93YXJkcyB0 cmVhdGluZyB0aGF0IGFzIGp1c3QgYSBwYXRoIHNpZ25hbC4NCg0KLUJlbg0KT24gMDUvMTEvMjAx NyAxMjo1NSBQTSwgTHViYXNoZXYsIElnb3Igd3JvdGU6DQpTbyB0aGlzIGF0dGFjayBzdXBwb3Nl cyB0aGF0IGFuIGF0dGFja2VyIGhhcyBlc3RhYmxpc2hlZCBhIFFVSUMgY29ubmVjdGlvbiBhbmQg aXMgdXNpbmcgdGhhdCBjb25uZWN0aW9u4oCZcyBjcnlwdG9ncmFwaGljIG1hdGVyaWFsIGZvciBh IHJlZmxlY3Rpb24gYXR0YWNrIG9uIGEgdmljdGltLiAgSG93ZXZlciwgd291bGQgbm90IHRoZSB2 aWN0aW0gc2ltcGx5IHJlcGx5IHdpdGggYSBQdWJsaWMgUmVzZXQgKG9yIElDTVAgcG9ydCB1bnJl YWNoYWJsZSksIGFuZCB0aGF0IHdvdWxkIGtpbGwgdGhpcyBRVUlDIGNvbm5lY3Rpb24/ICBJbiB0 aGUgZW5kLCB0aGUgYXR0YWNrZXIgd291bGQgaGFkIGRvbmUgYSBsb3Qgb2Ygd29yayBlc3RhYmxp c2hpbmcgdGhlIGNvbm5lY3Rpb24ganVzdCB0byBnZXQgYSBzaW5nbGUgcmVmbGVjdGVkIFFVSUMg cGFja2V0IHRvIHRoZSB2aWN0aW0uDQoNCg0KLSAgICAgICAgICBJZ29yDQoNCkZyb206IEJlbmph bWluIEthZHVrIFttYWlsdG86YmthZHVrQGFrYW1haS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5 IDExLCAyMDE3IDEyOjUyIFBNDQpUbzogSsSBbmlzIMSMb2RlcnMgPGphbmlzLmNvZGVyc0BnbWFp bC5jb20+PG1haWx0bzpqYW5pcy5jb2RlcnNAZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZzxtYWls dG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBBbXBsaWZpY2F0aW9uIGF0dGFjayB1c2lu ZyB0aGUgc2FtZSBjb25uZWN0aW9uIGlkPw0KDQpPbiAwNS8xMS8yMDE3IDExOjQyIEFNLCBCZW5q YW1pbiBLYWR1ayB3cm90ZToNCg0KDQpPbiAwNS8xMS8yMDE3IDA2OjU3IEFNLCBKxIFuaXMgxIxv ZGVycyB3cm90ZToNCg0KDQoNCkhpLCBkb2Vzbid0IHRoZSAiZnJlZSB0byBjaGFuZ2Ugc291cmNl LWlwIGFuZCBwb3J0IiBmZWF0dXJlIG1ha2UNCg0Kc2VydmVyIHZ1bG5lcmFibGUgdG8gYW1wbGlm aWNhdGlvbiBhdHRhY2tzPyBJbWFnaW5lIHRoYXQgdGhlcmUgaXMNCg0Kb25nb2luZyBzZXNzaW9u IGFuZCBjbGllbnQgc3Bvb2ZzIHNvdXJjZSBhZGRyZXNzLCBidXQgc2VuZHMgdGhlIHNhbWUNCg0K Y29ubmVjdGlvbi1pZCAtIGFuZCBiZWNhdXNlIGl0IGtub3dzIGFsbCB0aGUgaW50ZXJuYWwgc3Rh dGVzIG9mIFFVSUMsDQoNCnNlcnZlciBzaG91bGQgYWNjZXB0IGFuZCByZXNwb25kIHRvIHRoZSAi bmV3IHNwb29mZWQiIGFkZHJlc3MgKG9mDQoNCmNvdXJzZSBpdCBzaG91bGQgYmUgaW4gYSBzdGF0 ZSB3aGVyZSBzZXJ2ZXIncyByZXNwb25zZSBpcyBiaWdnZXIgdGhhbg0KDQpyZXF1ZXN0KS4NCg0K Tk9URSB0aGF0IEkgYW0gdGFsa2luZyBhYm91dCBzdGF0ZSBhZnRlciB0aGUgQ2xpZW50SW5pdGlh bCBoYXMgYmVlbiB2ZXJpZmllZC4NCg0KQXJlIG15IGFzc3VtcHRpb25zIGNvcnJlY3Q/IElmIHll cywgdGhlbiBob3cgY291bGQgdGhpcyBiZSBwcmV2ZW50ZWQ/DQoNCk1heWJlIGJ5IHJlLXZlcmlm eWluZyB0aGF0IGNsaWVudCByZWFsbHkgY2hhbmdlZCBJUC9wb3J0LCBidXQgbWF5YmUNCg0KZWFz aWVyIHdvdWxkIGJlIGFsbG93aW5nIHRvIHN3aXRjaCBJUC9wb3J0IG9ubHkgZXZlcnkgWCBzZWNv bmRzLg0KDQoNCg0KSWYgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgZG9lcyBub3QgY3J5cHRvZ3JhcGhp Y2FsbHkgdmVyaWZ5IGFzIGJlaW5nIHNlbnQgYnkgdGhlIHBlZXIsIGl0IGlzIGRyb3BwZWQgYW5k IG5vIHJlcGx5IGlzIHNlbnQuDQoNClJlcmVhZGluZyB5b3VyIG1lc3NhZ2UgbW9yZSBjYXJlZnVs bHksIG1heWJlIHRoZSAiaW50ZXJuYWwgc3RhdGVzIG9mIFFVSUMiIGlzIHN1cHBvc2VkIHRvIGlu Y2x1ZGUgdGhlIHJlbGV2YW50IGNyeXB0b2dyYXBoaWMgbWF0ZXJpYWw/DQoNClNvbWUgcmF0ZSBs aW1pdGluZyBvZiBzd2l0Y2hpbmcgKG1heWJlIHNsaWdodGx5IGNsZXZlciB0byBhbGxvdyBtdWx0 aXBhdGggb3Igc2ltaWxhciBzY2hlbWVzIHdoZXJlIGEgc21hbGwgc2V0IG9mIHJvdXRlcyBpcyB1 c2VkIGludGVyY2hhbmdlYWJseSkgaXMgcHJvYmFibHkgYWR2aXNhYmxlIGZvciBpbXBsZW1lbnRh dGlvbnMuDQoNCi1CZW4NCg0K --_000_56b889ba6e4142a6b3034d3bd3a1455dusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzExNTEwMzc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODYxOTg3MjIgMTIyMTMzODQ0MiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjE2 Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTc5NzUyODIzOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjM3ODYwNDggLTEwMDE4Njk5NzAg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDox NjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPllv dSBhcmUgcmlnaHQuJm5ic3A7IEtpbGxpbmcgdGhlIHBhdGggaXMgdGhlIHByb3BlciB3YXkgb2Yg c3RhdGluZyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+TWF5YmUgSSBuZWVkIHRvIGNhdGNoIHVwLCBidXQgSSB3b3VsZCB0aGluayB0aGF0IGVz dGFibGlzaGluZyBhbiBhZGRpdGlvbmFsIHBhdGggKGFzIGluIG11bHRpLXBhdGgpIGlzIGFsc28g YSBub24tdHJpdmlhbCBwcm9jZXNzIGFuZCB3b3VsZCByZXF1aXJlIHdvcmsgb24NCiB0aGUgcGF0 aCBvZiB0aGUgYXR0YWNrZXIgdG8gZXN0YWJsaXNoIGEgbmV3IHBhdGgsIOKAnG1pZ3JhdGUgaXTi gJ0gYW5kIGhhdmUgaXQga2lsbGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5JZ29yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+IEJlbmphbWluIEthZHVrIFttYWlsdG86YmthZHVrQGFrYW1haS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAxMSwgMjAxNyAzOjAwIFBNPGJyPg0KPGI+ VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IErEgW5p cyDEjG9kZXJzICZsdDtqYW5pcy5jb2RlcnNAZ21haWwuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQW1wbGlmaWNhdGlvbiBhdHRhY2sgdXNpbmcgdGhlIHNh bWUgY29ubmVjdGlvbiBpZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+V291bGQgSUNNUCBwb3J0IHVucmVhY2hhYmxlIGtpbGwgdGhlIGVudGly ZSBjb25uZWN0aW9uPyZuYnNwOyBJIHRob3VnaHQgd2Ugd2VyZSBsZWFuaW5nIHRvd2FyZHMgdHJl YXRpbmcgdGhhdCBhcyBqdXN0IGEgcGF0aCBzaWduYWwuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjxicj4NCjx0dD4tQmVuPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMDUvMTEvMjAxNyAxMjo1NSBQTSwgTHViYXNoZXYsIElnb3Ig d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlNvIHRoaXMgYXR0YWNrIHN1cHBvc2VzIHRo YXQgYW4gYXR0YWNrZXIgaGFzIGVzdGFibGlzaGVkIGEgUVVJQyBjb25uZWN0aW9uIGFuZCBpcyB1 c2luZyB0aGF0IGNvbm5lY3Rpb27igJlzIGNyeXB0b2dyYXBoaWMgbWF0ZXJpYWwgZm9yIGEgcmVm bGVjdGlvbiBhdHRhY2sgb24NCiBhIHZpY3RpbS4mbmJzcDsgSG93ZXZlciwgd291bGQgbm90IHRo ZSB2aWN0aW0gc2ltcGx5IHJlcGx5IHdpdGggYSBQdWJsaWMgUmVzZXQgKG9yIElDTVAgcG9ydCB1 bnJlYWNoYWJsZSksIGFuZCB0aGF0IHdvdWxkIGtpbGwgdGhpcyBRVUlDIGNvbm5lY3Rpb24/Jm5i c3A7IEluIHRoZSBlbmQsIHRoZSBhdHRhY2tlciB3b3VsZCBoYWQgZG9uZSBhIGxvdCBvZiB3b3Jr IGVzdGFibGlzaGluZyB0aGUgY29ubmVjdGlvbiBqdXN0IHRvIGdldCBhIHNpbmdsZSByZWZsZWN0 ZWQNCiBRVUlDIHBhY2tldCB0byB0aGUgdmljdGltLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPklnb3I8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBCZW5qYW1pbiBLYWR1ayBbPGEgaHJlZj0ibWFpbHRvOmJrYWR1a0Bh a2FtYWkuY29tIj5tYWlsdG86YmthZHVrQGFrYW1haS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBNYXkgMTEsIDIwMTcgMTI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IErEgW5p cyDEjG9kZXJzIDxhIGhyZWY9Im1haWx0bzpqYW5pcy5jb2RlcnNAZ21haWwuY29tIj4mbHQ7amFu aXMuY29kZXJzQGdtYWlsLmNvbSZndDs8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5v cmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBbXBsaWZpY2F0 aW9uIGF0dGFjayB1c2luZyB0aGUgc2FtZSBjb25uZWN0aW9uIGlkPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA1LzExLzIwMTcgMTE6NDIgQU0sIEJl bmphbWluIEthZHVrIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNS8xMS8yMDE3IDA2OjU3IEFNLCBKxIFuaXMgxIxvZGVy cyB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaSwgZG9l c24ndCB0aGUgJnF1b3Q7ZnJlZSB0byBjaGFuZ2Ugc291cmNlLWlwIGFuZCBwb3J0JnF1b3Q7IGZl YXR1cmUgbWFrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZlciB2dWxuZXJhYmxlIHRvIGFt cGxpZmljYXRpb24gYXR0YWNrcz8gSW1hZ2luZSB0aGF0IHRoZXJlIGlzPG86cD48L286cD48L3By ZT4NCjxwcmU+b25nb2luZyBzZXNzaW9uIGFuZCBjbGllbnQgc3Bvb2ZzIHNvdXJjZSBhZGRyZXNz LCBidXQgc2VuZHMgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb25uZWN0aW9uLWlk IC0gYW5kIGJlY2F1c2UgaXQga25vd3MgYWxsIHRoZSBpbnRlcm5hbCBzdGF0ZXMgb2YgUVVJQyw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZXJ2ZXIgc2hvdWxkIGFjY2VwdCBhbmQgcmVzcG9uZCB0 byB0aGUgJnF1b3Q7bmV3IHNwb29mZWQmcXVvdDsgYWRkcmVzcyAob2Y8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5jb3Vyc2UgaXQgc2hvdWxkIGJlIGluIGEgc3RhdGUgd2hlcmUgc2VydmVyJ3MgcmVz cG9uc2UgaXMgYmlnZ2VyIHRoYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1ZXN0KS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5OT1RFIHRoYXQgSSBhbSB0YWxraW5nIGFib3V0IHN0YXRlIGFm dGVyIHRoZSBDbGllbnRJbml0aWFsIGhhcyBiZWVuIHZlcmlmaWVkLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPkFyZSBteSBhc3N1bXB0aW9ucyBjb3JyZWN0PyBJZiB5ZXMsIHRoZW4gaG93IGNvdWxk IHRoaXMgYmUgcHJldmVudGVkPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1heWJlIGJ5IHJlLXZl cmlmeWluZyB0aGF0IGNsaWVudCByZWFsbHkgY2hhbmdlZCBJUC9wb3J0LCBidXQgbWF5YmU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5lYXNpZXIgd291bGQgYmUgYWxsb3dpbmcgdG8gc3dpdGNoIElQ L3BvcnQgb25seSBldmVyeSBYIHNlY29uZHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCklmIHRoZSByZWNlaXZlZCBtZXNzYWdlIGRvZXMgbm90IGNyeXB0b2dyYXBoaWNhbGx5IHZl cmlmeSBhcyBiZWluZyBzZW50IGJ5IHRoZSBwZWVyLCBpdCBpcyBkcm9wcGVkIGFuZCBubyByZXBs eSBpcyBzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KUmVyZWFkaW5nIHlvdXIgbWVzc2FnZSBtb3JlIGNhcmVmdWxseSwgbWF5YmUg dGhlICZxdW90O2ludGVybmFsIHN0YXRlcyBvZiBRVUlDJnF1b3Q7IGlzIHN1cHBvc2VkIHRvIGlu Y2x1ZGUgdGhlIHJlbGV2YW50IGNyeXB0b2dyYXBoaWMgbWF0ZXJpYWw/PGJyPg0KPGJyPg0KU29t ZSByYXRlIGxpbWl0aW5nIG9mIHN3aXRjaGluZyAobWF5YmUgc2xpZ2h0bHkgY2xldmVyIHRvIGFs bG93IG11bHRpcGF0aCBvciBzaW1pbGFyIHNjaGVtZXMgd2hlcmUgYSBzbWFsbCBzZXQgb2Ygcm91 dGVzIGlzIHVzZWQgaW50ZXJjaGFuZ2VhYmx5KSBpcyBwcm9iYWJseSBhZHZpc2FibGUgZm9yIGlt cGxlbWVudGF0aW9ucy48YnI+DQo8YnI+DQotQmVuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_56b889ba6e4142a6b3034d3bd3a1455dusma1exdag1mb5msgcorpak_-- From nobody Thu May 11 17:44:56 2017 Return-Path: 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 D6800126FB3 for ; Thu, 11 May 2017 17:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0f6bua0qd3ZZ for ; Thu, 11 May 2017 17:44:53 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F3712E039 for ; Thu, 11 May 2017 17:40:21 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 142so54745567wma.1 for ; Thu, 11 May 2017 17:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QROTQ5NtmZ7hK4wiC/sytGW/B4gQi+wAln5NtBJAe/c=; b=PcXgkkzY5i4SpUQULuLjUOFG74inw9n039Qe8S8rXYBC5dY7Jk2lij6zwafJTzxv7J DG0KXUBU77/QEpH6JFPbWXru67JctieA0k8SOKAv5Yxzxs+YDNc6JTsB9fFqTySlpzoo QkHj0vxSh20bi5THirRS+6h43w92hHbG45Em3HbJClu/4WagEd3NOnUcyga1E2zXTw3a PSZvBXI7pLxVntW69Xp45EthpWm4MFmbUAtv3u+Dts6EDbtcfXn4OoFZHRtGUSeLA4AR nUzkEPRC79et93KBTFBus+1ApwfwgRaNIMGPn0/x4tUaiBF1nrFiyboX1QPj95On6L5T +fmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QROTQ5NtmZ7hK4wiC/sytGW/B4gQi+wAln5NtBJAe/c=; b=S+R6sckPklr4mrDZC82MMbS+vxXohNSvDbe6QDc/cOUqIt3FGtpuRB3LUiI4WZovgS L1xfS+RKrpt4eNqYkJsMxHGJxnGECBRMPoim7jQhdfHTAvQE+kABuBr+IvkbAbGtHKL6 lT3GyQhlOUJiuqpSFlVmaOwdtI8PQZ4ZDp6OPKESngF76kjGC+a4kHtsStp93lv6xz4d nv27U2rUGtRaw64Uw+h6d0X1AUur9sAfJxrigjdhVsVjwC8qNVxNxEQ9fJMZohWY/5pS /fleTO/yL5gM0Id062bS4n7f2Ycxu5sA6n72yoVpUaN0X8EgVLoxcf+1jl5RYLNTBeE0 mAkg== X-Gm-Message-State: AODbwcBMfUlfzizRXSZzUdi2+jpORuPQI3WEafgLXZuRD7+FDQIv4Cri RxRX7AA1dJjxcuk4t6WVwC5zQtEYbg== X-Received: by 10.25.160.147 with SMTP id j141mr327829lfe.19.1494549620086; Thu, 11 May 2017 17:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 11 May 2017 17:40:19 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 12 May 2017 10:40:19 +1000 Message-ID: Subject: Re: Amplification attack using the same connection id? To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 00:44:55 -0000 On 11 May 2017 at 21:57, J=C4=81nis =C4=8Coders wr= ote: > Hi, doesn't the "free to change source-ip and port" feature make > server vulnerable to amplification attacks? Imagine that there is > ongoing session and client spoofs source address, but sends the same > connection-id - and because it knows all the internal states of QUIC, > server should accept and respond to the "new spoofed" address (of > course it should be in a state where server's response is bigger than > request). FYI, this is an issue we are aware of: https://github.com/quicwg/base-drafts/issues/161 First, the server resets its congestion state when it detects a new path and this is obviously a new path. That isn't sufficient in practice because asymmetric traffic patterns could eventually lead to some severe amplification. Think video downloads for an example. The main fix is that the server needs to verify that the client can receive at this new address before it sends (significantly) more than it receives *on this path*. This is not currently guaranteed, though there is some discussion about using packet number skipping for this in the draft. I'm personally not especially happy about that approach. We've discussed several ideas for this, because it's the important one for handling amplification. A simple example of what has been suggested: the server sends a ping that contains entropy and requires an echo of that ping. From nobody Thu May 11 23:14:56 2017 Return-Path: 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 5759A1289B0 for ; Thu, 11 May 2017 23:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BUKAEr-_NWNR for ; Thu, 11 May 2017 23:14:51 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2B41201F8 for ; Thu, 11 May 2017 23:09:58 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id o5so5295847ith.1 for ; Thu, 11 May 2017 23:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eMEH5D9nZCNiR6cmFIgwFEC7FwbsSi+eF5zrwTxltl0=; b=U0aSJ08LNl2Txtuj96SWaz0YYMaMkfNpqcXDu9EuQWnGv7OZF473cL2WjSeo/xGQ7s vRmsJmeTRaDc4a/NP+hrPBLBlD1VPuUV5GPbCfekgRSZ/BDmtb7Zsr8AM8oYVZDa2VcR zQROBXd8tyndak9O14dxB5GdUIQ+WZc9xWQtAe7D07rRIDkIJNLFpNROmZ9hCxpWhhLY 3X2j0mRudWfIImBfw/D8DdGE326qPdXw0mwufkkfiba/RFYUxyXjWxps4u0UXLYquPxK FEyWO3fW82uj62pMI2X89wVxODDo8e9Cih3mp5W8jCElzjHG57UATj0xipAASgVIF825 fb9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eMEH5D9nZCNiR6cmFIgwFEC7FwbsSi+eF5zrwTxltl0=; b=tMQr8Xrcqhe5o0KmOKFWSX9ktuMbXlOu5NTwbbwmCrc0DIkWxdPZgx9JlT25PoFYcY licNXr7wbLsjYssP+57z4AxfmuGm77X1aWf81vV4X9qYD+NvHwb9OIpIXaF0m5YEeWIb MdtaUgHSMvLJ5yM5yJ+FMVay0yM7RXtPQB+kALOSafvseo/7cXWi1Zy8UlKqei6Rsa8L E2IxwP5RmTW24EzmOj/OVr9Zt2vDKcMpsPSnGFpnrfjv63uhzF/tPdRKD5Njj19vYW6h BqAOdc5o34VD21p+5QCyC1E4/LqjHhqWb638RP/k91gWCD/5S2OGuz9s9Lxg8rPBPPSx SFYA== X-Gm-Message-State: AODbwcDeJv3f98eITXgzO/p8cjJhH79rDCsakRrBrMMNuOZoZNwetYKT GlrkIc8DMrSiVylNMGk0qt0706byXg== X-Received: by 10.36.139.69 with SMTP id g66mr2106220ite.114.1494569397887; Thu, 11 May 2017 23:09:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.7.70 with HTTP; Thu, 11 May 2017 23:09:57 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= Date: Fri, 12 May 2017 09:09:57 +0300 Message-ID: Subject: Re: Amplification attack using the same connection id? To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 06:14:54 -0000 Thanks, so there is already discussion about this. I'll try to follow it, but currently for me a "challenge ping" seems more reasonable solution - clearer intention. On 12 May 2017 at 03:40, Martin Thomson wrote: > On 11 May 2017 at 21:57, J=C4=81nis =C4=8Coders = wrote: >> Hi, doesn't the "free to change source-ip and port" feature make >> server vulnerable to amplification attacks? Imagine that there is >> ongoing session and client spoofs source address, but sends the same >> connection-id - and because it knows all the internal states of QUIC, >> server should accept and respond to the "new spoofed" address (of >> course it should be in a state where server's response is bigger than >> request). > > FYI, this is an issue we are aware of: > https://github.com/quicwg/base-drafts/issues/161 > > First, the server resets its congestion state when it detects a new > path and this is obviously a new path. That isn't sufficient in > practice because asymmetric traffic patterns could eventually lead to > some severe amplification. Think video downloads for an example. > > The main fix is that the server needs to verify that the client can > receive at this new address before it sends (significantly) more than > it receives *on this path*. This is not currently guaranteed, though > there is some discussion about using packet number skipping for this > in the draft. I'm personally not especially happy about that > approach. > > We've discussed several ideas for this, because it's the important one > for handling amplification. A simple example of what has been > suggested: the server sends a ping that contains entropy and requires > an echo of that ping. --=20 Ar cie=C5=86u, J=C4=81nis =C4=8Coders From nobody Sat May 13 11:57:54 2017 Return-Path: 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 01DF112ACAF for ; Sat, 13 May 2017 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 tZIXMoUHF8uC for ; Sat, 13 May 2017 11:57:50 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0203A127863 for ; Sat, 13 May 2017 11:55:12 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id p143so20262594yba.2 for ; Sat, 13 May 2017 11:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AboHTht1uDyXTSQn3tW64ZWyYsScWcVSIxGFpIlUTKY=; b=PqUFR+7DCg9etuwe6KmKCALN6ikfL95gYGdDqr7ys8WOvUC8YIr8gwTr2UHAkffUTn ppV7J9fsVNJh3pK/mcjsTWkcmIV/LO+MFrB4kjC1agQ2qf6bez+7UMIX2OQqT54T3Onr iO8V9xePxGa54dQ3kdkZDiMUjivuRGWrxJN+0dWPLrMpC4J6zyz34mp76ybVUDSDFH+q F8SmaESZsinjP6JDwZlSumcHttI/Pb1I9H6XDGNJRImbjJnIUjhh/zPgn5MaV9hD2w5E bp6i+6gxsFj3q/ortKcJ7/CDnZnwtAAk/dnE/4oURYOzYdk2WhOhMlXMeTiJG9zGvCa0 0UqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AboHTht1uDyXTSQn3tW64ZWyYsScWcVSIxGFpIlUTKY=; b=lmzQovU4vAhAClAkzfCPZZqR2h+f4ZxOKfKgb28RQf1RyyFvT5Wh7rn8imdbYoZpIp T3kfverEaZHhRFP8K1d12mR7/wfo2yYkA0O4bzIUnqhVQKan7JSH7da4Cp8WEpGc0Bek WZJIXdjS3/EnGYrwmYyJkUNXsTDFXU+iWCXZUghyp3wyeMlMwMj8GB2YxzkHHcmv9vAr Ds6xDi4UOspoVCDwBJ1P4IuDDLjHvz+I+Wo02Aiy93F1RD0QNsW+n7bFn06T1wZ5Ks9r gbMchXzjEeLJJPyBniIggqbPYd2J1BlxuHBE4kH/7K9WB00EFaf4dprKerlChkm9ha5o zDpw== X-Gm-Message-State: AODbwcAdK8HkcRl0TKgUY8MBk+VHu4PF8n8uYU3X2lLE72pXiGyAO6gp RnZm80/7Rm33msIQmd8Ao00L7G1GgI6vlKs= X-Received: by 10.37.41.130 with SMTP id p124mr8641963ybp.24.1494701711127; Sat, 13 May 2017 11:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Sat, 13 May 2017 11:54:30 -0700 (PDT) In-Reply-To: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> From: Eric Rescorla Date: Sat, 13 May 2017 11:54:30 -0700 Message-ID: Subject: Re: Getting to a First Implementation Draft To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="94eb2c14d834898b6a054f6c5cd7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 18:57:52 -0000 --94eb2c14d834898b6a054f6c5cd7 Content-Type: text/plain; charset="UTF-8" A few comments on this proposed list: > Integration with TLS 1.3 handshake - The basic 1-RTT mode must be > supported. TLS exporters are not needed, nor are session > tickets. Basic key exchange is sufficient and implementations can > use any certificate. All MTI algorithms listed in TLS 1.3 are > expected. I note that this and the transport parameters and HRR stuff below necessitate the generic changes to the TLS library to permit adding extra extensions. I wonder if it might make life better to just have a canned set of parameters for now. It's not that it's a lot of work, it's just that it's not critical path otherwise. > Packet protection - All post handshake packets must be sent with > 1RTT keys and packet protection. This is inconsistent with not requiring exporters above. As far as I can tell, if you're not doing NST, you don't need post-handshake packets anyway here, so you can probably skip this. On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham wrote: > Previously, we've mentioned an intention to have a First Implementation > Draft -- that is, an Internet-Draft that we feel is suitable for > implementers to write code to, for the purposes of interoperability testing > and gathering feedback -- shortly after the Paris interim. > > Due to the size and complexity of HTTP-over-QUIC, implementing all four > drafts for this purpose on a reasonable timeline isn't workable. > > Instead, the editors have identified a subset of functionality that they > believe will serve as a suitable starting point. See: > https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft > > They've also identified the set of issues that we believe will be > necessary to have proposals for before Paris; see: > https://github.com/quicwg/base-drafts/milestone/1 > > If all goes well, the plan is to have a set of drafts out (very) soon that > do so; then, we can discuss them and the First Implementation Draft > Candidate in the lead-up to and during the Paris interim. > > After Paris, we'll make any necessary adjustments to the documents and > publish another set, which will be the First Implementation Draft. > > Please comment / raise concerns / make suggestions on-list. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c14d834898b6a054f6c5cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few comments on this proposed list:

<= div>> Integration with TLS 1.3 handshake - The basic 1-RTT mode must be<= /div>
> supported. TLS exporters are not needed, nor are session
> tickets. Basic key exchange is sufficient and implementations c= an
> use any certificate. All MTI algorithms listed in TLS 1.3= are
> expected.

I note that this and= the transport parameters and HRR stuff below
necessitate the gen= eric changes to the TLS library to permit adding
extra extensions= . I wonder if it might make life better to just have a
canned set= of parameters for now. It's not that it's a lot of work,
it's just that it's not critical path otherwise.


> Packet protection - All post handshake packets = must be sent with
> 1RTT keys and packet protection.

This is inconsistent with not requiring exporters above. As= far
as I can tell, if you're not doing NST, you don't ne= ed post-handshake
packets anyway here, so you can probably skip t= his.



On Wed, May 10, 2017 at 9:53 PM, Mark No= ttingham <mnot@mnot.net> wrote:
https://github.com/quicw= g/base-drafts/wiki/First-Implementation-Draft

They've also identified the set of issues that we believe will be neces= sary to have proposals for before Paris; see:
=C2=A0 https://github.com/quicwg/base-drafts/m= ilestone/1

If all goes well, the plan is to have a set of drafts out (very) soon that = do so; then, we can discuss them and the First Implementation Draft Candida= te in the lead-up to and during the Paris interim.

After Paris, we'll make any necessary adjustments to the documents and = publish another set, which will be the First Implementation Draft.

Please comment / raise concerns / make suggestions on-list.

Regards,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


--94eb2c14d834898b6a054f6c5cd7-- From nobody Sun May 14 11:14:49 2017 Return-Path: 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 9CAB6129B4F for ; Sun, 14 May 2017 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 YAjA_GNFB7gX for ; Sun, 14 May 2017 11:14:44 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 746E3129B31 for ; Sun, 14 May 2017 11:11:30 -0700 (PDT) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id D363E3A019 for ; Sun, 14 May 2017 14:11:28 -0400 (EDT) Received: by mail-qk0-f182.google.com with SMTP id k74so79384298qke.1 for ; Sun, 14 May 2017 11:11:28 -0700 (PDT) X-Gm-Message-State: AODbwcAcllFuuKvJHI+QhgCqkxg4cpW3oumLBmvueozHPmnuIE37dzDy 0tr/VM5V8G1CoQsqtxBSHjTdqRuQ/Q== X-Received: by 10.55.76.140 with SMTP id z134mr2012878qka.35.1494785488612; Sun, 14 May 2017 11:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.178.74 with HTTP; Sun, 14 May 2017 11:11:28 -0700 (PDT) In-Reply-To: References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> From: Patrick McManus Date: Sun, 14 May 2017 14:11:28 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Getting to a First Implementation Draft To: Eric Rescorla Cc: Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a114a80fc1076d3054f7fdedb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 18:14:48 -0000 --001a114a80fc1076d3054f7fdedb Content-Type: text/plain; charset="UTF-8" I don't really know how I feel about this wiki page.. without ratholing too deeply on it I think that while it tries to facilitate testing and interop, it treads pretty significantly into the land of project management which is squarely out of bounds for the working group. I'm willing to see how it goes but that's my concern - I would rather the WG focuses on the complete picture while providing more of a forum for pair (or more) wise testing. anyhow wrt specifics - ekr points out the 2 major inconsistencies.. tbh I would require exporters and the ability to do at least one non-0 stream. At that point you have a hello world milestone, which is always the first stage worthy of a toast. Its ok by me if the transport params are just profiled. On Sat, May 13, 2017 at 2:54 PM, Eric Rescorla wrote: > A few comments on this proposed list: > > > Integration with TLS 1.3 handshake - The basic 1-RTT mode must be > > supported. TLS exporters are not needed, nor are session > > tickets. Basic key exchange is sufficient and implementations can > > use any certificate. All MTI algorithms listed in TLS 1.3 are > > expected. > > I note that this and the transport parameters and HRR stuff below > necessitate the generic changes to the TLS library to permit adding > extra extensions. I wonder if it might make life better to just have a > canned set of parameters for now. It's not that it's a lot of work, > it's just that it's not critical path otherwise. > > > > Packet protection - All post handshake packets must be sent with > > 1RTT keys and packet protection. > > This is inconsistent with not requiring exporters above. As far > as I can tell, if you're not doing NST, you don't need post-handshake > packets anyway here, so you can probably skip this. > > > > On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham wrote: > >> Previously, we've mentioned an intention to have a First Implementation >> Draft -- that is, an Internet-Draft that we feel is suitable for >> implementers to write code to, for the purposes of interoperability testing >> and gathering feedback -- shortly after the Paris interim. >> >> Due to the size and complexity of HTTP-over-QUIC, implementing all four >> drafts for this purpose on a reasonable timeline isn't workable. >> >> Instead, the editors have identified a subset of functionality that they >> believe will serve as a suitable starting point. See: >> https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft >> >> They've also identified the set of issues that we believe will be >> necessary to have proposals for before Paris; see: >> https://github.com/quicwg/base-drafts/milestone/1 >> >> If all goes well, the plan is to have a set of drafts out (very) soon >> that do so; then, we can discuss them and the First Implementation Draft >> Candidate in the lead-up to and during the Paris interim. >> >> After Paris, we'll make any necessary adjustments to the documents and >> publish another set, which will be the First Implementation Draft. >> >> Please comment / raise concerns / make suggestions on-list. >> >> Regards, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > --001a114a80fc1076d3054f7fdedb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't really know how I feel about this wiki pa= ge.. without ratholing too deeply on it I think that while it tries to faci= litate testing and interop, it treads pretty significantly into the land of= project management which is squarely out of bounds for the working group. = I'm willing to see how it goes but that's my concern - I would rath= er the WG focuses on the complete picture while providing more of a forum f= or pair (or more) wise testing.

anyhow wrt spe= cifics -=C2=A0 ekr points out the 2 major inconsistencies.. tbh I would req= uire exporters and the ability to do at least one non-0 stream. At that poi= nt you have a hello world milestone, which is always the first stage worthy= of a toast. Its ok by me if the transport params are just profiled.

On Sat, = May 13, 2017 at 2:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
A few comments on this propo= sed list:

> Integration with TLS 1.3 handshake -= The basic 1-RTT mode must be
> supported. TLS exporters are n= ot needed, nor are session
> tickets. Basic key exchange is su= fficient and implementations can
> use any certificate. All MT= I algorithms listed in TLS 1.3 are
> expected.

<= /div>
I note that this and the transport parameters and HRR stuff below=
necessitate the generic changes to the TLS library to permit add= ing
extra extensions. I wonder if it might make life better to ju= st have a
canned set of parameters for now. It's not that it&= #39;s a lot of work,
it's just that it's not critical pat= h otherwise.


> Packet protection= - All post handshake packets must be sent with
> 1RTT keys an= d packet protection.

This is inconsistent with not= requiring exporters above. As far
as I can tell, if you're n= ot doing NST, you don't need post-handshake
packets anyway he= re, so you can probably skip this.


<= br>
On Wed, May 10, 2017 at 9:53 PM, Mark Notting= ham <mnot@mnot.net> wrote:
Pre= viously, we've mentioned an intention to have a First Implementation Dr= aft -- that is, an Internet-Draft that we feel is suitable for implementers= to write code to, for the purposes of interoperability testing and gatheri= ng feedback -- shortly after the Paris interim.

Due to the size and complexity of HTTP-over-QUIC, implementing all four dra= fts for this purpose on a reasonable timeline isn't workable.

Instead, the editors have identified a subset of functionality that they be= lieve will serve as a suitable starting point. See:
=C2=A0 https://github.com/quicw= g/base-drafts/wiki/First-Implementation-Draft

They've also identified the set of issues that we believe will be neces= sary to have proposals for before Paris; see:
=C2=A0 https://github.com/quicwg/base-drafts/m= ilestone/1

If all goes well, the plan is to have a set of drafts out (very) soon that = do so; then, we can discuss them and the First Implementation Draft Candida= te in the lead-up to and during the Paris interim.

After Paris, we'll make any necessary adjustments to the documents and = publish another set, which will be the First Implementation Draft.

Please comment / raise concerns / make suggestions on-list.

Regards,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--001a114a80fc1076d3054f7fdedb-- From nobody Sun May 14 13:27:19 2017 Return-Path: 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 A3A0B1204DA for ; Sun, 14 May 2017 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 cg4BYMCQ8kHl for ; Sun, 14 May 2017 13:27:15 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD13129521 for ; Sun, 14 May 2017 13:23:26 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id b68so29477892ywe.3 for ; Sun, 14 May 2017 13:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+rBgr/ODN33JNtqatNBKTS8p88Jw/xT2xrYt+/Kd/AU=; b=bsbt4wqNJew9KqYAPx69qea72HE7KSn6PiAKGatnhVknl+J93ruqxwphf1w367kmeV 3am/t6PZwg/Lr0pMn/JUX919c2qVq5Qafo9f5iv5PFdW1SZeWr2DKE+I+wjejGtCXqY4 wbruTXUpFn0eDsn5L4ZaKvq2fxNaiPUgdpzgCB6bsC1qkOWtUwE7pNny9KGoNdU/tfk7 FfBWk8vWIRhh+/jjDq95QsOhVI3nM9P0OGQWBGQWC2fmBLN3PyffYHDhiwbxOQYovtNe cFKFqOox31SXvq3gTJ+kuGa24mqlL4HiyJds4JWjTtOaSATSthrqPHIkVUxQAS8VF0hF LXRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+rBgr/ODN33JNtqatNBKTS8p88Jw/xT2xrYt+/Kd/AU=; b=uXRrrq9U4zRu2x9KWoXLiPTnMddzlkBcE9o8WK2YoVoQmTiiH4FLKgljuPq5En9PPO GYgb3FFh6vCmWIj3kq5x8cbiD+jfdBFOnJKxRFqhIEgf4BVUHfaIB9BI3R4G9ICJ89Ir T+Rc3wOcpqc/rENydBfm7QSa4wTm3K+cLpV+pzfvBwCZFK6iw53HTAKvq5Yc7od/Kf9/ I3nHs9EdT45gWyhL+zIUhh6W90fioQHY3zVE2RV2zRF89io3CoTN7aPVNGxBMfTwetmB LhLYK5n8P8iHlb0btMW9fD4KBsZx2WEgce3BZ/Q2/sUJZWb1yTgSgj4yLyxWzZ46UyrK CGjg== X-Gm-Message-State: AODbwcD2YQIe3DOz9DPufKwgvklUNE7MBE45I4RmPkB1W5I6RfECZgvc NHR7l8ZxO9RcgTyH/5lBIQDfvcs6+TPBAqU= X-Received: by 10.129.85.83 with SMTP id j80mr2283478ywb.283.1494793405379; Sun, 14 May 2017 13:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.36.69 with HTTP; Sun, 14 May 2017 13:23:04 -0700 (PDT) In-Reply-To: References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> From: Ian Swett Date: Sun, 14 May 2017 16:23:04 -0400 Message-ID: Subject: Re: Getting to a First Implementation Draft To: Patrick McManus Cc: Eric Rescorla , Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a113f3cbef13b75054f81b513" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:27:18 -0000 --001a113f3cbef13b75054f81b513 Content-Type: text/plain; charset="UTF-8" Fixing the transport parameters sounds like a good simplification to me. I pushed for transferring some information with the 1RTT keys in a late draft, which likely resulted in the inconsistency. My logic is that you haven't really shown the handshake works unless you use the output of it. Transferring data on a non-0 stream requires an application of some sort. Do you have any suggestions for what that would be? Or were you thinking something of simple like "ping" and "pong"? On Sun, May 14, 2017 at 2:11 PM, Patrick McManus wrote: > I don't really know how I feel about this wiki page.. without ratholing > too deeply on it I think that while it tries to facilitate testing and > interop, it treads pretty significantly into the land of project management > which is squarely out of bounds for the working group. I'm willing to see > how it goes but that's my concern - I would rather the WG focuses on the > complete picture while providing more of a forum for pair (or more) wise > testing. > > anyhow wrt specifics - ekr points out the 2 major inconsistencies.. tbh I > would require exporters and the ability to do at least one non-0 stream. At > that point you have a hello world milestone, which is always the first > stage worthy of a toast. Its ok by me if the transport params are just > profiled. > > On Sat, May 13, 2017 at 2:54 PM, Eric Rescorla wrote: > >> A few comments on this proposed list: >> >> > Integration with TLS 1.3 handshake - The basic 1-RTT mode must be >> > supported. TLS exporters are not needed, nor are session >> > tickets. Basic key exchange is sufficient and implementations can >> > use any certificate. All MTI algorithms listed in TLS 1.3 are >> > expected. >> >> I note that this and the transport parameters and HRR stuff below >> necessitate the generic changes to the TLS library to permit adding >> extra extensions. I wonder if it might make life better to just have a >> canned set of parameters for now. It's not that it's a lot of work, >> it's just that it's not critical path otherwise. >> >> >> > Packet protection - All post handshake packets must be sent with >> > 1RTT keys and packet protection. >> >> This is inconsistent with not requiring exporters above. As far >> as I can tell, if you're not doing NST, you don't need post-handshake >> packets anyway here, so you can probably skip this. >> >> >> >> On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham wrote: >> >>> Previously, we've mentioned an intention to have a First Implementation >>> Draft -- that is, an Internet-Draft that we feel is suitable for >>> implementers to write code to, for the purposes of interoperability testing >>> and gathering feedback -- shortly after the Paris interim. >>> >>> Due to the size and complexity of HTTP-over-QUIC, implementing all four >>> drafts for this purpose on a reasonable timeline isn't workable. >>> >>> Instead, the editors have identified a subset of functionality that they >>> believe will serve as a suitable starting point. See: >>> https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft >>> >>> They've also identified the set of issues that we believe will be >>> necessary to have proposals for before Paris; see: >>> https://github.com/quicwg/base-drafts/milestone/1 >>> >>> If all goes well, the plan is to have a set of drafts out (very) soon >>> that do so; then, we can discuss them and the First Implementation Draft >>> Candidate in the lead-up to and during the Paris interim. >>> >>> After Paris, we'll make any necessary adjustments to the documents and >>> publish another set, which will be the First Implementation Draft. >>> >>> Please comment / raise concerns / make suggestions on-list. >>> >>> Regards, >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> >> > --001a113f3cbef13b75054f81b513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fixing the transport parameters sounds like a good simplif= ication to me.

I pushed for transferring some informatio= n with the 1RTT keys in a late draft, which likely resulted in the inconsis= tency.=C2=A0 My logic is that you haven't really shown the handshake wo= rks unless you use the output of it.

Transferring = data on a non-0 stream requires an application of some sort.=C2=A0 Do you h= ave any suggestions for what that would be?=C2=A0 Or were you thinking some= thing of simple like "ping" and "pong"?

On Sun, May 14, 2017 = at 2:11 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:=
I don't really= know how I feel about this wiki page.. without ratholing too deeply on it = I think that while it tries to facilitate testing and interop, it treads pr= etty significantly into the land of project management which is squarely ou= t of bounds for the working group. I'm willing to see how it goes but t= hat's my concern - I would rather the WG focuses on the complete pictur= e while providing more of a forum for pair (or more) wise testing.

anyhow wrt specifics -=C2=A0 ekr points out the 2 majo= r inconsistencies.. tbh I would require exporters and the ability to do at = least one non-0 stream. At that point you have a hello world milestone, whi= ch is always the first stage worthy of a toast. Its ok by me if the transpo= rt params are just profiled.

On Sat, = May 13, 2017 at 2:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
A few comments on this propo= sed list:

> Integration with TLS 1.3 handshake -= The basic 1-RTT mode must be
> supported. TLS exporters are n= ot needed, nor are session
> tickets. Basic key exchange is su= fficient and implementations can
> use any certificate. All MT= I algorithms listed in TLS 1.3 are
> expected.

<= /div>
I note that this and the transport parameters and HRR stuff below=
necessitate the generic changes to the TLS library to permit add= ing
extra extensions. I wonder if it might make life better to ju= st have a
canned set of parameters for now. It's not that it&= #39;s a lot of work,
it's just that it's not critical pat= h otherwise.


> Packet protection= - All post handshake packets must be sent with
> 1RTT keys an= d packet protection.

This is inconsistent with not= requiring exporters above. As far
as I can tell, if you're n= ot doing NST, you don't need post-handshake
packets anyway he= re, so you can probably skip this.



O= n Wed, May 10, 2017 at 9:53 PM, Mark Nottingham <mnot@mnot.net> = wrote:
Previously, we've mentioned an= intention to have a First Implementation Draft -- that is, an Internet-Dra= ft that we feel is suitable for implementers to write code to, for the purp= oses of interoperability testing and gathering feedback -- shortly after th= e Paris interim.

Due to the size and complexity of HTTP-over-QUIC, implementing all four dra= fts for this purpose on a reasonable timeline isn't workable.

Instead, the editors have identified a subset of functionality that they be= lieve will serve as a suitable starting point. See:
=C2=A0 https://github.com/quicw= g/base-drafts/wiki/First-Implementation-Draft

They've also identified the set of issues that we believe will be neces= sary to have proposals for before Paris; see:
=C2=A0 https://github.com/quicwg/base-drafts/m= ilestone/1

If all goes well, the plan is to have a set of drafts out (very) soon that = do so; then, we can discuss them and the First Implementation Draft Candida= te in the lead-up to and during the Paris interim.

After Paris, we'll make any necessary adjustments to the documents and = publish another set, which will be the First Implementation Draft.

Please comment / raise concerns / make suggestions on-list.

Regards,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




--001a113f3cbef13b75054f81b513-- From nobody Sun May 14 13:43:52 2017 Return-Path: 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 9E0B712940E for ; Sun, 14 May 2017 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 YNlGqvXNi3h1 for ; Sun, 14 May 2017 13:43:49 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 57748129C06 for ; Sun, 14 May 2017 13:39:34 -0700 (PDT) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id A8A6C3A0A3 for ; Sun, 14 May 2017 16:39:33 -0400 (EDT) Received: by mail-qt0-f180.google.com with SMTP id t26so72226621qtg.0 for ; Sun, 14 May 2017 13:39:33 -0700 (PDT) X-Gm-Message-State: AODbwcCJ2irqzzPPw1XLD6eti3oxWxLIXmYhgJL37VY7wd8zCt2MR/TA 2wgi+pZ03FNiIxy3i9dDbTx3p0SXKA== X-Received: by 10.237.57.170 with SMTP id m39mr2415509qte.163.1494794373382; Sun, 14 May 2017 13:39:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.178.74 with HTTP; Sun, 14 May 2017 13:39:32 -0700 (PDT) In-Reply-To: References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> From: Patrick McManus Date: Sun, 14 May 2017 16:39:32 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Getting to a First Implementation Draft To: Ian Swett Cc: Patrick McManus , Eric Rescorla , Mark Nottingham , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a11404b9ca34b0f054f81eff9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:43:50 -0000 --001a11404b9ca34b0f054f81eff9 Content-Type: text/plain; charset="UTF-8" On Sun, May 14, 2017 at 4:23 PM, Ian Swett wrote: > Or were you thinking something of simple like "ping" and "pong"? > yep. --001a11404b9ca34b0f054f81eff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Sun, May 14, 2017 at 4:23 PM, Ian Swett <ianswett@google.com><= /span> wrote:
Or w= ere you thinking something of simple like "ping" and "pong&q= uot;?


yep.
--001a11404b9ca34b0f054f81eff9-- From nobody Sun May 14 14:47:52 2017 Return-Path: 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 7384C129B15 for ; Sun, 14 May 2017 14:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 eRILm5AKf8j6 for ; Sun, 14 May 2017 14:47:49 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5668E129C39 for ; Sun, 14 May 2017 14:43:47 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n23so48178623pfb.2 for ; Sun, 14 May 2017 14:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z989ghB6pqbQsA/Uia/W/RhjraiI/0TVpyNpUslNECk=; b=E3nLSdfhgkNYDr8rHdtnby+p49lpLt2NBju9mKJK31dqYnBmydixAap+7jff0t+3Yi /GrJt8lf/fU4iKA8/QS1Jjf+SRR+Q/a8lXfu5+KEjyFIsyk/gBzKwrwwrMtAGGO7TpN3 PNGaOfmeuBpqIufr3cZ40URr55Iuks3r8obMjyvsipExPg3xE03+MQjmxfhC4YHenMZW 8xe8ImFVa2EULqsExdBW6b6YPlMAMEoCH5xdmTVExXEDd7b93NZgLsGZT6+whwqRxSVF Kao7otRRrVi+moGe0ztwsQrsIyrxbGzzJDD9499S3NFkGapJ3I+h6JSGzfADWRavH2Ax ZY5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z989ghB6pqbQsA/Uia/W/RhjraiI/0TVpyNpUslNECk=; b=Kjud3ZtXlMarpBRyFKm2DMUcGV6QAD5kCLSDFdZVNK8nOHHkuxY831TwU+GiDn5hCZ M5S3eJIEVbUhvzgJK4mFXRtPRbxtA7eOJ0siplPx1kLRSflp6jH5QR6O4YIV1x+9WkWN f0nmi9QxG0SOgXgW/0VPzGCW4kUt9UCAGxygphUQKdpUhhgOkMoTnvtew9W/GiLDqHE7 PnPSxGv6j8/AU5gF58XyVFxKpRS+bUUOJiRNN/htIP6vA75tA43xc74pohPZClxhZ9ZO A1XckS3463MS00bHzWqP+nMHK9GcYvj4fzDe5fG60jxq2StexYAAJEH8kYW8Ny8TRbVv bM5w== X-Gm-Message-State: AODbwcBnEONLh87qoEUSn7brFgHa1WpPsSL0liAirSp7gN/iIu6fUkoQ sJ2GV5r+R2RABN8C4m2xm2hD1wMf9mmk X-Received: by 10.98.42.213 with SMTP id q204mr2961332pfq.165.1494798226653; Sun, 14 May 2017 14:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Sun, 14 May 2017 14:43:46 -0700 (PDT) In-Reply-To: References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> From: Jana Iyengar Date: Sun, 14 May 2017 14:43:46 -0700 Message-ID: Subject: Re: Getting to a First Implementation Draft To: Patrick McManus Cc: Ian Swett , Mark Nottingham , Eric Rescorla , IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a11456f4a4ffda9054f82d5bd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 21:47:50 -0000 --001a11456f4a4ffda9054f82d5bd Content-Type: text/plain; charset="UTF-8" Adding a PING frame + ACK seems like a good idea. On Sun, May 14, 2017 at 1:39 PM, Patrick McManus wrote: > > On Sun, May 14, 2017 at 4:23 PM, Ian Swett wrote: > >> Or were you thinking something of simple like "ping" and "pong"? >> > > > yep. > --001a11456f4a4ffda9054f82d5bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding a PING frame + ACK seems like a good idea.

On Sun, May 14, 2017= at 1:39 PM, Patrick McManus <pmcmanus@mozilla.com> wrote= :

On Sun, May 14, 2017 a= t 4:23 PM, Ian Swett <ianswett@google.com> wrote:
Or were you thinking somet= hing of simple like "ping" and "pong"?


yep.

--001a11456f4a4ffda9054f82d5bd-- From nobody Sun May 14 21:15:13 2017 Return-Path: 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 10094128959 for ; Sun, 14 May 2017 21:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mvd1ROFD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZMzTZThv 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 5NlwBvNiUg0U for ; Sun, 14 May 2017 21:15:09 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE7F1201F2 for ; Sun, 14 May 2017 21:11:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 3D196A6C; Mon, 15 May 2017 00:11:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 15 May 2017 00:11:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:reply-to:subject:to:x-me-sender:x-me-sender :x-sasl-enc:x-sasl-enc; s=fm1; bh=BUuprEsLbvUv5707E64Ogde3ZiXast nAyn/zGIAqFpc=; b=mvd1ROFDip8Tw9mBv4g04IWpTKdZoxs41dklosqjIwIv5D VzSn0sUiVC1uCXKUXNGEb7d5VosE7xgeiMneBo5NJ5hroshFknXW8DyRR93H7RGg wrYIaMdlHOfMMR4bXGqBPV2xwpcRq/H0yKjfDHpzUh1YCV7hY9QZ7RXvu+zYI1vf io+xffTXsFr3kvn7cb2i4iU4UMonRgzwudiF1YBlfW38sJdpb0gnL4QR8tU20L+m Z4m3vUCVc11g1AD8M2suZn9PPWP37i/WqAoWhMddURaj0UjU0D22c2GADz8oThLD QX9VTYzYf4WBB+PoxJDp+LBfXvS6qBXZmhl79MQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:reply-to:subject:to :x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=BUuprE sLbvUv5707E64Ogde3ZiXastnAyn/zGIAqFpc=; b=ZMzTZThvgdmKrjRR2Uhx6K qcEv5dz1VaWsf+nrD3pJoxw9O2q32EdZZXndKIoFB3GZyDh5+fgnscuG5Av4sVI9 BIiRcXMfJExq53RVCc4ogMzxh2yGSYZuTQwDwM3ze2UkCwjm5QfvIp+SOKo3WkVo JB7Dlbls4wXZQeSeIQ9Nw+aNCqAi4Mu5EgIvA2HotuhkMorrhmg9diqgR7OQnEiN rdYc5XqhXp8EOgkXlRDmP1toHTV8AywA5AkFUSIFLsgM/XKOSendnVFTSL5eDAxp pvKUnFM5xzmhQPJy6t2afMS8Ln0wfhoL8Y+WkA8BxvyqvuVW5h5rLVGyEFSFX+cg == X-ME-Sender: X-Sasl-enc: CI4cgRgthAVy8fNOrRHAeJOg0rfKCCixjBPoNni4O9iR 1494821481 Received: from [192.168.1.18] (cpe-124-189-96-43.gziz1.win.bigpond.net.au [124.189.96.43]) by mail.messagingengine.com (Postfix) with ESMTPA id 35884241E3; Mon, 15 May 2017 00:11:20 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: Mark Nottingham Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Remote participation in the June QUIC Interim meeting Date: Mon, 15 May 2017 14:11:17 +1000 Message-Id: <418BF468-7CBA-4497-96E1-8D19EA93C123@mnot.net> Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 04:15:12 -0000 If you registered to participate in the June interim meeting remotely, = you should now have an e-mail with the details from WebEx.=20 If you did but don't receive such an e-mail in the next few hours, = please reply to this e-mail (just to me) and we'll sort it out. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 15 01:07:05 2017 Return-Path: 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 E51EF126E64 for ; Mon, 15 May 2017 01:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9p-Rhzd9Xutj for ; Mon, 15 May 2017 01:07:01 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0E3126D05 for ; Mon, 15 May 2017 01:02:14 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l14so33810322ywk.1 for ; Mon, 15 May 2017 01:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tGoIq1Ue4FtnjVJLWGPFSbWWwr6FwY2HvE1N8pT0l8Q=; b=e1lmo9Z5jqPt5VUMrkVh3HOjQYWmUTKF50mIGDQahFFwMTYd/lD9fSY6yzmyNs8zN1 VOnCqtWO2nSxw6FMeTcuiOSdwsMG3VEY4EMHHz05UCbIz6ORz/kg4w1R/Fc9MZWTsJDS n93/35A2qo2mq/GklP1NytLkwAKQnXzEm7gbRzMGOh+WSuVQHteXES1AJ4aWfK+v47p2 BU1MP2FYtLrC04Wa+ZXOHp6+mV+drMlrTrqr6NLB15XDEvAvPMd53Gokp4aS8kpqOT04 L45QqRBr9MOVix6UsXpmyGRf2DEA6vhKu+E3fRbzzoiXQ4O0ynw5oQoyiJezC0V6tNey ApTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tGoIq1Ue4FtnjVJLWGPFSbWWwr6FwY2HvE1N8pT0l8Q=; b=ZqgsIQorWSCU8xFcjkhShexMXekx4nqmTrNDXh5XDDToqpK7C7WBbq20ZMY/MGPlWE wnBsCnoCDuNHXmBaOIfu3InwwKZXiwjzHr77+enNxqxvl2WzWPNcxRxboA9gZTqcsU+J k3stXeatdpt6sHWalXrSJwRaI2o5Y4A92LyrPT7+8oLCn9KqUvikRxUWALx2nXWcjWdR tm8FXJ1QPqmG3tDrBU1PfNFHi48f8BteTI/BYq87kXOuCKPjZBS/1HjpD/r5LNCsROPd DvfttAQ7aJ0SCZtZsxS/2npsa/rMNTFjIKVzhdrZ8cV28gWuvbdxVYGDeu3ebqqlorwk u3xA== X-Gm-Message-State: AODbwcDXRDSqkM161S0P+60DwWJkgO0A1mEH9mnZb2zdo5dNzS7qydr1 2VVrPGnDZrWMC0xPurO7uDX01myiDw== X-Received: by 10.129.97.195 with SMTP id v186mr4141888ywb.151.1494835334111; Mon, 15 May 2017 01:02:14 -0700 (PDT) MIME-Version: 1.0 References: <20DB6018-3E7B-454F-8BEC-0F839D949AFE@mnot.net> In-Reply-To: From: Lucas Clemente Date: Mon, 15 May 2017 08:02:03 +0000 Message-ID: Subject: Re: Getting to a First Implementation Draft To: Jana Iyengar , Patrick McManus Cc: Ian Swett , IETF QUIC WG , Lars Eggert , Mark Nottingham , Eric Rescorla , Marten Seemann Content-Type: multipart/alternative; boundary="001a11490122166929054f8b798f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 08:07:03 -0000 --001a11490122166929054f8b798f Content-Type: text/plain; charset="UTF-8" Another idea would be to just have a single stream and "emulate" TCP+TLS using that. We used something similar in the past to refine our API, and this gave us a lot of input for that. This would probably add flow control to the scope, unless we just manually set the window to something huge for these initial tests. On Sun, 14 May 2017 at 23:47 Jana Iyengar wrote: > Adding a PING frame + ACK seems like a good idea. > > On Sun, May 14, 2017 at 1:39 PM, Patrick McManus > wrote: > >> >> On Sun, May 14, 2017 at 4:23 PM, Ian Swett wrote: >> >>> Or were you thinking something of simple like "ping" and "pong"? >>> >> >> >> yep. >> > > --001a11490122166929054f8b798f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another idea would be to just have a single stream and &qu= ot;emulate" TCP+TLS using that. We used something similar in the past to refine our A= PI, and this gave us a lot of input for that.

This would= probably add flow control to the scope, unless we just manually set the wi= ndow to something huge for these initial tests.

On Sun, 14 May 2017 at 23:47 Jana Iyengar &l= t;jri@google.com> wrote:
=
Adding a PING frame + ACK s= eems like a good idea.

On Sun, May 14, 2017 at 1:39 PM, Patrick McManus <pmcmanus@m= ozilla.com> wrote:

On= Sun, May 14, 2017 at 4:23 PM, Ian Swett <ianswett@google.com> wrote:
Or wer= e you thinking something of simple like "ping" and "pong&quo= t;?


yep.

--001a11490122166929054f8b798f-- From nobody Wed May 17 14:37:10 2017 Return-Path: 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 9D5F61201FA for ; Wed, 17 May 2017 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lplRkKpSQd0X for ; Wed, 17 May 2017 14:37:08 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FE31200F3 for ; Wed, 17 May 2017 14:37:07 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id h16so14078927vkd.2 for ; Wed, 17 May 2017 14:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=44arKqlKHBONGJYHh3XsGtBdh6s4gaVdLKc/eTS7gSY=; b=C6Lr2NCQRG+x114lVp5+O+YmT6YSSUaLoBtt66T01GolOY905buZjl0BbyLkYCgKlH 3dPXjnii/2Dp5ublCouXbeuJb+hTHE9N+CGk5Oz8HOTjhP1hAZky4NZtw6NUMp6//H93 LHG1wvhOMoZaj5MxjrG7IhRLia0eD4AZRiIvFyHyeWu2mN7gRRu8lWS6VcpMU+fAmzwc Zpxvv83spPHOj+XWl/H9J9skBJHKO9Nx0CJTPHDBbIjtzwMTIiKjxhntC90/ymvwoXko aM9foJfHhFmbbruUTunk8oQqDDeioKeR/mwucQSH1hOIwViTHOMRVPmTgiLwyT8dR5iA UEog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=44arKqlKHBONGJYHh3XsGtBdh6s4gaVdLKc/eTS7gSY=; b=TQvKGF38lB/Pi/sWrewLdmp3eOzH994QaEwbwKiSgpYO6B899iRmgRvZAopDBErvLf dR/cU/Pg8i76u+IdwiV3sPNxlQrAR020bxYS0sckrxROENx/S7+zGBF33Q5UojwXf1Yi RbSt7iwD8uOM+plLY4hG6kVVXrh9lQOFWer7y/e+U+u7CdT0kl1Eec33IP3TTH+mViX5 BDCkiJxN6155mEVxo2W96skGx0yM2TfHK+niv8h9ggDwrw+yCyU+kmt3jlg0SwADw7Tq FB1Q1xYk+EpW5TqAZsPQ8FK1d0XlSVtxEISBEjyKk9yHASOBdE/qi7tOi8yh+G1qBYUa K+pA== X-Gm-Message-State: AODbwcBV46N0CaTT7gRCkTv8/7hYI8faqIKuJz/WSJUSa9K7T4zOKF1h jy6enCCzka8oAbmq1v8KV2bfyuwDmQ== X-Received: by 10.31.115.194 with SMTP id o185mr504920vkc.45.1495057027001; Wed, 17 May 2017 14:37:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.18 with HTTP; Wed, 17 May 2017 14:36:46 -0700 (PDT) From: Bernard Aboba Date: Wed, 17 May 2017 14:36:46 -0700 Message-ID: Subject: Potential conflict between draft-ietf-quic-transport and RFC 7983 To: quic@ietf.org Cc: "pthatcher@google.com" , marc@petit-huguenin.org Content-Type: multipart/alternative; boundary="94eb2c14970c037594054fbf17dd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:37:10 -0000 --94eb2c14970c037594054fbf17dd Content-Type: text/plain; charset="UTF-8" There appears to be a potential conflict between draft-ietf-quic-transport and RFC 7983. Looking at draft-ietf-quic-transport, both the short and the long headers appear to conflict with the de-multiplexing scheme defined in RFC 7983, which is based on the value of the first byte of multi-plexed protocols: The process for demultiplexing a packet is as follows. The receiver looks at the first byte of the packet. If the value of this byte is in between 0 and 3 (inclusive), then the packet is STUN. If the value is between 16 and 19 (inclusive), then the packet is ZRTP. If the value is between 20 and 63 (inclusive), then the packet is DTLS. If the value is between 64 and 79 (inclusive), then the packet is TURN Channel. If the value is in between 128 and 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and RTP are being multiplexed over the same destination port). If the value does not match any known range, then the packet MUST be dropped and an alert MAY be logged. This process is summarized in Figure 3. +----------------+ | [0..3] -+--> forward to STUN | | | [16..19] -+--> forward to ZRTP | | packet --> | [20..63] -+--> forward to DTLS | | | [64..79] -+--> forward to TURN Channel | | | [128..191] -+--> forward to RTP/RTCP +----------------+ Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. --94eb2c14970c037594054fbf17dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There appears to be a potential conflict between draft-iet= f-quic-transport and=C2=A0RFC 7983. Looking at draft-ietf-quic-transport, b= oth the short and the long headers appear to conflict with the de-multiplex= ing scheme defined in RFC 7983, which is based on the value of the first by= te of multi-plexed protocols:=C2=A0

   The process for demultiplexing a packet is as follows=
.  The receiver
   looks at the first byte of the packet.  If the value of this byte is
   in between 0 and 3 (inclusive), then the packet is STUN.  If the
   value is between 16 and 19 (inclusive), then the packet is ZRTP.  If
   the value is between 20 and 63 (inclusive), then the packet is DTLS.
   If the value is between 64 and 79 (inclusive), then the packet is
   TURN Channel.  If the value is in between 128 and 191 (inclusive),
   then the packet is RTP (or RTCP, if both RTCP and RTP are being
   multiplexed over the same destination port).  If the value does not
   match any known range, then the packet MUST be dropped and an alert
   MAY be logged.  This process is summarized in Figure 3.

                    +----------------+
                    |        [0..3] -+--> forward to STUN
                    |                |
                    |      [16..19] -+--> forward to ZRTP
                    |                |
        packet -->  |      [20..63] -+--> forward to DTLS
                    |                |
                    |      [64..79] -+--> forward to TURN Channel
                    |                |
                    |    [128..191] -+--> forward to RTP/RTCP
                    +----------------+

     Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm=
.


--94eb2c14970c037594054fbf17dd-- From nobody Wed May 17 14:52:21 2017 Return-Path: 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 D8BAD12009C for ; Wed, 17 May 2017 14:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 ByN1usJVrRPx for ; Wed, 17 May 2017 14:52:17 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0096.outbound.protection.outlook.com [104.47.32.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91EC126DD9 for ; Wed, 17 May 2017 14:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l8Z/39fHKmd2DGk6iKtBn1xtSRJV4fsEyWiWLrP1nnI=; b=Fv7k6e4rG1nxmbPPG3IRd5k+Sp0H9jM9LI8tslxufD5dpKD+fZXtnhdcwtyM9ISye7iEtiuBPCV4u0X7nYJ/q25DWjCtXce+HXrWOj/Vpypt+f2eNeeNtWCE6BY6CVmYdX6SzvIxndJOkJhlLi0hCwVH7y/v/2vQHKO530Mx2Kg= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Wed, 17 May 2017 21:52:14 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1084.029; Wed, 17 May 2017 21:52:14 +0000 From: Mike Bishop To: Bernard Aboba , "quic@ietf.org" CC: "marc@petit-huguenin.org" , "pthatcher@google.com" Subject: RE: Potential conflict between draft-ietf-quic-transport and RFC 7983 Thread-Topic: Potential conflict between draft-ietf-quic-transport and RFC 7983 Thread-Index: AQHSz1XB0XTUZmZUbU2a1ilYEZYs7KH5DrUQ Date: Wed, 17 May 2017 21:52:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::660] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:ghAQQwUuIbyO0BplOGOPtC8mNEuE6glWYkh7X30Me7ynvlzCj/5L+nVDjiDeXSNCqCtQCtOWaFcX+Tp9jMIIENHE308gKtuZjU6rWvtjK8rF05WLjwm9lrhFdajmVykKXG+XH5ZYPMcth8JGKuQs2oF2yMb25hBrFAoRlD66P53MLfcxIguCHO5kgvU8vpw5e3i6LOHJgvd37QxTg9UgTxAM0UGX56tddw7fAJ304f+DO9oke88HTxb/0qhWEM+0/OVO+vODRdJ91wbfQb1mpoJNWtWol8DT5nrST28cItAX8irZjPEqMVHGge/mR9oYhXGZEAwApGU5E42LRyRPuLmLbVEB5iwGuT9zaPYdjBo= x-ms-office365-filtering-correlation-id: 50b9288a-7106-4730-9094-08d49d6efa96 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(377454003)(2501003)(10290500003)(39060400002)(54906002)(230783001)(99286003)(6506006)(2900100001)(53546009)(189998001)(7736002)(6306002)(74316002)(4326008)(6436002)(53936002)(10090500001)(5005710100001)(86362001)(86612001)(9686003)(54896002)(72206003)(6246003)(25786009)(76176999)(33656002)(8676002)(54356999)(38730400002)(229853002)(50986999)(77096006)(5660300001)(8990500004)(3280700002)(7696004)(8936002)(478600001)(102836003)(790700001)(2950100002)(2906002)(6116002)(81166006)(3660700001)(122556002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27088B21ED2D58F609EBA50287E70BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 21:52:13.9545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:52:20 -0000 --_000_BN6PR03MB27088B21ED2D58F609EBA50287E70BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Nzk4MyBpcyBhIGJ1Z2ZpeCB0byA1NzY0IHNlY3Rpb24gNS4xLjIsIHBlciBhIHF1aWNrIHBlcnVz YWwuICBJIGRpZG7igJl0IHJlYWQgZWl0aGVyIG9mIHRob3NlIFJGQ3MgYXMgcHVycG9ydGluZyB0 byBjb25zdHJhaW4gdGhlIGZpcnN0IGJ5dGUgb2YgYWxsIGZ1dHVyZSBVRFAtYmFzZWQgcHJvdG9j b2xzLiAgNTc2NCBzYXlzOg0KDQogICBXaGVuIERUTFMtU1JUUCBpcyB1c2VkIHRvIHByb3RlY3Qg YW4gUlRQIHNlc3Npb24sIHRoZSBSVFAgcmVjZWl2ZXINCiAgIG5lZWRzIHRvIGRlbXVsdGlwbGV4 IHBhY2tldHMgdGhhdCBhcmUgYXJyaXZpbmcgb24gdGhlIFJUUCBwb3J0Lg0KLi4uDQogICBJZiBv dGhlciBwYWNrZXQgdHlwZXMgYXJlIHRvIGJlIG11bHRpcGxleGVkIGFzIHdlbGwsIGltcGxlbWVu dG9ycw0KICAgYW5kL29yIGRlc2lnbmVycyBTSE9VTEQgZW5zdXJlIHRoYXQgdGhleSBjYW4gYmUg ZGVtdWx0aXBsZXhlZCBmcm9tDQogICB0aGVzZSB0aHJlZSBbb3IgZml2ZSwgZ2l2ZW4gNzk4M10g cGFja2V0IHR5cGVzLg0KDQpJcyBpdCBhIGdvYWwgZm9yIFFVSUMgYW5kIERUTFMtU1JUUCB0byBj b2V4aXN0IG9uIHRoZSBzYW1lIHBvcnQ/DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQpTZW50OiBXZWRuZXNkYXks IE1heSAxNywgMjAxNyAyOjM3IFBNDQpUbzogcXVpY0BpZXRmLm9yZw0KQ2M6IG1hcmNAcGV0aXQt aHVndWVuaW4ub3JnOyBwdGhhdGNoZXJAZ29vZ2xlLmNvbQ0KU3ViamVjdDogUG90ZW50aWFsIGNv bmZsaWN0IGJldHdlZW4gZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydCBhbmQgUkZDIDc5ODMNCg0K VGhlcmUgYXBwZWFycyB0byBiZSBhIHBvdGVudGlhbCBjb25mbGljdCBiZXR3ZWVuIGRyYWZ0LWll dGYtcXVpYy10cmFuc3BvcnQgYW5kIFJGQyA3OTgzLiBMb29raW5nIGF0IGRyYWZ0LWlldGYtcXVp Yy10cmFuc3BvcnQsIGJvdGggdGhlIHNob3J0IGFuZCB0aGUgbG9uZyBoZWFkZXJzIGFwcGVhciB0 byBjb25mbGljdCB3aXRoIHRoZSBkZS1tdWx0aXBsZXhpbmcgc2NoZW1lIGRlZmluZWQgaW4gUkZD IDc5ODMsIHdoaWNoIGlzIGJhc2VkIG9uIHRoZSB2YWx1ZSBvZiB0aGUgZmlyc3QgYnl0ZSBvZiBt dWx0aS1wbGV4ZWQgcHJvdG9jb2xzOg0KDQoNCiAgIFRoZSBwcm9jZXNzIGZvciBkZW11bHRpcGxl eGluZyBhIHBhY2tldCBpcyBhcyBmb2xsb3dzLiAgVGhlIHJlY2VpdmVyDQoNCiAgIGxvb2tzIGF0 IHRoZSBmaXJzdCBieXRlIG9mIHRoZSBwYWNrZXQuICBJZiB0aGUgdmFsdWUgb2YgdGhpcyBieXRl IGlzDQoNCiAgIGluIGJldHdlZW4gMCBhbmQgMyAoaW5jbHVzaXZlKSwgdGhlbiB0aGUgcGFja2V0 IGlzIFNUVU4uICBJZiB0aGUNCg0KICAgdmFsdWUgaXMgYmV0d2VlbiAxNiBhbmQgMTkgKGluY2x1 c2l2ZSksIHRoZW4gdGhlIHBhY2tldCBpcyBaUlRQLiAgSWYNCg0KICAgdGhlIHZhbHVlIGlzIGJl dHdlZW4gMjAgYW5kIDYzIChpbmNsdXNpdmUpLCB0aGVuIHRoZSBwYWNrZXQgaXMgRFRMUy4NCg0K ICAgSWYgdGhlIHZhbHVlIGlzIGJldHdlZW4gNjQgYW5kIDc5IChpbmNsdXNpdmUpLCB0aGVuIHRo ZSBwYWNrZXQgaXMNCg0KICAgVFVSTiBDaGFubmVsLiAgSWYgdGhlIHZhbHVlIGlzIGluIGJldHdl ZW4gMTI4IGFuZCAxOTEgKGluY2x1c2l2ZSksDQoNCiAgIHRoZW4gdGhlIHBhY2tldCBpcyBSVFAg KG9yIFJUQ1AsIGlmIGJvdGggUlRDUCBhbmQgUlRQIGFyZSBiZWluZw0KDQogICBtdWx0aXBsZXhl ZCBvdmVyIHRoZSBzYW1lIGRlc3RpbmF0aW9uIHBvcnQpLiAgSWYgdGhlIHZhbHVlIGRvZXMgbm90 DQoNCiAgIG1hdGNoIGFueSBrbm93biByYW5nZSwgdGhlbiB0aGUgcGFja2V0IE1VU1QgYmUgZHJv cHBlZCBhbmQgYW4gYWxlcnQNCg0KICAgTUFZIGJlIGxvZ2dlZC4gIFRoaXMgcHJvY2VzcyBpcyBz dW1tYXJpemVkIGluIEZpZ3VyZSAzLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICAgICB8ICAgICAgICBbMC4uM10gLSstLT4g Zm9yd2FyZCB0byBTVFVODQoNCiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICAgICAgICAgfCAgICAgIFsxNi4uMTldIC0rLS0+IGZvcndhcmQgdG8g WlJUUA0KDQogICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KDQogICAgICAg IHBhY2tldCAtLT4gIHwgICAgICBbMjAuLjYzXSAtKy0tPiBmb3J3YXJkIHRvIERUTFMNCg0KICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAg ICB8ICAgICAgWzY0Li43OV0gLSstLT4gZm9yd2FyZCB0byBUVVJOIENoYW5uZWwNCg0KICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICB8 ICAgIFsxMjguLjE5MV0gLSstLT4gZm9yd2FyZCB0byBSVFAvUlRDUA0KDQogICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KICAgICBGaWd1cmUgMzogVGhlIERUTFMt U1JUUCByZWNlaXZlcidzIHBhY2tldCBkZW11bHRpcGxleGluZyBhbGdvcml0aG0uDQoNCg0KDQoN Cg== --_000_BN6PR03MB27088B21ED2D58F609EBA50287E70BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjc5ODMgaXMgYSBidWdmaXggdG8gNTc2NCBzZWN0aW9uIDUu MS4yLCBwZXIgYSBxdWljayBwZXJ1c2FsLiZuYnNwOyBJIGRpZG7igJl0IHJlYWQgZWl0aGVyIG9m IHRob3NlIFJGQ3MgYXMgcHVycG9ydGluZyB0byBjb25zdHJhaW4gdGhlIGZpcnN0IGJ5dGUgb2Yg YWxsIGZ1dHVyZSBVRFAtYmFzZWQgcHJvdG9jb2xzLiZuYnNwOyA1NzY0IHNheXM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgV2hlbiBE VExTLVNSVFAgaXMgdXNlZCB0byBwcm90ZWN0IGFuIFJUUCBzZXNzaW9uLCB0aGUgUlRQIHJlY2Vp dmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBuZWVkcyB0byBkZW11bHRpcGxleCBwYWNrZXRzIHRo YXQgYXJlIGFycml2aW5nIG9uIHRoZSBSVFAgcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Li4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOw0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6 eWVsbG93Ij5JZiBvdGhlciBwYWNrZXQgdHlwZXMgYXJlIHRvIGJlIG11bHRpcGxleGVkIGFzIHdl bGw8L3NwYW4+LCBpbXBsZW1lbnRvcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuZC9vciBkZXNp Z25lcnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZXkgY2FuIGJlIGRlbXVsdGlwbGV4ZWQgZnJvbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlc2UgdGhyZWUNCjwvc3Bhbj48aT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPltvciBmaXZlLCBnaXZlbiA3OTgzXTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiBwYWNrZXQgdHlwZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0IGEgZ29hbCBmb3IgUVVJQyBhbmQgRFRM Uy1TUlRQIHRvIGNvZXhpc3Qgb24gdGhlIHNhbWUgcG9ydD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZg0KPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBNYXkgMTcsIDIwMTcgMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gcXVpY0BpZXRmLm9yZzxicj4N CjxiPkNjOjwvYj4gbWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc7IHB0aGF0Y2hlckBnb29nbGUuY29t PGJyPg0KPGI+U3ViamVjdDo8L2I+IFBvdGVudGlhbCBjb25mbGljdCBiZXR3ZWVuIGRyYWZ0LWll dGYtcXVpYy10cmFuc3BvcnQgYW5kIFJGQyA3OTgzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVyZSBhcHBlYXJzIHRvIGJlIGEgcG90ZW50aWFsIGNvbmZsaWN0IGJldHdlZW4gZHJh ZnQtaWV0Zi1xdWljLXRyYW5zcG9ydCBhbmQmbmJzcDtSRkMgNzk4My4gTG9va2luZyBhdCBkcmFm dC1pZXRmLXF1aWMtdHJhbnNwb3J0LCBib3RoIHRoZSBzaG9ydCBhbmQgdGhlIGxvbmcgaGVhZGVy cyBhcHBlYXIgdG8gY29uZmxpY3Qgd2l0aCB0aGUgZGUtbXVsdGlwbGV4aW5nIHNjaGVtZSBkZWZp bmVkIGluIFJGQyA3OTgzLCB3aGljaA0KIGlzIGJhc2VkIG9uIHRoZSB2YWx1ZSBvZiB0aGUgZmly c3QgYnl0ZSBvZiBtdWx0aS1wbGV4ZWQgcHJvdG9jb2xzOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgVGhlIHByb2Nlc3MgZm9yIGRlbXVsdGlwbGV4aW5nIGEgcGFja2V0IGlzIGFzIGZvbGxvd3Mu Jm5ic3A7IFRoZSByZWNlaXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBsb29rcyBhdCB0aGUgZmlyc3QgYnl0ZSBv ZiB0aGUgcGFja2V0LiZuYnNwOyBJZiB0aGUgdmFsdWUgb2YgdGhpcyBieXRlIGlzPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGluIGJldHdlZW4gMCBhbmQgMyAoaW5jbHVzaXZlKSwgdGhlbiB0aGUgcGFja2V0IGlzIFNU VU4uJm5ic3A7IElmIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZSBpcyBiZXR3ZWVuIDE2IGFuZCAxOSAo aW5jbHVzaXZlKSwgdGhlbiB0aGUgcGFja2V0IGlzIFpSVFAuJm5ic3A7IElmPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHRoZSB2YWx1ZSBpcyBiZXR3ZWVuIDIwIGFuZCA2MyAoaW5jbHVzaXZlKSwgdGhlbiB0aGUgcGFj a2V0IGlzIERUTFMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElmIHRoZSB2YWx1ZSBpcyBiZXR3ZWVuIDY0IGFuZCA3 OSAoaW5jbHVzaXZlKSwgdGhlbiB0aGUgcGFja2V0IGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRVUk4gQ2hhbm5l bC4mbmJzcDsgSWYgdGhlIHZhbHVlIGlzIGluIGJldHdlZW4gMTI4IGFuZCAxOTEgKGluY2x1c2l2 ZSksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHRoZW4gdGhlIHBhY2tldCBpcyBSVFAgKG9yIFJUQ1AsIGlmIGJvdGgg UlRDUCBhbmQgUlRQIGFyZSBiZWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtdWx0aXBsZXhlZCBvdmVyIHRoZSBz YW1lIGRlc3RpbmF0aW9uIHBvcnQpLiZuYnNwOyBJZiB0aGUgdmFsdWUgZG9lcyBub3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgbWF0Y2ggYW55IGtub3duIHJhbmdlLCB0aGVuIHRoZSBwYWNrZXQgTVVTVCBiZSBkcm9w cGVkIGFuZCBhbiBhbGVydDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBNQVkgYmUgbG9nZ2VkLiZuYnNwOyBUaGlzIHBy b2Nlc3MgaXMgc3VtbWFyaXplZCBpbiBGaWd1cmUgMy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0t LS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbMC4u M10gLSYjNDM7LS0mZ3Q7IGZvcndhcmQgdG8gU1RVTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbMTYuLjE5XSAtJiM0 MzstLSZndDsgZm9yd2FyZCB0byBaUlRQPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXQgLS0m Z3Q7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzIwLi42M10gLSYjNDM7 LS0mZ3Q7IGZvcndhcmQgdG8gRFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbNjQuLjc5XSAtJiM0MzstLSZndDsg Zm9yd2FyZCB0byBUVVJOIENoYW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgWzEyOC4uMTkxXSAtJiM0MzstLSZndDsgZm9yd2FyZCB0 byBSVFAvUlRDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBGaWd1cmUgMzogVGhlIERUTFMtU1JUUCByZWNlaXZlcidzIHBhY2tldCBkZW11 bHRpcGxleGluZyBhbGdvcml0aG0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB27088B21ED2D58F609EBA50287E70BN6PR03MB2708namp_-- From nobody Wed May 17 15:32:08 2017 Return-Path: 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 654E31270B4 for ; Wed, 17 May 2017 15:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IG1OSVIsmzeW for ; Wed, 17 May 2017 15:31:43 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D314A126C2F for ; Wed, 17 May 2017 15:31:42 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id p85so14639033vkd.3 for ; Wed, 17 May 2017 15:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6DhPc44gzI726P72+7fq9F+jVuZw4/MMaqBpdL77HbE=; b=hUsn2YlpX6/O8DWj4kjgQ1yEB+VAqHHAU1NN+o55duj8pF334cMaqhkhOW5xOzCTnJ d7LIBLj6wQU2NanNSoJvT9AtWVgUjIf5K4phrL+mQ3uvpbP51HOvMi95hTeWuul9izJM ibtbmHAu/xnOs8BRtnTDvyLSMyJZQXjXHFs1H2kCf5UgUTLcJMFarn4LrSfYfRuyWgRw bQKiZVrjh5yU2jt7h9k35HPXHEbr3E/8dw6rb8Z9xpfBdUd8m3WMKClregK1hbYOkFLn I7H5TzYeBOiwjqt4cSpE8bPZd7E77EvuMvcIqVtES8OY4mAo4cP2isDqzL0CjKVLtH8e ECiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6DhPc44gzI726P72+7fq9F+jVuZw4/MMaqBpdL77HbE=; b=uI83gqhiGUuJc02/fJeUum0v7lLzMxDUx1YlvvERFaRbuuTtUQTnxs1WEJYjt87pJi RAzzyW9IGa0T5YhfyBjw2FfmLZXDdld+721Of3w8Y858vXfuF1O0mbDbM/f+xTi4yFJp t69/9jcBODBv3dy5T8wrSh7I/EKWVdCRe/NUKEAU4h7hGelu1vABUNNlLYnpGKHkWzVB kUimSVHO3Isx07+LD+bFA5Du0Zf1Kc5FsTmq+qemflu8WGeiWjbYIRVqZe0jRn1TwSYx wDp3k7Vcxxh1zWEUS3KgfixhWqjWRiZzXdEZuCaVaXATm94B0jUWNNCdOXTPGz9o/aic J0AQ== X-Gm-Message-State: AODbwcDDthMk/C6tcgeSIULBBvA+Nj2HazfyMO0VLNhPBhtuEX/a7lEL qCaiY5eaRUttwU0YjBQutTOdYpkN2Q== X-Received: by 10.31.242.79 with SMTP id q76mr589513vkh.128.1495060301757; Wed, 17 May 2017 15:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.18 with HTTP; Wed, 17 May 2017 15:31:21 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 17 May 2017 15:31:21 -0700 Message-ID: Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983 To: Mike Bishop Cc: "quic@ietf.org" , "marc@petit-huguenin.org" , "pthatcher@google.com" Content-Type: multipart/alternative; boundary="94eb2c19abda3446dc054fbfda58" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 22:32:06 -0000 --94eb2c19abda3446dc054fbfda58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike asked: "Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"? [BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to co-exist on the same port. Within the scheme, DTLS is used for transport of WebRTC's DTLS/SCTP/UDP data channel and DTLS-SRTP is used for key management of SRTP/SRTCP. While within WebRTC, DTLS currently provides both data channel transport as well as SRTP key management, it is not clear that initial QUIC implementations within WebRTC will attempt to provide alternatives for both of these functions. For example, experimental implementations of a QUIC data channel may wish to focus solely on that objective without having to provide an alternative to DTLS-SRTP. In such an implementation, QUIC and DTLS-SRTP would need to co-exist on the same port. On Wed, May 17, 2017 at 2:52 PM, Mike Bishop wrote: > 7983 is a bugfix to 5764 section 5.1.2, per a quick perusal. I didn=E2= =80=99t > read either of those RFCs as purporting to constrain the first byte of al= l > future UDP-based protocols. 5764 says: > > > > When DTLS-SRTP is used to protect an RTP session, the RTP receiver > > needs to demultiplex packets that are arriving on the RTP port. > > ... > > If other packet types are to be multiplexed as well, implementors > > and/or designers SHOULD ensure that they can be demultiplexed from > > these three *[or five, given 7983]* packet types. > > > > Is it a goal for QUIC and DTLS-SRTP to coexist on the same port? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Bernard Aboba > *Sent:* Wednesday, May 17, 2017 2:37 PM > *To:* quic@ietf.org > *Cc:* marc@petit-huguenin.org; pthatcher@google.com > *Subject:* Potential conflict between draft-ietf-quic-transport and RFC > 7983 > > > > There appears to be a potential conflict between draft-ietf-quic-transpor= t > and RFC 7983. Looking at draft-ietf-quic-transport, both the short and th= e > long headers appear to conflict with the de-multiplexing scheme defined i= n > RFC 7983, which is based on the value of the first byte of multi-plexed > protocols: > > > > The process for demultiplexing a packet is as follows. The receiver > > looks at the first byte of the packet. If the value of this byte is > > in between 0 and 3 (inclusive), then the packet is STUN. If the > > value is between 16 and 19 (inclusive), then the packet is ZRTP. If > > the value is between 20 and 63 (inclusive), then the packet is DTLS. > > If the value is between 64 and 79 (inclusive), then the packet is > > TURN Channel. If the value is in between 128 and 191 (inclusive), > > then the packet is RTP (or RTCP, if both RTCP and RTP are being > > multiplexed over the same destination port). If the value does not > > match any known range, then the packet MUST be dropped and an alert > > MAY be logged. This process is summarized in Figure 3. > > > > +----------------+ > > | [0..3] -+--> forward to STUN > > | | > > | [16..19] -+--> forward to ZRTP > > | | > > packet --> | [20..63] -+--> forward to DTLS > > | | > > | [64..79] -+--> forward to TURN Channel > > | | > > | [128..191] -+--> forward to RTP/RTCP > > +----------------+ > > > > Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. > > > > > > --94eb2c19abda3446dc054fbfda58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike asked:=C2=A0

"Is it a goal fo= r QUIC and DTLS-SRTP to coexist on the same port"?=C2=A0
[BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to = co-exist on the same port.=C2=A0 Within the scheme, DTLS is used for transp= ort of WebRTC's DTLS/SCTP/UDP data channel and DTLS-SRTP is used for ke= y management of SRTP/SRTCP. =C2=A0

While withi= n WebRTC, DTLS currently provides both data channel transport as well as SR= TP key management, it is not clear that initial QUIC implementations within= WebRTC will attempt to provide alternatives for both of these functions. = =C2=A0

For example, experimental implementations o= f a QUIC data channel may wish to focus solely on that objective without ha= ving to provide an alternative to DTLS-SRTP.=C2=A0 In such an implementatio= n, QUIC and DTLS-SRTP would need to co-exist on the same port.=C2=A0
<= div>


On Wed, May 17, 2017 at 2:52 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

7983 is a bugfix to 5764 section 5.1.2, per a quick = perusal.=C2=A0 I didn=E2=80=99t read either of those RFCs as purporting to = constrain the first byte of all future UDP-based protocols.=C2=A0 5764 says= :

=C2=A0

=C2=A0=C2=A0 When DTLS-SRTP is used to protect= an RTP session, the RTP receiver

=C2=A0=C2=A0 needs to demultiplex packets that= are arriving on the RTP port.

...

=C2=A0=C2=A0 If other packet types are to be multiplex= ed as well, implementors

=C2=A0=C2=A0 and/or designers SHOULD ensure th= at they can be demultiplexed from

=C2=A0=C2=A0 these three [or five, given 7983] packet types.

=C2=A0

Is it a goal for QUIC and DTLS-SRTP to coexist on th= e same port?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 17, 2017 2:37 PM
To: quic@ietf.org=
Cc: mar= c@petit-huguenin.org; pthatcher@google.com
Subject: Potential conflict between draft-ietf-quic-transport and RF= C 7983

=C2=A0

There appears to be a potential conflict between dra= ft-ietf-quic-transport and=C2=A0RFC 7983. Looking at draft-ietf-quic-transp= ort, both the short and the long headers appear to conflict with the de-mul= tiplexing scheme defined in RFC 7983, which is based on the value of the first byte of multi-plexed protocols:=C2=A0

=C2=A0

=C2=A0=C2=A0 The process for demultiplexin=
g a packet is as follows.=C2=A0 The receiver
=C2=A0=C2=A0 looks at the first byte of th=
e packet.=C2=A0 If the value of this byte is
=C2=A0=C2=A0 in between 0 and 3 (inclusive=
), then the packet is STUN.=C2=A0 If the
=C2=A0=C2=A0 value is between 16 and 19 (i=
nclusive), then the packet is ZRTP.=C2=A0 If
=C2=A0=C2=A0 the value is between 20 and 6=
3 (inclusive), then the packet is DTLS.
=C2=A0=C2=A0 If the value is between 64 an=
d 79 (inclusive), then the packet is
=C2=A0=C2=A0 TURN Channel.=C2=A0 If the va=
lue is in between 128 and 191 (inclusive),
=C2=A0=C2=A0 then the packet is RTP (or RT=
CP, if both RTCP and RTP are being
=C2=A0=C2=A0 multiplexed over the same des=
tination port).=C2=A0 If the value does not
=C2=A0=C2=A0 match any known range, then t=
he packet MUST be dropped and an alert
=C2=A0=C2=A0 MAY be logged.=C2=A0 This pro=
cess is summarized in Figure 3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
---------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [0..3] -+--> forward to STUN<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [16..19] -+--> forward to ZRTP<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 packet -->=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [20..63] -+--> forw=
ard to DTLS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [64..79] -+--> forward to TURN Channel=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0 [128..191] -+--> forward to RTP/RTCP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
---------------+
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 Figure 3: The DTL=
S-SRTP receiver's packet demultiplexing algorithm.=

=C2=A0
=C2=A0

--94eb2c19abda3446dc054fbfda58-- From nobody Wed May 17 18:02:49 2017 Return-Path: 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 32B4D127F0E for ; Wed, 17 May 2017 18:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 WLlZF6DYkX4v for ; Wed, 17 May 2017 18:02:44 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9D9124BE8 for ; Wed, 17 May 2017 18:02:44 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id n23so15336987pfb.2 for ; Wed, 17 May 2017 18:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ACNe+S57ILBct5VnuZsXHfSuj3RVHcGuhmCc82Xpdu8=; b=vFJKbio6WotxrDtJW2TGaS58NvNzxdK8SV4j+T1cathQC/Xk4Mt2ES4jnzacssvyB9 Om5l2qcUwnIvEEF1jejtlU8QYw+1M6oRBs759cyKuhlz3hmetXBwuPSrPE9pPa7vVKL/ cjoIbLOwa6eknTjumCMNQhfOi0TMII/VYb7yapRRgE5qlCPYI85OqCc1e7GxOylAIWAl KF7zOycwjmsgiOpp4bz9be6xXklQmNDNJKwAIwNRK/YQOTQ7wEBs7CdgUkmfdAikHm43 JUDrY0ibL49IQoFOBlg2aapUjcpnZsm0N70BAyWc+/NifrtyGQSy+X5TjHXay0T9uJ/o iZiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ACNe+S57ILBct5VnuZsXHfSuj3RVHcGuhmCc82Xpdu8=; b=ZxISNrbRHCrtWAPb+syEm0s1oqKPWM7LQpMbmKLCFOOBgbJ+JriWfCmgRQ5GhXdH6j G8g2MNK2sdqvoAyTDJO2J1MEiULX+7Czcn9QBNz+q0CsgfFRXqtB0EyasFmgcPJsRTO1 ce5vtBn+PU+eMvnYRiXAy0OXHrqeWNoVCh0GmzZeSnyKrAQkWAE2gdRsd3qyKA9t2PHi O4Cp3HZBLSF3UigN/KqPB7UpL9Xrz934YBB/eXGZC8T1JppPUWewdhtuvkz7OBN6j3mR D2vJdYmLPoVTlOrWN6qKAzY8L320EaWqRLD2v6xl0MEK8pmhU2/NJ4c+4cggKe1xMsdd cYbg== X-Gm-Message-State: AODbwcBSQoeBPK76UJy58WuWwQczSrzr4PYdWkzaFZRLixJpaTwdUQd2 nuox4t61xya11H7z5fb2AlFL8FblSvN/ X-Received: by 10.98.76.155 with SMTP id e27mr1452661pfj.77.1495069364041; Wed, 17 May 2017 18:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Wed, 17 May 2017 18:02:43 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 17 May 2017 18:02:43 -0700 Message-ID: Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983 To: Bernard Aboba Cc: Mike Bishop , "marc@petit-huguenin.org" , "quic@ietf.org" , "pthatcher@google.com" Content-Type: multipart/alternative; boundary="001a1135da9a5c1f3e054fc1f695" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 01:02:47 -0000 --001a1135da9a5c1f3e054fc1f695 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This *may* be one of those things where keeping WebRTC in the back of our minds might help QUIC not get stuck badly in the future. So, as a thought exercise (not assuming that we need to solve this problem here) I'd like to walk through what we *could* do if we actually supported both WebRTC protocols and QUIC on the same port. I think the simplest thing to do would be to pass everything through a QUIC "dispatcher" that determines if this packet belongs to QUIC --- basically confirms whether this packet should be consumed by QUIC or not --- and if it isn't consumed by QUIC (including packets that QUIC decides MUST be dropped because they are QUIC packets but violate some property) then it can be consumed by non-QUIC applications on the same port. The question of course is how bad is the likelihood of false positives/negatives. With the encrypted packet types in QUIC, the QUIC dispatcher will safely reject non-QUIC packets. With the plaintext types, which are used during handshake, QUIC packets are covered by a non-crypto FNV-1a hash. The cost that QUIC bears of a mis-classification among plaintext packets as a QUIC packet is limited to cases where the contents of the packet are not part of the final key derivation. These packet types are limited to a few long-form packet types, all of which have a number of version-independent fields upfront, including version, which could be checked for sanity (since connection ID and packet number can be arbitrary.) This still doesn't seem great, since 0x0001 is a fine version number to have in QUIC and may be a completely reasonable string in RTP. So alternatively, we could renumber the long-form packet types to start at 255 and count down, since 192 - 255 is left open by RFC 7983, and since we just need 6 cleartext packet types at the moment to be distinct from the RTP packet types (it's smaller than that, since Stateless Reject and Version Negotiation packets need to echo stuff from the client's packets.) TL;DR of this is that *if* we wanted to allow for a future coexistence of WebRTC protocols with QUIC on the same port -- and this is a big "if", since I wonder if they need to be on the same port --- we could renumber just the long-form packets to start at 255 and grow downwards. We only need <=3D 6 plaintext packet types to be out of the collision region with RFC 7983. On Wed, May 17, 2017 at 3:31 PM, Bernard Aboba wrote: > Mike asked: > > "Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"? > > [BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to co-exist o= n > the same port. Within the scheme, DTLS is used for transport of WebRTC's > DTLS/SCTP/UDP data channel and DTLS-SRTP is used for key management of > SRTP/SRTCP. > > While within WebRTC, DTLS currently provides both data channel transport > as well as SRTP key management, it is not clear that initial QUIC > implementations within WebRTC will attempt to provide alternatives for bo= th > of these functions. > > For example, experimental implementations of a QUIC data channel may wish > to focus solely on that objective without having to provide an alternativ= e > to DTLS-SRTP. In such an implementation, QUIC and DTLS-SRTP would need t= o > co-exist on the same port. > > > > On Wed, May 17, 2017 at 2:52 PM, Mike Bishop > wrote: > >> 7983 is a bugfix to 5764 section 5.1.2, per a quick perusal. I didn=E2= =80=99t >> read either of those RFCs as purporting to constrain the first byte of a= ll >> future UDP-based protocols. 5764 says: >> >> >> >> When DTLS-SRTP is used to protect an RTP session, the RTP receiver >> >> needs to demultiplex packets that are arriving on the RTP port. >> >> ... >> >> If other packet types are to be multiplexed as well, implementors >> >> and/or designers SHOULD ensure that they can be demultiplexed from >> >> these three *[or five, given 7983]* packet types. >> >> >> >> Is it a goal for QUIC and DTLS-SRTP to coexist on the same port? >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Bernard Aboba >> *Sent:* Wednesday, May 17, 2017 2:37 PM >> *To:* quic@ietf.org >> *Cc:* marc@petit-huguenin.org; pthatcher@google.com >> *Subject:* Potential conflict between draft-ietf-quic-transport and RFC >> 7983 >> >> >> >> There appears to be a potential conflict between >> draft-ietf-quic-transport and RFC 7983. Looking at >> draft-ietf-quic-transport, both the short and the long headers appear to >> conflict with the de-multiplexing scheme defined in RFC 7983, which is >> based on the value of the first byte of multi-plexed protocols: >> >> >> >> The process for demultiplexing a packet is as follows. The receiver >> >> looks at the first byte of the packet. If the value of this byte is >> >> in between 0 and 3 (inclusive), then the packet is STUN. If the >> >> value is between 16 and 19 (inclusive), then the packet is ZRTP. If >> >> the value is between 20 and 63 (inclusive), then the packet is DTLS. >> >> If the value is between 64 and 79 (inclusive), then the packet is >> >> TURN Channel. If the value is in between 128 and 191 (inclusive), >> >> then the packet is RTP (or RTCP, if both RTCP and RTP are being >> >> multiplexed over the same destination port). If the value does not >> >> match any known range, then the packet MUST be dropped and an alert >> >> MAY be logged. This process is summarized in Figure 3. >> >> >> >> +----------------+ >> >> | [0..3] -+--> forward to STUN >> >> | | >> >> | [16..19] -+--> forward to ZRTP >> >> | | >> >> packet --> | [20..63] -+--> forward to DTLS >> >> | | >> >> | [64..79] -+--> forward to TURN Channel >> >> | | >> >> | [128..191] -+--> forward to RTP/RTCP >> >> +----------------+ >> >> >> >> Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. >> >> >> >> >> >> > --001a1135da9a5c1f3e054fc1f695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This *may* be one of those things where keeping WebRT= C in the back of our minds might help QUIC not get stuck badly in the futur= e.

So, as a thought exercise (not assuming that we= need to solve this problem here) I'd like to walk through what we *cou= ld* do if we actually supported both WebRTC protocols and QUIC on the same = port.

I think the simplest thing to do would be to= pass everything through a QUIC "dispatcher" that determines if t= his packet belongs to QUIC --- basically confirms whether this packet shoul= d be consumed by QUIC or not --- and if it isn't consumed by QUIC (incl= uding packets that QUIC decides MUST be dropped because they are QUIC packe= ts but violate some property) then it can be consumed by non-QUIC applicati= ons on the same port.

The question of course is ho= w bad is the likelihood of false positives/negatives. With the encrypted pa= cket types in QUIC, the QUIC dispatcher will safely reject non-QUIC packets= .=C2=A0

With the plaintext types, which are used d= uring handshake, QUIC packets are covered by a non-crypto FNV-1a hash. The = cost that QUIC bears of a mis-classification among plaintext packets as a Q= UIC packet is limited to cases where the contents of the packet are not par= t of the final key derivation. These packet types are limited to a few long= -form packet types, all of which have a number of version-independent field= s upfront, including version, which could be checked for sanity (since conn= ection ID and packet number can be arbitrary.) This still doesn't seem = great, since 0x0001 is a fine version number to have in QUIC and may be a c= ompletely reasonable string in RTP.=C2=A0 So alternatively, we could renumb= er the long-form packet types to start at 255 and count down, since 192 - 2= 55 is left open by RFC 7983, and since we just need =C2=A06 cleartext packe= t types at the moment to be distinct from the RTP packet types (it's sm= aller than that, since Stateless Reject and Version Negotiation packets nee= d to echo stuff from the client's packets.)

TL= ;DR of this is that *if* we wanted to allow for a future coexistence of Web= RTC protocols with QUIC on the same port -- and this is a big "if"= ;, since I wonder if they need to be on the same port --- we could renumber= just the long-form packets to start at 255 and grow downwards. We only nee= d <=3D 6 plaintext packet types to be out of the collision region with = =C2=A0RFC 7983.


On Wed, May 17, 2017 at 3:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Mike asked:=C2=A0

"Is it a goal for QUIC and DTLS-SRTP to coexist on the same port= "?=C2=A0

[BA] RFC 7983 enables DTLS, S= RTP/SRTCP, ZRTP, STUN and TURN to co-exist on the same port.=C2=A0 Within t= he scheme, DTLS is used for transport of WebRTC's DTLS/SCTP/UDP data ch= annel and DTLS-SRTP is used for key management of SRTP/SRTCP. =C2=A0

While within WebRTC, DTLS currently provides both da= ta channel transport as well as SRTP key management, it is not clear that i= nitial QUIC implementations within WebRTC will attempt to provide alternati= ves for both of these functions. =C2=A0

For exampl= e, experimental implementations of a QUIC data channel may wish to focus so= lely on that objective without having to provide an alternative to DTLS-SRT= P.=C2=A0 In such an implementation, QUIC and DTLS-SRTP would need to co-exi= st on the same port.=C2=A0



On Wed, May 17, 2017 at 2:52 PM, Mike Bishop <= Michael.Bishop@microsoft.com> wrote:

7983 is a bugfix to 5764 section 5.1.2, per a quick = perusal.=C2=A0 I didn=E2=80=99t read either of those RFCs as purporting to = constrain the first byte of all future UDP-based protocols.=C2=A0 5764 says= :

=C2=A0

=C2=A0=C2=A0 When DTLS-SRTP is used to protect= an RTP session, the RTP receiver

=C2=A0=C2=A0 needs to demultiplex packets that= are arriving on the RTP port.

...

=C2=A0=C2=A0 If other packet types are to be multiplex= ed as well, implementors

=C2=A0=C2=A0 and/or designers SHOULD ensure th= at they can be demultiplexed from

=C2=A0=C2=A0 these three [or five, given 7983] packet types.

=C2=A0

Is it a goal for QUIC and DTLS-SRTP to coexist on th= e same port?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 17, 2017 2:37 PM
To: quic@ietf.org=
Cc: mar= c@petit-huguenin.org; pthatcher@google.com
Subject: Potential conflict between draft-ietf-quic-transport and RF= C 7983

=C2=A0

There appears to be a potential conflict between dra= ft-ietf-quic-transport and=C2=A0RFC 7983. Looking at draft-ietf-quic-transp= ort, both the short and the long headers appear to conflict with the de-mul= tiplexing scheme defined in RFC 7983, which is based on the value of the first byte of multi-plexed protocols:=C2=A0

=C2=A0

=C2=A0=C2=A0 The process for demultiplexin=
g a packet is as follows.=C2=A0 The receiver
=C2=A0=C2=A0 looks at the first byte of th=
e packet.=C2=A0 If the value of this byte is
=C2=A0=C2=A0 in between 0 and 3 (inclusive=
), then the packet is STUN.=C2=A0 If the
=C2=A0=C2=A0 value is between 16 and 19 (i=
nclusive), then the packet is ZRTP.=C2=A0 If
=C2=A0=C2=A0 the value is between 20 and 6=
3 (inclusive), then the packet is DTLS.
=C2=A0=C2=A0 If the value is between 64 an=
d 79 (inclusive), then the packet is
=C2=A0=C2=A0 TURN Channel.=C2=A0 If the va=
lue is in between 128 and 191 (inclusive),
=C2=A0=C2=A0 then the packet is RTP (or RT=
CP, if both RTCP and RTP are being
=C2=A0=C2=A0 multiplexed over the same des=
tination port).=C2=A0 If the value does not
=C2=A0=C2=A0 match any known range, then t=
he packet MUST be dropped and an alert
=C2=A0=C2=A0 MAY be logged.=C2=A0 This pro=
cess is summarized in Figure 3.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
---------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [0..3] -+--> forward to STUN<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [16..19] -+--> forward to ZRTP<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 packet -->=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [20..63] -+--> forw=
ard to DTLS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [64..79] -+--> forward to TURN Channel=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0 [128..191] -+--> forward to RTP/RTCP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
---------------+
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 Figure 3: The DTL=
S-SRTP receiver's packet demultiplexing algorithm.=

=C2=A0
=C2=A0


--001a1135da9a5c1f3e054fc1f695-- From nobody Wed May 17 23:52:04 2017 Return-Path: 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 8C037129B11 for ; Wed, 17 May 2017 23:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 ZpnQ01zuZ46K for ; Wed, 17 May 2017 23:52:00 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE54129577 for ; Wed, 17 May 2017 23:46:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,357,1491289200"; d="asc'?scan'208";a="194020713" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx143-out.netapp.com with ESMTP; 17 May 2017 23:29:44 -0700 Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 May 2017 23:45:28 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 17 May 2017 23:45:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eBeRCG64LVryoR/ABtJKX+0HEfDwAPq85wGoNQQOack=; b=dr/d8SEpQguHqXFhw1m6x1yczm9o5DfrP2wN8LRxW4E5z+pk8kLqX5fovgLOZIUh0YgoXk+yDlPYgLow5ohn6/O2R3e7xGkH66poqag2fN0Jq1BTT1xOdXLiVaxoQ6XjykgQ9VauMZy2qvqgpdxbQcm8ynyvBnY7jDw347YzyIE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 18 May 2017 06:45:27 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1101.019; Thu, 18 May 2017 06:45:27 +0000 From: "Eggert, Lars" To: Bernard Aboba CC: IETF QUIC WG , "marc@petit-huguenin.org" , "pthatcher@google.com" , Colin Perkins Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983 Thread-Topic: Potential conflict between draft-ietf-quic-transport and RFC 7983 Thread-Index: AQHSz1XIXCzACO/170yWGyUYF0R/0aH5pfsA Date: Thu, 18 May 2017 06:45:27 +0000 Message-ID: <8FFA81A9-C08E-4856-B058-AC2766FD931C@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 7:351/dT55o7qOGYSatHqnZ3At7As/nm4yLm1jVdSGxwbAwx289vg7hilH+5E0MygffVY/wsUxYkktiEduyvY+iUzmw1ESe2eKJA1uSB3bqCzUgVkNAiPcEfA9kFxcAu2WRz5OMSdi/AofurE4bnz5HGdr1zjqhPNV8v3E+ePjd9NFWUhNf+zmnzVvn2ZxgJpYdAZ45+/QoCXqOh/1dGib5yk0ZNIAB7JgSYLHBr67qM/nDEC5u+v+hmAsomZOQUJ+OPOl1yhBirhPOhSpCKg8cS5lFriNG6Za5vB+blokLT4q7hqUWKinGOhOUfB6qD0z0eSMEtHcmGbrVWeSgTOCfQ== x-ms-traffictypediagnostic: BLUPR06MB1761: x-ms-office365-filtering-correlation-id: 1a4af2b2-cf12-4cb0-da2f-08d49db97804 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(377424004)(69234005)(24454002)(38730400002)(110136004)(54906002)(4326008)(6512007)(6306002)(99286003)(4001150100001)(229853002)(122556002)(6436002)(6246003)(57306001)(33656002)(76176999)(53546009)(25786009)(99936001)(83716003)(82746002)(966005)(39060400002)(50986999)(66066001)(6506006)(53936002)(230783001)(8936002)(50226002)(7736002)(305945005)(478600001)(102836003)(6116002)(8676002)(81166006)(3846002)(5660300001)(2900100001)(6486002)(77096006)(6916009)(2950100002)(36756003)(86362001)(2906002)(3660700001)(189998001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_33E65924-12AD-4766-90B3-AEF5F339523C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 06:45:27.1875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 06:52:03 -0000 --Apple-Mail=_33E65924-12AD-4766-90B3-AEF5F339523C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, Colin raised this issue in the past and we have ticket #426 on it = open: https://github.com/quicwg/base-drafts/issues/426 Lars > On 2017-5-17, at 23:36, Bernard Aboba wrote: >=20 > There appears to be a potential conflict between = draft-ietf-quic-transport and RFC 7983. Looking at = draft-ietf-quic-transport, both the short and the long headers appear to = conflict with the de-multiplexing scheme defined in RFC 7983, which is = based on the value of the first byte of multi-plexed protocols: >=20 > The process for demultiplexing a packet is as follows. The = receiver > looks at the first byte of the packet. If the value of this byte = is > in between 0 and 3 (inclusive), then the packet is STUN. If the > value is between 16 and 19 (inclusive), then the packet is ZRTP. = If > the value is between 20 and 63 (inclusive), then the packet is = DTLS. > If the value is between 64 and 79 (inclusive), then the packet is > TURN Channel. If the value is in between 128 and 191 (inclusive), > then the packet is RTP (or RTCP, if both RTCP and RTP are being > multiplexed over the same destination port). If the value does not > match any known range, then the packet MUST be dropped and an alert > MAY be logged. This process is summarized in Figure 3. >=20 > +----------------+ > | [0..3] -+--> forward to STUN > | | > | [16..19] -+--> forward to ZRTP > | | > packet --> | [20..63] -+--> forward to DTLS > | | > | [64..79] -+--> forward to TURN Channel > | | > | [128..191] -+--> forward to RTP/RTCP > +----------------+ >=20 > Figure 3: The DTLS-SRTP receiver's packet demultiplexing = algorithm. >=20 >=20 >=20 --Apple-Mail=_33E65924-12AD-4766-90B3-AEF5F339523C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlkdQwQACgkQVLXDCb9w wVc1hQ//XYo5/vfJCPyXqWazSlYYlBy78y4BVgClZaltTEgqmFwRzTO23r83BkvX +wBg2vjBEi8bwpV4FKf6M4sdW7gma46CK/gv9aCA8RpF+RajeU5c0ZCQFLajWs6k PbYI1p1wZR7LnlO6oAM3I3ZlV8NQgBLEsu9fuxzh4HPSrTl/dxozRfuksXp2n174 HTJ/mRzz6Z7LCUP/GRLbT2M0l7hxykCXzdz4TrkotFK0cfzlppn5fc0sdrVG9BD5 bxKnb7hMWzr1Gu5zbU2fYvjHNDhiWZ6IZnjz2rGrM4aXGYeR7Ms++jkKHAzBQqyG 18xW8UGoykn2auu4cDz+xeNGLz4uNSk7uZXNxC8EhnUjClfTLou6xvlTLYYSksc+ nJFr4aG6MkDbU1PidIVa9DYegDR5gIT//XEe/y5mLmFZ4Y1dw099we7VGlZcT2Vm TsB0BH9urTK/42mMk6ajAC4qbHyA3wG2zIfdtR4flBNCPKC2z9W+/uoEp/3CVj65 rmLTOx31cJ/1vUu6eV/aRZiHrRo4VMMW+JJPgzkOGbR9Zx7pUyLCS0LrkxYnNbDI 8MBr2gNBq5CuUpYbZym0qBxhk6d41QsCMHyFxIlbUP3B1+SBXHIjlVXqKCbeSNgE ZICcPaHDf9dD8h5oYM6rTScgrcwy68ZjCKJzGhHKrTt9m5xZINk= =RVhz -----END PGP SIGNATURE----- --Apple-Mail=_33E65924-12AD-4766-90B3-AEF5F339523C-- From nobody Thu May 18 04:17:37 2017 Return-Path: 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 14D21129B5A for ; Thu, 18 May 2017 04:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 RWWPINeUGaBr for ; Thu, 18 May 2017 04:17:33 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F28129C55 for ; Thu, 18 May 2017 04:12:52 -0700 (PDT) Received: from [130.209.247.112] (port=59812 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dBJMO-00026k-Rk; Thu, 18 May 2017 12:12:50 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B1F34B37-3FC3-4DAE-A5F9-6DF8711A5A8D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983 Date: Thu, 18 May 2017 12:12:43 +0100 In-Reply-To: Cc: Bernard Aboba , Mike Bishop , "marc@petit-huguenin.org" , "quic@ietf.org" , "pthatcher@google.com" To: Jana Iyengar References: X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 11:17:36 -0000 --Apple-Mail=_B1F34B37-3FC3-4DAE-A5F9-6DF8711A5A8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I sketched out one way of doing the demuxing of QUIC and the WebRTC = protocols on the same port in = https://github.com/quicwg/base-drafts/issues/426 = =E2=80=93 if we=E2=80=99= re willing to lose a couple of bits from the QUIC type field, then = separating the protocols seems straight-forward. Colin > On 18 May 2017, at 02:02, Jana Iyengar wrote: >=20 > This *may* be one of those things where keeping WebRTC in the back of = our minds might help QUIC not get stuck badly in the future. >=20 > So, as a thought exercise (not assuming that we need to solve this = problem here) I'd like to walk through what we *could* do if we actually = supported both WebRTC protocols and QUIC on the same port. >=20 > I think the simplest thing to do would be to pass everything through a = QUIC "dispatcher" that determines if this packet belongs to QUIC --- = basically confirms whether this packet should be consumed by QUIC or not = --- and if it isn't consumed by QUIC (including packets that QUIC = decides MUST be dropped because they are QUIC packets but violate some = property) then it can be consumed by non-QUIC applications on the same = port. >=20 > The question of course is how bad is the likelihood of false = positives/negatives. With the encrypted packet types in QUIC, the QUIC = dispatcher will safely reject non-QUIC packets.=20 >=20 > With the plaintext types, which are used during handshake, QUIC = packets are covered by a non-crypto FNV-1a hash. The cost that QUIC = bears of a mis-classification among plaintext packets as a QUIC packet = is limited to cases where the contents of the packet are not part of the = final key derivation. These packet types are limited to a few long-form = packet types, all of which have a number of version-independent fields = upfront, including version, which could be checked for sanity (since = connection ID and packet number can be arbitrary.) This still doesn't = seem great, since 0x0001 is a fine version number to have in QUIC and = may be a completely reasonable string in RTP. So alternatively, we = could renumber the long-form packet types to start at 255 and count = down, since 192 - 255 is left open by RFC 7983, and since we just need = 6 cleartext packet types at the moment to be distinct from the RTP = packet types (it's smaller than that, since Stateless Reject and Version = Negotiation packets need to echo stuff from the client's packets.) >=20 > TL;DR of this is that *if* we wanted to allow for a future coexistence = of WebRTC protocols with QUIC on the same port -- and this is a big = "if", since I wonder if they need to be on the same port --- we could = renumber just the long-form packets to start at 255 and grow downwards. = We only need <=3D 6 plaintext packet types to be out of the collision = region with RFC 7983. >=20 >=20 > On Wed, May 17, 2017 at 3:31 PM, Bernard Aboba = > wrote: > Mike asked:=20 >=20 > "Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"?=20 >=20 > [BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to = co-exist on the same port. Within the scheme, DTLS is used for = transport of WebRTC's DTLS/SCTP/UDP data channel and DTLS-SRTP is used = for key management of SRTP/SRTCP. =20 >=20 > While within WebRTC, DTLS currently provides both data channel = transport as well as SRTP key management, it is not clear that initial = QUIC implementations within WebRTC will attempt to provide alternatives = for both of these functions. =20 >=20 > For example, experimental implementations of a QUIC data channel may = wish to focus solely on that objective without having to provide an = alternative to DTLS-SRTP. In such an implementation, QUIC and DTLS-SRTP = would need to co-exist on the same port.=20 >=20 >=20 >=20 > On Wed, May 17, 2017 at 2:52 PM, Mike Bishop = > = wrote: > 7983 is a bugfix to 5764 section 5.1.2, per a quick perusal. I = didn=E2=80=99t read either of those RFCs as purporting to constrain the = first byte of all future UDP-based protocols. 5764 says: >=20 > =20 >=20 > When DTLS-SRTP is used to protect an RTP session, the RTP receiver >=20 > needs to demultiplex packets that are arriving on the RTP port. >=20 > ... >=20 > If other packet types are to be multiplexed as well, implementors >=20 > and/or designers SHOULD ensure that they can be demultiplexed from >=20 > these three [or five, given 7983] packet types. >=20 > =20 >=20 > Is it a goal for QUIC and DTLS-SRTP to coexist on the same port? >=20 > =20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org = ] On Behalf Of Bernard Aboba > Sent: Wednesday, May 17, 2017 2:37 PM > To: quic@ietf.org > Cc: marc@petit-huguenin.org ; = pthatcher@google.com > Subject: Potential conflict between draft-ietf-quic-transport and RFC = 7983 >=20 > =20 >=20 > There appears to be a potential conflict between = draft-ietf-quic-transport and RFC 7983. Looking at = draft-ietf-quic-transport, both the short and the long headers appear to = conflict with the de-multiplexing scheme defined in RFC 7983, which is = based on the value of the first byte of multi-plexed protocols:=20 >=20 > =20 >=20 > The process for demultiplexing a packet is as follows. The = receiver > looks at the first byte of the packet. If the value of this byte = is > in between 0 and 3 (inclusive), then the packet is STUN. If the > value is between 16 and 19 (inclusive), then the packet is ZRTP. = If > the value is between 20 and 63 (inclusive), then the packet is = DTLS. > If the value is between 64 and 79 (inclusive), then the packet is > TURN Channel. If the value is in between 128 and 191 (inclusive), > then the packet is RTP (or RTCP, if both RTCP and RTP are being > multiplexed over the same destination port). If the value does not > match any known range, then the packet MUST be dropped and an alert > MAY be logged. This process is summarized in Figure 3. > =20 > +----------------+ > | [0..3] -+--> forward to STUN > | | > | [16..19] -+--> forward to ZRTP > | | > packet --> | [20..63] -+--> forward to DTLS > | | > | [64..79] -+--> forward to TURN Channel > | | > | [128..191] -+--> forward to RTP/RTCP > +----------------+ > =20 > Figure 3: The DTLS-SRTP receiver's packet demultiplexing = algorithm. > =20 > =20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_B1F34B37-3FC3-4DAE-A5F9-6DF8711A5A8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I sketched out one way of doing the demuxing of QUIC and the = WebRTC protocols on the same port in https://github.com/quicwg/base-drafts/issues/426 =E2=80= =93 if we=E2=80=99re willing to lose a couple of bits from the QUIC type = field, then separating the protocols seems straight-forward.

Colin




On = 18 May 2017, at 02:02, Jana Iyengar <jri@google.com> wrote:

This *may* be one of those things where = keeping WebRTC in the back of our minds might help QUIC not get stuck = badly in the future.

So, as a thought exercise (not assuming that we need to solve = this problem here) I'd like to walk through what we *could* do if we = actually supported both WebRTC protocols and QUIC on the same = port.

I think = the simplest thing to do would be to pass everything through a QUIC = "dispatcher" that determines if this packet belongs to QUIC --- = basically confirms whether this packet should be consumed by QUIC or not = --- and if it isn't consumed by QUIC (including packets that QUIC = decides MUST be dropped because they are QUIC packets but violate some = property) then it can be consumed by non-QUIC applications on the same = port.

The = question of course is how bad is the likelihood of false = positives/negatives. With the encrypted packet types in QUIC, the QUIC = dispatcher will safely reject non-QUIC packets. 

With the plaintext = types, which are used during handshake, QUIC packets are covered by a = non-crypto FNV-1a hash. The cost that QUIC bears of a mis-classification = among plaintext packets as a QUIC packet is limited to cases where the = contents of the packet are not part of the final key derivation. These = packet types are limited to a few long-form packet types, all of which = have a number of version-independent fields upfront, including version, = which could be checked for sanity (since connection ID and packet number = can be arbitrary.) This still doesn't seem great, since 0x0001 is a fine = version number to have in QUIC and may be a completely reasonable string = in RTP.  So alternatively, we could renumber the long-form packet = types to start at 255 and count down, since 192 - 255 is left open by = RFC 7983, and since we just need  6 cleartext packet types at the = moment to be distinct from the RTP packet types (it's smaller than that, = since Stateless Reject and Version Negotiation packets need to echo = stuff from the client's packets.)

TL;DR of this is that *if* we wanted to = allow for a future coexistence of WebRTC protocols with QUIC on the same = port -- and this is a big "if", since I wonder if they need to be on the = same port --- we could renumber just the long-form packets to start at = 255 and grow downwards. We only need <=3D 6 plaintext packet types to = be out of the collision region with  RFC 7983.


On Wed, May 17, 2017 at 3:31 PM, = Bernard Aboba <bernard.aboba@gmail.com> wrote:
Mike asked: 

"Is it a goal for QUIC and DTLS-SRTP to = coexist on the same port"? 

[BA] RFC 7983 enables DTLS, = SRTP/SRTCP, ZRTP, STUN and TURN to co-exist on the same port.  = Within the scheme, DTLS is used for transport of WebRTC's DTLS/SCTP/UDP = data channel and DTLS-SRTP is used for key management of SRTP/SRTCP. =  

While within WebRTC, DTLS currently provides both data = channel transport as well as SRTP key management, it is not clear that = initial QUIC implementations within WebRTC will attempt to provide = alternatives for both of these functions.  

For example, experimental = implementations of a QUIC data channel may wish to focus solely on that = objective without having to provide an alternative to DTLS-SRTP.  = In such an implementation, QUIC and DTLS-SRTP would need to co-exist on = the same port. 



On Wed, May 17, 2017 at 2:52 PM, Mike Bishop <Michael.Bishop@microsoft.com> = wrote:

7983 is a bugfix to 5764 section 5.1.2, per a quick = perusal.  I didn=E2=80=99t read either of those RFCs as purporting = to constrain the first byte of all future UDP-based protocols.  = 5764 says:

 

   When DTLS-SRTP is used to = protect an RTP session, the RTP receiver

   needs to = demultiplex packets that are arriving on the RTP port.

...

   If other packet types are = to be multiplexed as well, implementors

   and/or = designers SHOULD ensure that they can be demultiplexed from

   these three [or five, given = 7983] packet types.

 

Is it a goal for QUIC = and DTLS-SRTP to coexist on the same port?

 

From: QUIC = [mailto:quic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, May 17, 2017 2:37 PM
To: quic@ietf.org
Cc: marc@petit-huguenin.org; pthatcher@google.com
Subject: Potential conflict between = draft-ietf-quic-transport and RFC 7983

 

There appears to be a potential = conflict between draft-ietf-quic-transport and RFC 7983. Looking at = draft-ietf-quic-transport, both the short and the long headers appear to = conflict with the de-multiplexing scheme defined in RFC 7983, which is based on the value of the first byte of multi-plexed = protocols: 

 

   The process for =
demultiplexing a packet is as follows.  The receiver
   looks at the =
first byte of the packet.  If the value of this byte is
   in between 0 =
and 3 (inclusive), then the packet is STUN.  If the
   value is =
between 16 and 19 (inclusive), then the packet is ZRTP.  If
   the value is =
between 20 and 63 (inclusive), then the packet is DTLS.
   If the value is =
between 64 and 79 (inclusive), then the packet is
   TURN =
Channel.  If the value is in between 128 and 191 (inclusive),
   then the packet =
is RTP (or RTCP, if both RTCP and RTP are being
   multiplexed =
over the same destination port).  If the value does not
   match any known =
range, then the packet MUST be dropped and an alert
   MAY be =
logged.  This process is summarized in Figure 3.
 
          &nb=
sp;         +----------------+
          &nb=
sp;         =
|        [0..3] -+--> forward to =
STUN
          &nb=
sp;         =
|            &=
nbsp;   |
          &nb=
sp;         =
|      [16..19] -+--> forward to ZRTP
          &nb=
sp;         =
|            &=
nbsp;   |
        packet =
-->  |      [20..63] -+--> forward =
to DTLS
          &nb=
sp;         =
|            &=
nbsp;   |
          &nb=
sp;         =
|      [64..79] -+--> forward to TURN =
Channel
          &nb=
sp;         =
|            &=
nbsp;   |
          &nb=
sp;         |    =
[128..191] -+--> forward to RTP/RTCP
          &nb=
sp;         +----------------+
 
     =
Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
 
 





-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_B1F34B37-3FC3-4DAE-A5F9-6DF8711A5A8D-- From nobody Thu May 18 04:20:38 2017 Return-Path: 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 68CC912EAFF for ; Thu, 18 May 2017 04:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 NPForC8dKBdK for ; Thu, 18 May 2017 04:20:34 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B3E12EBB2 for ; Thu, 18 May 2017 04:15:12 -0700 (PDT) Received: from [130.209.247.112] (port=59868 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dBJOf-0002Ok-MG; Thu, 18 May 2017 12:15:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Potential conflict between draft-ietf-quic-transport and RFC 7983 From: Colin Perkins In-Reply-To: Date: Thu, 18 May 2017 12:15:08 +0100 Cc: Mike Bishop , "marc@petit-huguenin.org" , "quic@ietf.org" , "pthatcher@google.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 11:20:35 -0000 > On 17 May 2017, at 23:31, Bernard Aboba = wrote: >=20 > Mike asked:=20 >=20 > "Is it a goal for QUIC and DTLS-SRTP to coexist on the same port"?=20 >=20 > [BA] RFC 7983 enables DTLS, SRTP/SRTCP, ZRTP, STUN and TURN to = co-exist on the same port. Within the scheme, DTLS is used for = transport of WebRTC's DTLS/SCTP/UDP data channel and DTLS-SRTP is used = for key management of SRTP/SRTCP. =20 >=20 > While within WebRTC, DTLS currently provides both data channel = transport as well as SRTP key management, it is not clear that initial = QUIC implementations within WebRTC will attempt to provide alternatives = for both of these functions. =20 >=20 > For example, experimental implementations of a QUIC data channel may = wish to focus solely on that objective without having to provide an = alternative to DTLS-SRTP. In such an implementation, QUIC and DTLS-SRTP = would need to co-exist on the same port.=20 Being able to co-exist with STUN and TURN on the same port is likely = important if we ever want QUIC to work peer-to-peer through NATs, too. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Sun May 21 21:54:24 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B13127F0E; Sun, 21 May 2017 21:54:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149542885557.30287.3879638581430203234@ietfa.amsl.com> Date: Sun, 21 May 2017 21:54:15 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 04:54:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-03.txt Pages : 76 Date : 2017-05-21 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-03 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 21 22:21:51 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BFA129B30; Sun, 21 May 2017 22:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149543050319.3467.12693624828503422348@ietfa.amsl.com> Date: Sun, 21 May 2017 22:21:43 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 05:21:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-03.txt Pages : 28 Date : 2017-05-21 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-03 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 21 22:24:57 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2581124C27; Sun, 21 May 2017 22:24:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149543069562.22141.7328442516088212113@ietfa.amsl.com> Date: Sun, 21 May 2017 22:24:55 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 05:24:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-03.txt Pages : 37 Date : 2017-05-21 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-03 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 21 23:27:00 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3F129B62; Sun, 21 May 2017 23:26:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149543441810.3775.5105749613387376627@ietfa.amsl.com> Date: Sun, 21 May 2017 23:26:58 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 06:26:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-03.txt Pages : 18 Date : 2017-05-21 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/recovery . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-03 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 22 00:56:34 2017 Return-Path: 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 93FB6129B8C for ; Mon, 22 May 2017 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=NPuF+dmJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=loaidbrO 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 YF5WH7fbv91w for ; Mon, 22 May 2017 00:56:29 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA938124C27 for ; Mon, 22 May 2017 00:56:29 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 40D02B5F; Mon, 22 May 2017 03:56:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 22 May 2017 03:56:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=N2gczhrsn1l3fosuhSdhe98sFz25zU68BVKZUsutv XQ=; b=NPuF+dmJ8hwZ5td/CitSKXqhnrfUirz1vSkRcH7Lycmh+77U+BRIOx8FJ 7LEVcgEZfDfq5MPQxepQQKnMdTcv38mXa4yJFMxvZ6iHnTaEYWX7Sol5gDAUz6Z/ pPRuFFw/B6Ayf/zNZzPqkitZzALnaiOYJl59aO8gCCunDuZIS4zoQzi7BXFigDky qM3A0a7Tdr3ykpZbk2DLuEG4oTnLcwW4p836ndAQ7YDW8QziF01UhAzIuyCeWU6D AOU0/WQ5NaCk8P8CaGnTQsUb6ykvBGfhnZ7KrcC3E5nnRCWXcc34byrn94knf+tR PmwP6s4PfItvlRFXBMFnJE+szReJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=N2gczhrsn1l3fosuhS dhe98sFz25zU68BVKZUsutvXQ=; b=loaidbrO8waom2dzJUvN2AtEd97WBk9O4n jMgwYyl0mLVrBJWrjb7QPyMyTtCw0Mq9zaZIvxwKHRbutWeKyMzT9UocL1VibNce eQffcKpYIypQULme2NOxBSRM/hB9mckMiFymcmip9LhJ6JodJpf5IwNYGlTppDEj tl1MJTuOSgwLiJj7R9cUHInchnGtkV3yiF/a3ZWGIClhpXe3W0YLO7GYYe8KS8Nm zgGg/8ypdrjidEB0claPq+PtMW3nHJPiAJXKlxZ4yy1x588Yo4LFR+Pvsa2XlFEL nyVRDvdh0hAHbeNV5EY3vJR0yny9Wf1F8dgB/z8T0YhuG3yVECgg== X-ME-Sender: X-Sasl-enc: Q1AprZyugv0TdkTRDe4VxJBVjreBcwuc7AtkZd3UzdP4 1495439785 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 1607A2475C; Mon, 22 May 2017 03:56:24 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Consensus Call on issues closed by the -03 drafts Message-Id: Date: Mon, 22 May 2017 17:56:22 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:56:32 -0000 Everyone, The -02 drafts incorporate the proposed resolutions to another group of = issues, as listed below.=20 Please have a look through them. If there are any resolutions that you = feel need more discussion, please bring it up, either here on the = mailing list or by commenting on the issue itself. In either case, = please explicitly ask for the issue to be re-opened if you want it to be = reconsidered. If folks do this before the Paris interim, we can hopefully have any = necessary discussions before or during the meeting, allowing us to = publish the First Implementation Draft afterwards, incorporating any = changes needed. See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). This list is also available at = . * #543: Reduce the number of different offset sizes for STREAM = (transport) * #542: Don't include timestamps until after the handshake completes = (transport) * #513: Create more certainty about 0-RTT transport parameters = (transport) * #481: FNV-1a 64 (transport) * #451: No rules limit the sending of BLOCKED (transport) * #443: Split WINDOW_UPDATE (transport) * #442: Invert the connection ID logic during the handshake = (transport) * #439: Unclear stream close semantics (transport) * #434: PADDING Frame performance (transport) * #432: Specify what concurrent stream limit protects (transport) * #425: Do not require clients to reset initial streams (transport) * #419: Get rid of the concurrent stream limit by advertising a maximum = stream ID (transport) * #405: Transport parameter that limits 0-RTT data (transport tls) * #388: Timestamps in acknowledgment of PING? (transport) * #370: Out-of-order Flow Control (transport) * #344: Justify retransmitting handshake packets so slowly (recovery) * #294: Ignore version negotiation if the client version is present = (transport) * #284: Ignore Version Negotiation if it was already done (transport) * #267: Server enforcement of 1280 octet packet size (transport) * #265: Define source address validation in the transport (transport) * #264: Define how source address validation interactions with TLS work = (transport tls) * #263: Counting closed streams against the concurrent stream limit = (transport) * #248: Exemption from congestion control (transport recovery) * #241: What do we do if special packets are lost (transport) * #237: Create a firm recommendation on when to send WINDOW_UPDATE = (transport) * #232: New connection ID message (transport) * #227: Encrypt the initial cleartext packets with a deterministic key = (transport) * #217: Packet reordering / loss distorts open stream limits = (transport) * #200: Race condition between stream creation and MSPC (transport) * #199: Why are reason phrases potentially 65k long? (transport) * #194: Frames should have a length field (transport) * #181: Remove SETTINGS[_ACK] (transport http) * #167: Hash for unencrypted packets (transport tls) * #158: Padding between frames (transport) * #143: Repeating Version Negotiation (transport) * #134: Certificate compression (transport tls) * #123: ACK frame timestamp format (transport) * #89: Version negotiation gaps (transport) * #60: Stateless Reject mechanism needs description (transport tls) * #55: What can change in a different version (transport) * #45: Handshake protocol selection (transport) -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 22 16:56:37 2017 Return-Path: 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 C953A129462 for ; Mon, 22 May 2017 16:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mzvHPyV3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MZcQjNS7 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 Fofe7RJKAfEq for ; Mon, 22 May 2017 16:56:33 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC199129458 for ; Mon, 22 May 2017 16:56:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 32F80956; Mon, 22 May 2017 19:56:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 22 May 2017 19:56:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ItsWA8k9us3uH+szdf vpz9mGJKOuTpz+7MZledLrrCs=; b=mzvHPyV3lcjP3q9+Jivt7RdBJyWqABnni8 Os0bpmnCSgt2gdv80uirymf+fFMGdFB+lTvCXbLTmqn75XDxurTs1qi+wCTIsmfU a3lzvnEprxGMpUjcm4nof+Pwr+apun2Z3dhMEJqeWZfDM1w85myCEUTrq8Pq9WsL yv934CtqAVB3V0CgMUMxUjhqzOZxH5HOWd4gR3HEqaAaS8PQXiFYkEALlspZ5Qvo ZIp2+nANozxe6bbt2qOtuGioGEggnP4gvtQ4LTlkDb1ztgyMYCjaD3n+J88om9F4 qIq+FPw5eBvSubguoqbJCPBOfadU1rL0IWJm4iNcCz02kcLQqczg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ItsWA8k9us3uH+szdfvpz9mGJKOuTpz+7MZledLrrCs=; b=MZcQjNS7 oLTEGu1rGrKFZNEjZNaMrVPbs0JmKMv+0DdWDPM185a6tIPbfp4hU+LKgZoD/Eup bGllRFcTYILG3i9GsFsXfKry8cSvtzl9SU2Et2zMIt8Sx3GR+11DDxzMNRU5oOGf eVF9fqvhH5kzhI+BaXvfxmAnnTWb9OJ93drySwfWKOwHTfR7pWIEWfw1HEKOthwk c5t9qpV2+kL5XTkwWeCjzHqw0kTqsbP5ipYHxIl5I7vUP4x8Z+9OAkxn4pUPkOOm yPr+2fuzHapLZIqguJmMJY0SD54drfRLMrwY88iKAp/Kx6xbP5A1YO4v7QzaLOxk yQ5eLuJ+v1M+kw== X-ME-Sender: X-Sasl-enc: oOEHLh7Vy/oetDm/KrazeB5Dq8JvRQPEJq9XlepVFIVX 1495497390 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id E13B47E1FB; Mon, 22 May 2017 19:56:29 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Consensus Call on issues closed by the -03 drafts From: Mark Nottingham In-Reply-To: Date: Tue, 23 May 2017 09:56:26 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 23:56:36 -0000 > On 22 May 2017, at 5:56 pm, Mark Nottingham wrote: >=20 > Everyone, >=20 > The -02 drafts incorporate the proposed resolutions to another group = of issues, as listed below.=20 That's -03, of course. >=20 > Please have a look through them. If there are any resolutions that you = feel need more discussion, please bring it up, either here on the = mailing list or by commenting on the issue itself. In either case, = please explicitly ask for the issue to be re-opened if you want it to be = reconsidered. >=20 > If folks do this before the Paris interim, we can hopefully have any = necessary discussions before or during the meeting, allowing us to = publish the First Implementation Draft afterwards, incorporating any = changes needed. >=20 > See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). >=20 > This list is also available at = . >=20 > * #543: Reduce the number of different offset sizes for STREAM = (transport) > * #542: Don't include timestamps until after the handshake completes = (transport) > * #513: Create more certainty about 0-RTT transport parameters = (transport) > * #481: FNV-1a 64 (transport) > * #451: No rules limit the sending of BLOCKED (transport) > * #443: Split WINDOW_UPDATE (transport) > * #442: Invert the connection ID logic during the handshake = (transport) > * #439: Unclear stream close semantics (transport) > * #434: PADDING Frame performance (transport) > * #432: Specify what concurrent stream limit protects (transport) > * #425: Do not require clients to reset initial streams (transport) > * #419: Get rid of the concurrent stream limit by advertising a = maximum stream ID (transport) > * #405: Transport parameter that limits 0-RTT data (transport tls) > * #388: Timestamps in acknowledgment of PING? (transport) > * #370: Out-of-order Flow Control (transport) > * #344: Justify retransmitting handshake packets so slowly = (recovery) > * #294: Ignore version negotiation if the client version is present = (transport) > * #284: Ignore Version Negotiation if it was already done = (transport) > * #267: Server enforcement of 1280 octet packet size (transport) > * #265: Define source address validation in the transport = (transport) > * #264: Define how source address validation interactions with TLS = work (transport tls) > * #263: Counting closed streams against the concurrent stream limit = (transport) > * #248: Exemption from congestion control (transport recovery) > * #241: What do we do if special packets are lost (transport) > * #237: Create a firm recommendation on when to send WINDOW_UPDATE = (transport) > * #232: New connection ID message (transport) > * #227: Encrypt the initial cleartext packets with a deterministic key = (transport) > * #217: Packet reordering / loss distorts open stream limits = (transport) > * #200: Race condition between stream creation and MSPC (transport) > * #199: Why are reason phrases potentially 65k long? (transport) > * #194: Frames should have a length field (transport) > * #181: Remove SETTINGS[_ACK] (transport http) > * #167: Hash for unencrypted packets (transport tls) > * #158: Padding between frames (transport) > * #143: Repeating Version Negotiation (transport) > * #134: Certificate compression (transport tls) > * #123: ACK frame timestamp format (transport) > * #89: Version negotiation gaps (transport) > * #60: Stateless Reject mechanism needs description (transport tls) > * #55: What can change in a different version (transport) > * #45: Handshake protocol selection (transport) >=20 >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 22 22:37:01 2017 Return-Path: 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 67D3F127F0E for ; Mon, 22 May 2017 22:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=cB0qC9YP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sjl8J+pB 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 DYrMQLCJy8NK for ; Mon, 22 May 2017 22:36:58 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020471275C5 for ; Mon, 22 May 2017 22:36:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 3BD45E94; Tue, 23 May 2017 01:36:57 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 23 May 2017 01:36:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=rZzEUB00JE3y2XKJ2ipl2JmNZqEvILCl1EWn80IcE jc=; b=cB0qC9YPYs+iIXq8RTzCaCnGIIsMgMn/sSR54zAIiumyfUdVuAc1eIi94 3cp9Mr4lZaChl8qvht1K3HyvOWAJcqT7hkuQUoPLD2u4RvTS83AyofHtCzJvk9Nn O9Y0L/58Cs5SoZjTea5trXwQ3p4jTli2x86tiIK8LbpCPo5bByL7JnLmQKM5MAMR Gi8qOdjKuUqLhSX8KFizrIL19bHhKis4k3VAOFK05PKf61M6mE0eYjHd50+APehk 0zoSKJHCssW3DD2l2NSKrkw6AiYsUNOll4VTe7rhzTQYq1SNCinxkkbi1OzZjmat xlUdyBjBgB4XxtSilzXuhJ7T12wcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=rZzEUB00JE3y2XKJ2i pl2JmNZqEvILCl1EWn80IcEjc=; b=Sjl8J+pBUs2S2UPWDh+545jPrfOvH2e+eC ZI/t/+l0mVAYLeaz7blWhYZDXutOziBDvbD+0kBnRAtEACgMWyItkxHLW3k2cbmN wzo4mD1/2gQQ3VW84Rrf1SWe5PGjxomSIZQplM5sdQWrzvsu2gHVOsrk0KZ0RuJ/ 39YLIKdeKJorjFJxCXAEez5aQn3sQBaxyUp7oLNgIoX5yavEsr53NbDWc59C5uTn 3pT8AA23nEMZ+JoH5RkorsigrOnw0Wsvtmui/eYN2KdGtZHxSDYYFvkwajzIYscl gUnboY3SEurZJ4rQnWHXzBhXuperABdgHoDohPKiWlBtCQdMl4Tg== X-ME-Sender: X-Sasl-enc: ujJkQIjh/hQhXxbMnCYAeM8emHl6vt7GoWIhIY9JrIMZ 1495517815 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 5DC957E59A; Tue, 23 May 2017 01:36:55 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Paris Agenda Message-Id: Date: Tue, 23 May 2017 15:36:52 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 05:37:00 -0000 Everyone, We've updated the agenda for Paris: https://datatracker.ietf.org/meeting/interim-2017-quic-02/agenda/quic/ As you can see, the focus of the meeting is getting the First = Implementation Draft ready. In particular, we'll be focusing on issues = that block that as a matter of priority, so if you want to discuss any = of the proposed resolutions in -03 (see previous message), or feel that = any other issue blocks the First Implementation Draft, please bring it = up as soon as you can. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 30 04:57:08 2017 Return-Path: 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 73070129C06 for ; Tue, 30 May 2017 04:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 10LjgdB1d3uJ for ; Tue, 30 May 2017 04:57:04 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 917D3128D3E for ; Tue, 30 May 2017 04:57:04 -0700 (PDT) X-AuditID: c1b4fb3a-307ff70000004a6a-d4-592d5e0ed965 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 48.52.19050.E0E5D295; Tue, 30 May 2017 13:57:02 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 30 May 2017 13:57:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ncDxMVa5lZFDVruisizGOyIbGJoiXjPi7FMRBoW4dVE=; b=DAxFGRSS1Lqzw8cd8YqjsEQDWHVBgwIIdMBPAK6Ju7FblO60XUVMf//daaM4/6CIxpWBvYvBQ6CK4LTreOshDqu6WArE6Ms5wEDp6DsqLs0n27UgDQNSDenOooGcj025dsHTcGYuQUgZQ2xN52jgkbdsscKe5jL9GB2jTSXTSLk= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Tue, 30 May 2017 11:57:01 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f%17]) with mapi id 15.01.1143.009; Tue, 30 May 2017 11:57:01 +0000 From: Ingemar Johansson S To: "quic@ietf.org" Subject: FW: New Version Notification for draft-johansson-quic-ecn-03.txt Thread-Topic: New Version Notification for draft-johansson-quic-ecn-03.txt Thread-Index: AQHS2TuhYxSGQ5nF/0eD1iKaMWCkTaIMxNcw Date: Tue, 30 May 2017 11:57:01 +0000 Message-ID: References: <149614529835.21808.15099549394486222656.idtracker@ietfa.amsl.com> In-Reply-To: <149614529835.21808.15099549394486222656.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:MNXgvabzqKAeGUsuLupGFM3Q4baceespNjvyWf7onXFIA0864kf5FbQMqbMfGUl6cMkK285aboqqGqCbibC3wZFTUjb4hTfqeTx42cnbv22T9FibEj1vvtW3Wn5lOaHiVtJbF4u08+90i8RJ0A/5yco67otBoaoBFEx9AYC/XLWHjXrqBQGDoWZ/WJ5otu0QPapNzoE5jE+hgVaKUbcyiZWaQdEZ+vpg/h6TrK2CyAFbyZJpjJye8JeuTKmc8vJf/3bonNjzzeOUjgzMyNAwZqD9BOj9NQwpo04RKPV6ddePygNT8yStzWeV4pgTz7E+QwRMEs4jmsk3VoeIfFH5/Q== x-ms-traffictypediagnostic: DB4PR07MB348: x-ms-office365-filtering-correlation-id: 637157fa-66d0-49a0-0c44-08d4a752fb7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(39450400003)(13464003)(377424004)(229853002)(230783001)(33656002)(966005)(5250100002)(5640700003)(7696004)(2950100002)(2906002)(99286003)(14454004)(6506006)(2501003)(6916009)(55016002)(54356999)(2473003)(6306002)(9686003)(15650500001)(53546009)(50986999)(3660700001)(76176999)(86362001)(25786009)(53936002)(5660300001)(38730400002)(110136004)(2900100001)(6436002)(8936002)(7736002)(478600001)(3280700002)(305945005)(189998001)(6116002)(66066001)(8676002)(102836003)(3846002)(74316002)(2351001)(1730700003)(81166006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2017 11:57:01.2262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7ty5fnG6kQftBG4ueBdwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mo4/mQ/S8E94YopKx+wNTDOEe5i5OSQEDCR2Pv2DxuILSRwhFHi 2tPcLkYuIPsEo8S83mtsIA6LQC+zxJHzn9ghMtOYJO4/+MYK4TxklHj++DRYP5uAjcTKQ98Z QWwRAWWJOUsXs4PYwgKeEgvnHWWBiHtJHPjWD1VjJPH17SWwGhYBVYlHk5qYQWxegSiJtz/e skPc5CfxZm43WC+ngL/Eob3nmUBsRgFZifvf74HFmQXEJW49mc8E8Y+AxJI955khbFGJl4// gR3KKNDNKPFh3jWoIgWJV90NbBC2rMSl+d2MIEUSAt3MEo+/PGKFSGhK7Jz/nQXC9pVY3vwU qrlWYlL7U0YIO1NizaR+qPpoiQMLVzFBDPrAJHH7zBSohIzEtldroRp2s0ncPmoACRYpibtX OhknMGrNQvLFLEYOIFtTYv0ufYiwosSU7ofss8ABIyhxcuYTlgWMLKsYRYtTi4tz042M9FKL MpOLi/Pz9PJSSzYxAlPEwS2/rXYwHnzueIhRgINRiYdXLVA3Uog1say4MvcQowQHs5II7+5w oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2M5S+unna9 f7wjPH969K9Q7kl6f79eePfxieQ7zeVXE25oz/8dEz+5ZLOrpOUL8Y+aHzbOsSmSy2CMPS3W zem4wG7dzun/z6b8jfqveEH04tYW0ykbrBtuXb7d4SEiviy46f05nabS5Cl/Z05lnu/odOJu 982kBwd2qzhfWLRSVO++ybPL3LeVBZVYijMSDbWYi4oTARzSKdENAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 11:57:06 -0000 SGkNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgRUNOIGluIFFVSUMgZHJhZnQgdGhhdCBwcm9wb3Nl cyBvbmUgRUNOIGVuY29kaW5nIGFsdGVybmF0aXZlLg0KDQpFbmpveQ0KL0luZ2VtYXINCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBkZW4gMzAgbWFqIDIwMTcg MTM6NTUNClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9o YW5zc29uLXF1aWMtZWNuLTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1q b2hhbnNzb24tcXVpYy1lY24tMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgSW5nZW1hciBKb2hhbnNzb24gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuDQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJ RUNOIHN1cHBvcnQgaW4gUVVJQw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wNS0zMA0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTENClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAz LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAzDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1qb2hhbnNzb24tcXVp Yy1lY24tMDMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1v IG91dGxpbmVzIHRoZSBFQ04gKEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uKSBzdXBw b3J0DQogICBpbiBRVUlDLiAgVGhlIGRyYWZ0IHNwZWNpZmllcyB0aGUgRUNOIG5lZ290aWF0aW9u IGFuZCB0aGUgRUNOIGVjaG8NCiAgIGFuZCBpbiBhZGRpdGlvbiwgZGlmZmVyZW50IGFzcGVjdHMg b2YgZmFsbGJhY2sgaW4gY2FzZSBvZiBFQ04gZmFpbHVyZQ0KICAgYXMgd2VsbCBhcyBPUyBzcGVj aWZpYyBpc3N1ZXMgd2l0aCBFQ04gYW5kIG1vbml0b3JpbmcgZm9yIEVDTg0KICAgY2FwYWJpbGl0 eS4gIFRoZSBpbnRlbnRpb24gaXMgdGhhdCBtb3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwDQog ICB1cGRhdGluZyBvdGhlciBuZXcgb3IgZXhpc3RpbmcgUVVJQyBwcm90b2NvbCBzcGVjaWZpY2F0 aW9ucywgdGh1cyBpdA0KICAgbWF5IGJlIHBvc3NpYmxlIHRoYXQgdGhpcyBkcmFmdCBkb2VzIG5v dCB3YXJyYW50IGEgd29ya2luZyBncm91cA0KICAgc3RhdHVzLg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue May 30 12:41:30 2017 Return-Path: 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 9CA0D1292FD for ; Tue, 30 May 2017 12:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 cMSMxprscEa9 for ; Tue, 30 May 2017 12:41:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 92B621250B8 for ; Tue, 30 May 2017 12:41:26 -0700 (PDT) X-AuditID: c1b4fb2d-1e1ff70000000d37-6d-592dcae4173a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.54.03383.4EACD295; Tue, 30 May 2017 21:41:24 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 30 May 2017 21:41:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S31yuPmXvFY2V+AmnfH1AKjc5GihIDCpwfqU4wAqP5U=; b=BsmqYNCQjk7Fhign49eaduiPrHfH21cPLC9Bj0aCyyoz9Y/XcxLPvIAaEUGBrWoIP8dbJ1F3CtQj0yvhgxVZE/Ye9e2MOVTR1c2nIrn8y7NonH6IxY5prVxDcowRXe/0CMwqQcgpZmJl0OxBRdjypYpuhjsOvyjhs0RwSRV6QiU= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Tue, 30 May 2017 19:41:22 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f%17]) with mapi id 15.01.1143.009; Tue, 30 May 2017 19:41:22 +0000 From: Ingemar Johansson S To: "Jana Iyengar (jri@google.com)" , Ian Swett CC: "quic@ietf.org" Subject: On bytes per packet in draft-ietf-quic-recovery-03 Thread-Topic: On bytes per packet in draft-ietf-quic-recovery-03 Thread-Index: AdLZfLb4ud156r9pSgCVMNZTNcnVEg== Date: Tue, 30 May 2017 19:41:22 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:q0/Vv3meozU0AaP4qKLN+tr/91ljxKKmmHrPgj9lGjBzpzE83EgR1kka2KhEUnP0ysOSN0YhzEyFajijV2L7/MB32qb6jWc5ltRaI+535rRXobngKpHtFzCEu0ux2UK8MAI2PMKNFk/RRmyz8B7Fp1KLyY+gdchSNoRqo83M0KxpYdBMrtWIpyAXeYj1LWZzbP7qJSLmWduaW2g8s/xWuBfXdkDMlEWuXEO3UomxsqgzFy+4iRapkl8fJUhcATkjNNCJEKUPbEQTLWHEqfgCH6ULqJVykbfjM1Kh9DJtOxoGoZHS7ueXjYACGYPdP8S8B4mcVEl89x9yDcM8js1NRQ== x-ms-traffictypediagnostic: DB4PR07MB348: x-ms-office365-filtering-correlation-id: d685be87-3354-4789-f9a3-08d4a793da12 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39860400002)(39840400002)(39410400002)(39400400002)(39850400002)(478600001)(8936002)(7736002)(5660300001)(38730400002)(2900100001)(6436002)(74316002)(81166006)(8676002)(3280700002)(19609705001)(189998001)(66066001)(102836003)(6116002)(3846002)(790700001)(99286003)(14454004)(55016002)(6506006)(7696004)(5250100002)(33656002)(230783001)(2906002)(86362001)(4326008)(53936002)(25786009)(54896002)(9686003)(9326002)(6306002)(54356999)(3660700001)(50986999)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3487F71991FCFAB81938136C2F00DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2017 19:41:22.5540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHO7t31+tqcJ2KD/OlWkqWbFZW7IOE9iUrCu1VDamZVx3OKff6 WhnLIG0rKpmmkak5DV8iUTMXtWwtMRMUTahsSqllWSR+UbE0t7PAb7/zf37nf+4DlyYkDUIp rdZmsZxWpZFRIrIi9om3fLJXHret2Fe5MGoWKkte15DKa9VrI4io6tbsKJNpQRAtiBeFJ7Ea dQ7Lhe45I0ptaL5PZfaE541/e0rp0OxuPXKngdkJtYYuNz0S0RLGhqCuwkriQw+C8flx54Rk rhNQrat3aWUCmB0ddmmfERj7+4WOMooJhwbrHHKwF3MSPpjvOZlgNoHxrc7peK44r2pnSOxE QvGDZUKP6BVWgO5noANJJghsXU4UM/FQ+cgpI8YfxuZGSVzoAx8nqgR4AwZMz/oJzN7wfXxJ 6PgyxNxAMDQ9InD0ALMRbMZc7PjDYJUBORxgDARcLupzXd4C5qo5EvMhaB6wCTEXQEnRJMI9 amjvS8bxKTB26yncMyOAphd/KDzwg44fD10PLJPQNtghwKtLwf7uKsLsB1OfngtvouA7qxbC nAGWxnLCwWLGA95UTJA4V8D7UiOFOQTqa6YJzHIoX7KSq/Nq5NaIvHmW59NTdoQpWE59lucz tAotm9WKVn6gl+2L8k7UNB1pRQyNZOvE0XflcRKhKofPT7cioAmZl/h390okTlLln2O5jNNc toblrciXJmU+4gjLQKyESVFlsWksm8ly/6cC2l2qQ3Wa3J6F3pbHIxJ1cEjTsQDoU+nLW/LT 7F9TJfOiA1SUckNc6MHKQGmwb3LQYc5+KcznykhcxpfjY+RUImduI1sT1g9OHrldU1C2S1xa b7loaTIfXTy/eY1Ot29oOM+M7Kb9MYZycUBCwAn61t+awsJRY+JehenXBc4zptOjW0byqart WwmOV/0DrEuybTwDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 19:41:29 -0000 --_000_DB4PR07MB3487F71991FCFAB81938136C2F00DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am reading myself though the QUIC drafts, in particular draft-ietf-quic-r= ecovery, trying to get an idea of the meaning of bytes in a packet. What does a QUIC packet constitute ? QUIC QUIC+UDP QUIC+UDP+IP I would believe that it is only the QUIC packet alone that counts in the dr= afts or ?, on the other hand the MTU is 1460 bytes so I am not sure ? BTW, a minor nit in draft-ietf-quic-recovery-03 acket_packet -> acked_packet =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB3487F71991FCFAB81938136C2F00DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I am reading myself though the QUIC drafts, in parti= cular draft-ietf-quic-recovery, trying to get an idea of the meaning of byt= es in a packet.

What does a QUIC packet constitute ?

QUIC

QUIC+UDP

QUIC+UDP+IP

 

I would believe that it is only the QUIC packet alon= e that counts in the drafts or ?, on the other hand the MTU is 1460 bytes s= o I am not sure ?

 

BTW, a minor nit in draft-ietf-quic-recovery-03

  acket_packet -> acked_packet

 

 

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB3487F71991FCFAB81938136C2F00DB4PR07MB348eurprd_-- From nobody Wed May 31 04:53:29 2017 Return-Path: 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 4384212EA8D for ; Wed, 31 May 2017 04:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 KMBLJbXmZ1Ei for ; Wed, 31 May 2017 04:53:26 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B84126CC7 for ; Wed, 31 May 2017 04:53:26 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2AB59340534 for ; Wed, 31 May 2017 13:53:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.23201); Wed, 31 May 2017 13:53:22 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Wed, 31 May 2017 13:53:22 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19240927 for quic@ietf.org; Wed, 31 May 2017 13:53:22 +0200 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_7CD826ED-D093-4CDC-8699-B5844E1B969F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Should QUIC have a path-verifiable proof of source address? Date: Wed, 31 May 2017 13:53:21 +0200 Message-Id: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> To: QUIC WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 11:53:28 -0000 --Apple-Mail=_7CD826ED-D093-4CDC-8699-B5844E1B969F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We have a few contentious points in the design of QUIC, and how that = design interacts with devices deployed in the Internet. I'd like to = start the discussion on two such points, to see if we can come to some = kind of consensus as to what we want QUIC to do without regard to how it = does it, keeping in mind our charter requirement that QUIC have = "security and privacy properties that are at least as good as a stack = composed of TLS 1.3 using TCP (or MPTCP when using multipath)." I'll start with the easier one: "Shoud QUIC allow devices on path to distinguish QUIC traffic with valid = source addresses from traffic with spoofed source addresses?" The utility of this property is obvious: it would allow in-network = reflection/amplification, backscatter, and spoofed-DoS protection = equivalent to that available with TCP. This is already provided by TCP = state tracking devices for TCP endpoints more or less as a side effect = of their operation. One could argue that this is pointless, since botnets-of-things have = made spoofing irrelevant, and careful design (of new UDP protocols), = aggressive patching (e.g. of ntpd), and lagging DNSSEC deployment are = taking care of the most severe amplification vectors. The other side of = that argument is essentially that every little bit helps. The risks and efficiency tradeoffs are a matter of the exact design = used, of course. However, it seems to me that establishing whether this = is a desirable feature, and at what cost, seems like a good way to = decide whether we should design for it, as opposed to letting discussion = of mechanisms drive discussion of requirements. Cheers, Brian --Apple-Mail=_7CD826ED-D093-4CDC-8699-B5844E1B969F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLq6xAAoJEIoSt78L6kajeKoP/jTTvjBQ2CvhEa1Rc6m1uLZv KQqrhqlbzap9gsOLy4JYcxiMYCFJBXOGjGmyzv+HSK+sfqBRhjqMPRjGsGAvlJL4 9EZYBUFFLWT5aODbTI6LB6gMiyFHYEXXNO8QBYUig1ROTJN54JSA0whFy2YjWpYF ypk/rnVwVEJCPdl7FbJQ3fwG13rh8TgRfqG821gEl2umkNK0bqiHL/HzUQAIAKRn 1V8dMXNb1V+6N2swQ2+GaolUBE110YEo3LltjFxAsKGxriDHNhBCgXlKD+bPVfle xLMHbK/xanf6dwyNq8JyHATUPTuwu0ZyrUBq31DcDwOJfNvQV/ToNPa7ouNF53RZ w/nJdjG93D+eXRW1cBNFB1lVACswS+0OB45I+3ImeFBUF+JSH3e8vxJIjJBMiuNu 2mFpaj9IgH8/n0nP0pNTibuvx8aaZlQHyHH46gtw3LYFJi20J9RUsUTvYcw/eBD8 Au3BbvHiH05TTxVnpXQXgvhnOI3CfMMsDnbzgR46Defgx/ZWN9+PQACl0QD79YEG bSJ2w0+9iTZKgDMdnuHJtx5y1YwL1567+Zs9In41F3RMhvRM98yX/51jcYadBTr5 zWtCXvNRvg9KZRUJcDDX42vNAVTyTBFdOwItmDnUkfPsKPaGbdqZWx5m0bCmS/S1 e8dWMFlSKMIm1k0G6DQ9 =NNcq -----END PGP SIGNATURE----- --Apple-Mail=_7CD826ED-D093-4CDC-8699-B5844E1B969F-- From nobody Wed May 31 05:04:28 2017 Return-Path: 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 7E79D129BBD for ; Wed, 31 May 2017 05:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nXT_sccIEeYb for ; Wed, 31 May 2017 05:04:24 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCF2126CC7 for ; Wed, 31 May 2017 05:04:24 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l14so5487015ywk.1 for ; Wed, 31 May 2017 05:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DPRe86Su/Rgc2A6qMz1tIWYY9/yfoJLDb08JOfb7fOs=; b=GtIgvAhOvuklwWtIsGWQQ9t7gjhr90kbxnOFCd4pEItIKhGgjhRcPwYkZUMZ6tB9tt kp5QEhC04wLzdpMFAYMb62RPXHB2dI79RauZD5HfvhOf3eAAf3q8naa/GPY3ZbHxpYEB ZXKGomTD4a/Ajpb1Q1iIu/oVAu7NIE3ZPMy7SHERm3PckJ2X1PkgQAwgJ+GIptukHDvy HM1TXa5RAQ4AEedPYHrylxSyDPmQHdj7i3vxtjsUAhdigEixZY2JLIFK0jH0zBBwizKi 1BrRPJvr2tL7gTIv2eYXG57ZFDeMLTUtqlEa0eL4ItWSJ8uSZ7PhJjdncmP/oCE8OYFS sm7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DPRe86Su/Rgc2A6qMz1tIWYY9/yfoJLDb08JOfb7fOs=; b=D7WudYG82CZU5ECX37MuZcF2YGgCOUxjAH9FcUWRPhcECxCgYajR7lQo2eBhM43dUP ktb0SE1nlQJyiaYbbMapq62hhb1Du5oxx0jCtZmrK6pBTZlOo2mqeet+5oqM7flFRI5I 2msnRZ+qQ7Zp08cDaQxDRsiDC4yU53eWUIC0KgORmj7jb+OzNbqnS5WGvGX+KpKZBAkb g57HXQZ4WInjeAImQkA3zu9pGkMrrXmISlDyKIp5jEW+AIziMKJKs03gohn5QAX+tE8y b+/JVw3vr/7t6rruER3y1MQW7Q7lRhRRlHefePNVKyZp13ZHysT3ekB750aKK9mWfGBe 5GhA== X-Gm-Message-State: AODbwcCKz0JUkh5y8ZWODP6WsytZUPVwxKMbfushFUt1nyEkHDJBUOLB AZpmcaV5vvLlrAynQwVknCcU6vmaf9FnUXQ= X-Received: by 10.129.89.131 with SMTP id n125mr19053638ywb.181.1496232263684; Wed, 31 May 2017 05:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.212.133 with HTTP; Wed, 31 May 2017 05:04:03 -0700 (PDT) In-Reply-To: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> From: Erik Kline Date: Wed, 31 May 2017 21:04:03 +0900 Message-ID: Subject: Re: Should QUIC have a path-verifiable proof of source address? To: "Brian Trammell (IETF)" Cc: QUIC WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114920c69ba9510550d0b872" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:04:26 -0000 --001a114920c69ba9510550d0b872 Content-Type: multipart/alternative; boundary="001a114920c694b7ee0550d0b8ba" --001a114920c694b7ee0550d0b8ba Content-Type: text/plain; charset="UTF-8" On 31 May 2017 at 20:53, Brian Trammell (IETF) wrote: > Greetings, all, > > We have a few contentious points in the design of QUIC, and how that > design interacts with devices deployed in the Internet. I'd like to start > the discussion on two such points, to see if we can come to some kind of > consensus as to what we want QUIC to do without regard to how it does it, > keeping in mind our charter requirement that QUIC have "security and > privacy properties that are at least as good as a stack composed of TLS 1.3 > using TCP (or MPTCP when using multipath)." > > I'll start with the easier one: > > "Shoud QUIC allow devices on path to distinguish QUIC traffic with valid > source addresses from traffic with spoofed source addresses?" > > The utility of this property is obvious: it would allow in-network > reflection/amplification, backscatter, and spoofed-DoS protection > equivalent to that available with TCP. This is already provided by TCP > state tracking devices for TCP endpoints more or less as a side effect of > their operation. > > One could argue that this is pointless, since botnets-of-things have made > spoofing irrelevant, and careful design (of new UDP protocols), aggressive > patching (e.g. of ntpd), and lagging DNSSEC deployment are taking care of > the most severe amplification vectors. The other side of that argument is > essentially that every little bit helps. > > The risks and efficiency tradeoffs are a matter of the exact design used, > of course. However, it seems to me that establishing whether this is a > desirable feature, and at what cost, seems like a good way to decide > whether we should design for it, as opposed to letting discussion of > mechanisms drive discussion of requirements. > > Cheers, > > Brian > My main concern here would be that preserve the ability to migrate connections. Allowing on-path but non-endpoint devices to distinguish traffic as you describe opens up the opportunity for them to do it incorrectly/badly thereby making some implementations of connection migration unreliable (at best). There may still be ways to support connection migration and support this kind of traffic analysis, though. --001a114920c694b7ee0550d0b8ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 3= 1 May 2017 at 20:53, Brian Trammell (IETF) <ietf@trammell.ch>= wrote:
Greetings, all,

We have a few contentious points in the design of QUIC, and how that design= interacts with devices deployed in the Internet. I'd like to start the= discussion on two such points, to see if we can come to some kind of conse= nsus as to what we want QUIC to do without regard to how it does it, keepin= g in mind our charter requirement that QUIC have "security and privacy= properties that are at least as good as a stack composed of TLS 1.3 using = TCP (or MPTCP when using multipath)."

I'll start with the easier one:

"Shoud QUIC allow devices on path to distinguish QUIC traffic with val= id source addresses from traffic with spoofed source addresses?"

The utility of this property is obvious: it would allow in-network reflecti= on/amplification, backscatter, and spoofed-DoS protection equivalent to tha= t available with TCP. This is already provided by TCP state tracking device= s for TCP endpoints more or less as a side effect of their operation.

One could argue that this is pointless, since botnets-of-things have made s= poofing irrelevant, and careful design (of new UDP protocols), aggressive p= atching (e.g. of ntpd), and lagging DNSSEC deployment are taking care of th= e most severe amplification vectors. The other side of that argument is ess= entially that every little bit helps.

The risks and efficiency tradeoffs are a matter of the exact design used, o= f course. However, it seems to me that establishing whether this is a desir= able feature, and at what cost, seems like a good way to decide whether we = should design for it, as opposed to letting discussion of mechanisms drive = discussion of requirements.

Cheers,

Brian

My main concern her= e would be that preserve the ability to migrate connections.

Allowing on-path but= non-endpoint devices to distinguish traffic as you describe opens up the o= pportunity for them to do it incorrectly/badly thereby making some implemen= tations of connection migration unreliable (at best).

There may still be ways to = support connection migration and support this kind of traffic analysis, tho= ugh.
--001a114920c694b7ee0550d0b8ba-- --001a114920c69ba9510550d0b872 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgDK/31G4wj+PdsaltFhNwi1uiG3RKe+NO wNUnLwBCK4YwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTMx MTIwNDI0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAE5HLmpugjXDi7VoeXci83xhljoRFR7jGpyrb/plsO0dAZHuzt24 leQY+StgIK85xhtOtSCEqeJ5yDzt8s6USDO2p3eOAdIoS51d9BxDwEWLytLUhDYJtFFCZW6tV8Bm Nn9pd3nUe10l+31AbbGrtQMTzYo2z+/ZEeDIBvtTzQjFQhRPY7pJvoYUDiOVESFloo/xr1yCxutp X8nN0Z28Zo1RRdIeLHhv/UuR/9yJN8hLO1nTc+2CScUoWEJl5/sK751AGnEh+RfVMQSipd4MkBIH QOvSVfoLNXElEoCoigK1TGqy2ysqV9+6sYh8SKLvhLaaKYUHUfE/af0yZnsqi38= --001a114920c69ba9510550d0b872-- From nobody Wed May 31 06:22:46 2017 Return-Path: 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 43F35129BEC for ; Wed, 31 May 2017 06:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 WSimV3Cg9n8k for ; Wed, 31 May 2017 06:22:43 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138FC129BDB for ; Wed, 31 May 2017 06:22:43 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A1DA340D4D; Wed, 31 May 2017 15:22:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.8096); Wed, 31 May 2017 15:22:40 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 31 May 2017 15:22:40 +0200 (CEST) Received: from [195.176.111.18] (account ietf@trammell.ch HELO public-docking-cx-1324.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19254275; Wed, 31 May 2017 15:22:40 +0200 Subject: Re: Should QUIC have a path-verifiable proof of source address? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_54DE166D-BEAB-432E-A1AA-8704A7419ECE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Wed, 31 May 2017 15:22:40 +0200 Cc: QUIC WG Message-Id: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> To: Erik Kline X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:22:45 -0000 --Apple-Mail=_54DE166D-BEAB-432E-A1AA-8704A7419ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Erik, > On 31 May 2017, at 14:04, Erik Kline wrote: >=20 >> On 31 May 2017 at 20:53, Brian Trammell (IETF) = wrote: >> Greetings, all, >> "Shoud QUIC allow devices on path to distinguish QUIC traffic with = valid source addresses from traffic with spoofed source addresses?" > My main concern here would be that preserve the ability to migrate = connections. >=20 > Allowing on-path but non-endpoint devices to distinguish traffic as = you describe opens up the opportunity for them to do it = incorrectly/badly thereby making some implementations of connection = migration unreliable (at best). >=20 > There may still be ways to support connection migration and support = this kind of traffic analysis, though. Okay... so I'll mark that down "this seems useful, but not at the cost = of any flexibility in connection migration." Actually, your answer suggests an alternate and potentially more useful = framing for this question: "which design properties are you not willing = to sacrifice to get the ability for devices on path to distinguish QUIC = traffic with valid source addresses from traffic with spoofed source = addresses?", which captures the risk/utility tradeoff nicely. Thanks, cheers, Brian --Apple-Mail=_54DE166D-BEAB-432E-A1AA-8704A7419ECE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLsOgAAoJEIoSt78L6kajb2wP+QEFnjTK5utKgjeZfvrBv6Zv MBEc43/UsZ8dIri/QK2jOI+O9QhD5P2TQJBwKEQgj/dA01l/DLui/BbkZuqfCJ7p FngQ6f45O/F8EgZSYZ4JEpaASyp9McgU0GWRMGJIlJpbPmZ8wfm2id0SUHA8Qdpo 3Wgt+1GosyT6ldIHuGOCfuFSPe01dLO+sN20GaSYkCOcDQuxZCXYl5B8nHNq8eaw FVcJyVzMcOGyXlTHctvQKXg/UjJvO7Lh2t0M9efWddQGLTtF8zvyn3Us/fPIGZLT ft7/X3ZSsH3/wr5iA/y8fCdvdfaff3p1o2eHy3oDrDDPkkqHWwAQtGtNPadL8Xtk aZliQuV75WmtrgF8CHgc8Sd4HSGm9FBhOA2WnVUaZ2y+1mqiMYl0OMRAtrHJrCQa UIIYuZGMlD+Cv27RBPP2aCFEjT/Swhacu4nKY+rc8Mzxons15ogDR4ipYSqty/RY qmKsQBv/kCqw0IDaqkZGsXcoBkfGN8n7M4phb3anUhyLLwNi/GavKrSpaxXpDUDH lEjOMjx3l4fZFahh8Tg1jZ3bUFJXOhFviJrdaOB4fAWEhkwNEsis7W1ENaJDDoY0 dlEPGGKIR1ggpPqkxE4sAgxtvLRwxNOe5eBG4tz7Nf4R3YQ8VkErlnnEXhu1sjg2 +r60F9VnOmzdjcJtaOSt =GaT8 -----END PGP SIGNATURE----- --Apple-Mail=_54DE166D-BEAB-432E-A1AA-8704A7419ECE-- From nobody Wed May 31 06:43:38 2017 Return-Path: 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 DE240129406 for ; Wed, 31 May 2017 06:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 MTHykxN3ZqTE for ; Wed, 31 May 2017 06:43:35 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBD1129BF8 for ; Wed, 31 May 2017 06:43:34 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id r66so3713372yba.2 for ; Wed, 31 May 2017 06:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aOTy3KDXty4f1eA7lQJh8jjaSvjZO+xia1B0HHJ7tTk=; b=HvG3IBOS9H26vbtKJ0UOrZJ9eXtG1E+tt+DOtLhGULUZax67pmEVU4ER/oLbHDHrID oixhqt918D46PHpSnrtEVjCHeejTqgz9frtvJ4tiVfpFVOStVkxOEXA2hG1JePI97Kt/ Ylo648u+7DvHsltK5WaxE5z8T6eB4+wMyuNdI2RwnzJpRWWlUH3H+r/jdqzNR2QxB/b4 kDUHe5DfdlwzGI7tMzWz9TxH4we8uvA/GhiXJURRAcr4PiSXhx8RNLwKWHQsGxTKNVx/ JFA2ZCHPypjRf9v6zJjy0zUwOKJtUW1hB/BOGnDYKyWXOpgj/KP2dysw2Sa7EGnPpJ4y kBSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aOTy3KDXty4f1eA7lQJh8jjaSvjZO+xia1B0HHJ7tTk=; b=kmrTWY/uWWWy4fRppzzLzlPRWP0E+P0a05FMNWaE3hrZGVmAzIzy4CxfkcegMg3dNU dY8HNwEJhpakaNuwxeiiUneJ4o1x1tlT190ErcgiHNy4uJF8ejilOc1ek42zlaTj9m10 wcKfK9ebzbR2N+m7GaKLeMT9Xv66NtGPluSxZ4HEwoq2dm3+skPGDluAdtveggimB+Ki tQEgDkmELErkdnf2QSUEkJ54uKTqDPeTmHDLn1sheggYL85QPXSj1J34JisKIMiJpKVZ kvnR7csoRQ9Z0hIrOq8QJDGx+KUoSr/Z7IlVWdE4uQjScCIj3TYwRLoK3tenKGAclzBi mAUw== X-Gm-Message-State: AODbwcBTOsGKa0W4ghfm3mreDpZXOGIxHvLoe4TvD+FE8T+P6HL+Oe5y lzzRVTcW8nLgyu0n4o4DMsG6oF1fTo+Ou4rGcw== X-Received: by 10.37.122.129 with SMTP id v123mr55088803ybc.157.1496238213862; Wed, 31 May 2017 06:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.212.133 with HTTP; Wed, 31 May 2017 06:43:13 -0700 (PDT) In-Reply-To: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> From: Erik Kline Date: Wed, 31 May 2017 22:43:13 +0900 Message-ID: Subject: Re: Should QUIC have a path-verifiable proof of source address? To: "Brian Trammell (IETF)" Cc: QUIC WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114baca8440b470550d21b57" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:43:37 -0000 --001a114baca8440b470550d21b57 Content-Type: multipart/alternative; boundary="001a114baca83d791a0550d21b5d" --001a114baca83d791a0550d21b5d Content-Type: text/plain; charset="UTF-8" On 31 May 2017 at 22:22, Brian Trammell (IETF) wrote: > Hi, Erik, > > > > On 31 May 2017, at 14:04, Erik Kline wrote: > > > >> On 31 May 2017 at 20:53, Brian Trammell (IETF) > wrote: > >> Greetings, all, > > > > >> "Shoud QUIC allow devices on path to distinguish QUIC traffic with > valid source addresses from traffic with spoofed source addresses?" > > > > > My main concern here would be that preserve the ability to migrate > connections. > > > > Allowing on-path but non-endpoint devices to distinguish traffic as you > describe opens up the opportunity for them to do it incorrectly/badly > thereby making some implementations of connection migration unreliable (at > best). > > > > There may still be ways to support connection migration and support this > kind of traffic analysis, though. > > Okay... so I'll mark that down "this seems useful, but not at the cost of > any flexibility in connection migration." > > Actually, your answer suggests an alternate and potentially more useful > framing for this question: "which design properties are you not willing to > sacrifice to get the ability for devices on path to distinguish QUIC > traffic with valid source addresses from traffic with spoofed source > addresses?", which captures the risk/utility tradeoff nicely. > > Thanks, cheers, > > Brian > A comment and request to make a distinction (though I know it's complicated). [ comment ] Anything on-path boxes can do analytically can become a point of policy control in a vendor's marketing slide deck. There is only embrittlement down this road, I fear. [ (complicated) distinction ] I would like to argue that there is a distinction between: [1] on-path elements that are within the administrative domains of either end-point ("administratively related to an endpoint") and [2] on-path elements in administrative domains not associated (except by peering/transit) with either endpoint. It might be possible to permit analysis (and therefore policy enforcement) by the former and not the latter, if we assume there can be some cooperation with endpoints and on-path elements in their administrative domain. If possible, I think this might give the best of both worlds: the benefits of analysis and policy enforcement but only afforded to the endpoints and their administrative domains (no interference from unrelated parties). --001a114baca83d791a0550d21b5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 31 May 2017 at 22:22, Brian Trammell (IETF) <ietf@trammell.ch>= ; wrote:
Hi, Er= ik,


> On 31 May 2017, at 14:04, Erik Kline <ek@google.com> wrote:
>
>> On 31 May 2017 at 20:53, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> Greetings, all,

<snip>

>> "Shoud QUIC allow devices on path to distinguish QUIC traffic= with valid source addresses from traffic with spoofed source addresses?&qu= ot;

<snip>

> My main concern here would be that preserve the ability to migrate con= nections.
>
> Allowing on-path but non-endpoint devices to distinguish traffic as yo= u describe opens up the opportunity for them to do it incorrectly/badly the= reby making some implementations of connection migration unreliable (at bes= t).
>
> There may still be ways to support connection migration and support th= is kind of traffic analysis, though.

Okay... so I'll mark that down "this seems useful, but not = at the cost of any flexibility in connection migration."

Actually, your answer suggests an alternate and potentially more useful fra= ming for this question: "which design properties are you not willing t= o sacrifice to get the ability for devices on path to distinguish QUIC traf= fic with valid source addresses from traffic with spoofed source addresses?= ", which captures the risk/utility tradeoff nicely.

Thanks, cheers,

Brian

A comment and reque= st to make a distinction (though I know it's complicated).

[ comment ]
<= div class=3D"gmail_extra">Anything on-path boxes can do analytically can be= come a point of policy control in a vendor's marketing slide deck.=C2= =A0 There is only embrittlement down this road, I fear.

[ (complicated) distincti= on ]
I would like to argue that there is a = distinction between:

=C2=A0 =C2=A0 [1] on-path elements that are within the adm= inistrative domains of either end-point ("administratively related to = an endpoint") and

=C2=A0 =C2=A0 [2] on-path elements in administrative domai= ns not associated (except by peering/transit) with either endpoint.

It might be p= ossible to permit analysis (and therefore policy enforcement) by the former= and not the latter, if we assume there can be some cooperation with endpoi= nts and on-path elements in their administrative domain.=C2=A0 If possible,= I think this might give the best of both worlds: the benefits of analysis = and policy enforcement but only afforded to the endpoints and their adminis= trative domains (no interference from unrelated parties).
--001a114baca83d791a0550d21b5d-- --001a114baca8440b470550d21b57 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgC5ux8WxslEeT3mr9wQHla2OYQRwiXIrt yOv4pkVEuF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTMx MTM0MzM0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAD3rVRwk2fsOFvCEmQBOGmAfFHq+oU4Dj3d8gAeHDyisbooVUt8L 9b/v9dLaVQ87LTMCTW09xyi4AlbjesgdMTvDx1atPtVy+c6ENaThBdypEN+gGeaz2eDbLKo7i6OX 56rdv6U7OtDYs2cBIoa2vnm4Aj8UGPYgNNbs8/gTsasuTehMyP43jB9ySnITLL70uZ5ez6nzdfRc HBSZXScIi0PqWcrWGqDPVDnahxZh9Itp/eFY8ZVTnge89sukW/aewIw473ki/QBm0ArQAQqBXhtD C0WlsDae4wMDZR/ZID4VUS2fWH+ukneTeYLgdn06aMRjJC/Z9YJ3ZY9YmGnA7S0= --001a114baca8440b470550d21b57-- From nobody Wed May 31 08:23:55 2017 Return-Path: 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 912091286D6 for ; Wed, 31 May 2017 08:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com 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 MNjQRxfr1FlV for ; Wed, 31 May 2017 08:23:52 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AF81274D2 for ; Wed, 31 May 2017 08:23:51 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id l39so2274926qtb.1 for ; Wed, 31 May 2017 08:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance; bh=zjBQhncBiXsbe6+sUnrCJNjQWFab0KEbZEqjypiAM68=; b=JHYhM6hHwhhBS/6zZIElzmY6thconI9PujIOVEgfEYCAb6HQL2TP1phi8QXTaWdF5/ 62tNjhdekIW/uNrytzeR8+FLaDnZcuPMZlY+qw+WNdcveDh38406z3QAh9cFPIdoLTKk 3a3X4tS0oIMcf45TGuYIMt91AoUn5HSdLcjdZHovToTxBD9xmnJKglDdcvGpiCD91HGu EnSbWfxud1Xhd7NTbwJS9Dz7mUwcUkLPdeKvVbY2E3wq7T6opiNlt4hv+cUO0gYF5dit 7F7cJTU3GvlhSAZwg7tDAyP5xAAK4eaYz/J+khIZt2ktJthD86muF7FCmb21gqE2FUT3 z+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=zjBQhncBiXsbe6+sUnrCJNjQWFab0KEbZEqjypiAM68=; b=Of5scnelGOwRXTGEfrsO2kgq/qYESiZGRtPjTENIQqDYW0I3tIeU6PQ6sMjYHhvvo8 wrtZbJiJUFTyOe+oZnmK0/n/wW7Bb65ajXnJi99KMxwqI92oD5ooogd8Z6JVACLi7jGH FFHou0XePpwZsZX7IjXbCIz58ZVmVqT4qiD00rMNrNkoHyxILeAF8/h2M4wldkHKrW/Y csRNIBhRe1XVweI8WkYJy7I4V3qdYmLQd1mqK7GoL+8hW9YDzE/4/7clc8u1JfR74408 UZ7CZ0Z/EPZynwLrvcOO5japzJuSnDpn6SdbIk7j43W1mJpZQjmCA2FiAGGRMt0muW0r TbRw== X-Gm-Message-State: AODbwcDXNHwjI2q59Ty9CE3b2vDLr7qB00IZg7dAzzoxe46YFKUDtEDI /+9I+ZIf8gxJhqFY85BUGw== X-Received: by 10.200.49.229 with SMTP id i34mr29693438qte.113.1496244230900; Wed, 31 May 2017 08:23:50 -0700 (PDT) Received: from ?IPv6:::ffff:192.168.0.196? (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id j204sm10621371qke.27.2017.05.31.08.23.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 08:23:50 -0700 (PDT) Message-ID: <592ee006.d5a0370a.621c9.06bf@mx.google.com> MIME-Version: 1.0 To: "quic@ietf.org" From: Dmitri Tikhonov Subject: Why mandate stream creation order? Date: Wed, 31 May 2017 11:23:48 -0400 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_B18CACBF-CAC9-4E68-8691-707865F4EED7_" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:23:53 -0000 --_B18CACBF-CAC9-4E68-8691-707865F4EED7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hello, Section 10.1 of draft-ietf-quic-transport-03 states that =E2=80=9CStreams M= UST be created in sequential order.=E2=80=9D My question is: why mandate s= tream creation order, since the other side may receive out-of-order packets= ? Let the implementation do what it wants with Stream IDs =E2=80=93 as lon= g as it does not go over the limit, all should be well. This phrase is a holdover from the previous version; this requirement seems= to be unnecessary since issue 435 has been resolved. - Dmitri. P.S. I have read CONTRIBUTING.md and decided that mailing list is the way = to ask this question, rather than opening a GitHub issue. If this is incor= rect, please let me know. --_B18CACBF-CAC9-4E68-8691-707865F4EED7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hello,

 

Section= 10.1 of draft-ietf-quic-transport-03 states that =E2=80=9CStreams MUST be created in sequential orde= r.=E2=80=9D=C2= =A0 My question is: why mandate stream creation order, since the other side= may receive out-of-order packets?=C2=A0 Let the implementation do what it = wants with Stream IDs =E2=80=93 as long as it does not go over the limit, a= ll should be well.

 

This phras= e is a holdover from the previous version; this requirement seems to be unn= ecessary since issue 435 has been resolved.

 

  • Dmitri.

&nbs= p;

P.S.=C2=A0 I have read CONTRIBUTING.md and decided = that mailing list is the way to ask this question, rather than opening a Gi= tHub issue.=C2=A0 If this is incorrect, please let me know.

 

= --_B18CACBF-CAC9-4E68-8691-707865F4EED7_-- From nobody Wed May 31 08:31:24 2017 Return-Path: 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 348981243F6 for ; Wed, 31 May 2017 08:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wzisTJt59jCW for ; Wed, 31 May 2017 08:31:19 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8B51293E3 for ; Wed, 31 May 2017 08:31:19 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 21DEA340D4D; Wed, 31 May 2017 17:31:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.4874); Wed, 31 May 2017 17:31:16 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 31 May 2017 17:31:16 +0200 (CEST) Received: from [195.176.110.241] (account ietf@trammell.ch HELO public-docking-etx-2691.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19273288; Wed, 31 May 2017 17:31:16 +0200 Subject: Re: Should QUIC have a path-verifiable proof of source address? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FACF53B4-4CD2-49B0-B279-97A207A86E20"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Wed, 31 May 2017 17:31:15 +0200 Cc: QUIC WG Message-Id: <54DB143C-3E91-4AB0-9132-8194A9AB0010@trammell.ch> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> To: Erik Kline X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:31:22 -0000 --Apple-Mail=_FACF53B4-4CD2-49B0-B279-97A207A86E20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31 May 2017, at 15:43, Erik Kline wrote: >=20 > A comment and request to make a distinction (though I know it's = complicated). >=20 > [ comment ] > Anything on-path boxes can do analytically can become a point of = policy control in a vendor's marketing slide deck. There is only = embrittlement down this road, I fear. Of course. The higher-level argument I'm making behind this whole line of = questioning is that there is a principle of conservation of (perceived) = control in the deployed Internet, and that this will cause embrittlement = to happen anyway. By being explicit and conservative about our aims for = what can be done with the QUIC wire image by devices on path, we as = protocol designers gain some measure of control over where this = embrittlement occurs. > [ (complicated) distinction ] > I would like to argue that there is a distinction between: >=20 > [1] on-path elements that are within the administrative domains of = either end-point ("administratively related to an endpoint") and >=20 > [2] on-path elements in administrative domains not associated = (except by peering/transit) with either endpoint. >=20 > It might be possible to permit analysis (and therefore policy = enforcement) by the former and not the latter, if we assume there can be = some cooperation with endpoints and on-path elements in their = administrative domain. If possible, I think this might give the best of = both worlds: the benefits of analysis and policy enforcement but only = afforded to the endpoints and their administrative domains (no = interference from unrelated parties). In general, I agree with you that there's a useful distinction here. And = I agree completely that this function, spoofed traffic recognition and = rejection, only really makes sense within the receiver's administrative = domain. (...and now, ignoring my own entreaty to focus on requirements as = opposed to mechanisms in this aside...) Making this distinction leveragable at runtime, however, is tricky: you = need some way to establish trust with those devices; and either = something like out-of-band like PCP, relying on on the "local to the = path" endpoint to use it; or a much more elaborate inline signaling = mechanism than IMO it makes sense to wedge into QUIC. With respect to this *specific* question, though, I don't see how this = would work with respect to spoofed traffic detection/rejection, since = any design pattern leveraging this distinction necessarily involves the = endpoints, and the whole point of spoof rejection as it's currently = deployed is to reduce load on the endpoints. Cheers, Brian --Apple-Mail=_FACF53B4-4CD2-49B0-B279-97A207A86E20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLuHDAAoJEIoSt78L6kajt5YP/i4pCctgHrpcp3yQAwajD01K 55odYBL6xK4ObS2bhHSXQMs1tUk7SlFD8F4Uf/Lw5xW+NXXjeQZg3ZGSU2K0wiCh 8CwQ3N5dv9v8ITpFoS2e1e7XgqFg5JI9yV6WPODteFDcD1ocE/RwLs711UIHp5ss 3l4LhCgvLHQ7MhetqTgipXg78K+Xyci491km24WlpkbW1t/Fw8LzraLQafsA4qJf absPmSgML0Oipe0AglmLYOmIsMhvoqTbtBa/X2n4qsA8l94c9zQMHQnwjJcX8dMg 6D4isFtMKzo9pq4DMzb9eIcx4GveQp/D1oqoAwP+CMAolI2GVjbFTnyW2lZyVwg/ fCA5tIdvome8wD2qN3DRCn44wxAqCi15NBYIdjLtiU0bEqXNJ9o4gqbGHYz9KKkO uJtu/5Rmum0iNChKP90L7gLm4juampjDE3isgwi2qJ9AHoDdrCEHx8zTfLghGnqr LGhXqrWSYAuEQNEXlzshnuYjgSLsFgPBU8VDizVfPM4wTaGpYpfIws1DGt+DoS4f CmZgqwercmeQOwxFJUBeG+eID/DqGhDBb8mckv5P5LDXBX9br9nWUs8hfg0SnK0q ovrHT7DMcc8852Jl+R6VUHYU4p6TEWgjRSI4VIGgyEc1lgGmD+Skvc0p0FAEumYM 4a7pZ54uAli3FSXVSRUF =v5vw -----END PGP SIGNATURE----- --Apple-Mail=_FACF53B4-4CD2-49B0-B279-97A207A86E20-- From nobody Wed May 31 10:14:15 2017 Return-Path: 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 445D8129AB2 for ; Wed, 31 May 2017 10:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 XJUnLzizIKls for ; Wed, 31 May 2017 10:14:12 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258F3129A96 for ; Wed, 31 May 2017 10:14:04 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 31 May 2017 13:14:01 -0400 From: Dave Dolson To: "Brian Trammell (IETF)" , Erik Kline CC: QUIC WG Subject: RE: Should QUIC have a path-verifiable proof of source address? Thread-Topic: Should QUIC have a path-verifiable proof of source address? Thread-Index: AQHS2gSJtVPz9+3NT0qZMF6P90IGe6IOmwKAgAAV9wCAAAW+gIAAHi+A///Y8nA= Date: Wed, 31 May 2017 17:14:01 +0000 Message-ID: References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <54DB143C-3E91-4AB0-9132-8194A9AB0010@trammell.ch> In-Reply-To: <54DB143C-3E91-4AB0-9132-8194A9AB0010@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.114] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 17:14:13 -0000 > ... the whole point of spoof rejection as it's currently deployed is to r= educe load on the endpoints I would add, to also reduce load on the network.=20 In many cases the network (or one link thereof) presents more of a bottlene= ck than the capacity of the endpoint. In such cases, mitigation at the receiver is too late. -Dave -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Wednesday, May 31, 2017 11:31 AM To: Erik Kline Cc: QUIC WG Subject: Re: Should QUIC have a path-verifiable proof of source address? > On 31 May 2017, at 15:43, Erik Kline wrote: >=20 > A comment and request to make a distinction (though I know it's complicat= ed). >=20 > [ comment ] > Anything on-path boxes can do analytically can become a point of policy c= ontrol in a vendor's marketing slide deck. There is only embrittlement dow= n this road, I fear. Of course. The higher-level argument I'm making behind this whole line of questioning = is that there is a principle of conservation of (perceived) control in the = deployed Internet, and that this will cause embrittlement to happen anyway.= By being explicit and conservative about our aims for what can be done wit= h the QUIC wire image by devices on path, we as protocol designers gain som= e measure of control over where this embrittlement occurs. > [ (complicated) distinction ] > I would like to argue that there is a distinction between: >=20 > [1] on-path elements that are within the administrative domains of ei= ther end-point ("administratively related to an endpoint") and >=20 > [2] on-path elements in administrative domains not associated (except= by peering/transit) with either endpoint. >=20 > It might be possible to permit analysis (and therefore policy enforcement= ) by the former and not the latter, if we assume there can be some cooperat= ion with endpoints and on-path elements in their administrative domain. If= possible, I think this might give the best of both worlds: the benefits of= analysis and policy enforcement but only afforded to the endpoints and the= ir administrative domains (no interference from unrelated parties). In general, I agree with you that there's a useful distinction here. And I = agree completely that this function, spoofed traffic recognition and reject= ion, only really makes sense within the receiver's administrative domain. (...and now, ignoring my own entreaty to focus on requirements as opposed t= o mechanisms in this aside...) Making this distinction leveragable at runtime, however, is tricky: you nee= d some way to establish trust with those devices; and either something like= out-of-band like PCP, relying on on the "local to the path" endpoint to us= e it; or a much more elaborate inline signaling mechanism than IMO it makes= sense to wedge into QUIC. With respect to this *specific* question, though, I don't see how this woul= d work with respect to spoofed traffic detection/rejection, since any desig= n pattern leveraging this distinction necessarily involves the endpoints, a= nd the whole point of spoof rejection as it's currently deployed is to redu= ce load on the endpoints. Cheers, Brian From nobody Wed May 31 11:28:55 2017 Return-Path: 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 04548128854 for ; Wed, 31 May 2017 11:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 AAyKIr4jn2w4 for ; Wed, 31 May 2017 11:28:52 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E91200C1 for ; Wed, 31 May 2017 11:28:52 -0700 (PDT) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by linode64.ducksong.com (Postfix) with ESMTPSA id C85D33A0A7 for ; Wed, 31 May 2017 14:28:51 -0400 (EDT) Received: by mail-qk0-f174.google.com with SMTP id y201so18866209qka.0 for ; Wed, 31 May 2017 11:28:51 -0700 (PDT) X-Gm-Message-State: AODbwcCyxXGHKGiM+9SqIE3L31hYUNm1+NcjyltntL+mfFnJt6d1+sIf hkifkkHq0Ue4j172DgBtUsRYzJjOLg== X-Received: by 10.55.91.70 with SMTP id p67mr31223611qkb.237.1496255331510; Wed, 31 May 2017 11:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.178.74 with HTTP; Wed, 31 May 2017 11:28:51 -0700 (PDT) From: Patrick McManus Date: Wed, 31 May 2017 14:28:51 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: enumerate packets not to ack? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114cad4c87300e0550d617e9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:28:54 -0000 --001a114cad4c87300e0550d617e9 Content-Type: text/plain; charset="UTF-8" Quic-Friends, It seems clear that Version Negotiation and Server Stateless Retry packets should not be acknowledged (afterall they cannot be retransmitted, and they use packet numbers not generated by the sender).. but I can't find any text that says this. Am I missing it, should we add it, other? I guess I'm particularly concerned about interop running into "The sender MUST close the connection if an unsent packet number is acknowledged" if acks are sent here.. -P --001a114cad4c87300e0550d617e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Quic-Friends,

It seems clear= that Version Negotiation and Server Stateless Retry packets should not be = acknowledged (afterall they cannot be retransmitted, and they use packet nu= mbers not generated by the sender).. but I can't find any text that say= s this. Am I missing it, should we add it, other?

= I guess I'm particularly concerned about interop running into "The= sender MUST close the connection if an unsent packet number is acknowledge= d" if acks are sent here..

-P

<= /div>
--001a114cad4c87300e0550d617e9-- From nobody Wed May 31 11:58:01 2017 Return-Path: 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 83C82128ACA for ; Wed, 31 May 2017 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 yXYpIiYU3PgL for ; Wed, 31 May 2017 11:57:56 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315B21200C1 for ; Wed, 31 May 2017 11:57:56 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 9so15168592pfj.1 for ; Wed, 31 May 2017 11:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jeSX7iFt7QNiyUEGnltknar50QXMZ2HF+EFaiim5ZvM=; b=lHJOum5c37bZiKOLsik8+sC76YDz+nwcbMOPN/ZnyjHxyxfXxVSzMOf7pG3oJ5u/L1 AZzslUadDCYzPc/wP0i3AR7AuxSG8DHms/zjb2Eb9m0lUPFsT2ODSr/4WeyMJetyC9uU wbNGgD2ntmFm8YTxwhAsYt9R790oGNr210yeoyNwhCsCtxWbP14UaQy3EsdHlCG+ylf8 nDZyYkZOrxicfGIPghM0suInviUlGweIRR8KdPtKoYWNWLDK3c+YmUzT8E2T29TyoiEw SF2XeASfZVWFy91wB9mmUEI0JVVo+bTLJPpQRyhs5qSMeCjdpQ4a/DzB+hV/5bQ2onT9 ewFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jeSX7iFt7QNiyUEGnltknar50QXMZ2HF+EFaiim5ZvM=; b=ONnXE1I5SUFGS9rdn4jWcFf3+i91XB7YCIMpnsKE02qTvs5WX3OVs+pIh9rf/RW2V6 8Ou8ObOp3GCId5BZMzxeiTfDIUeqFj8DBHDtfUzJiGRkFRy+5NCuUF0tHB6IfNhhSuO7 pfYlCVDGI7SGnD6xVdWx20eybBhg1hrYDRklazNJmvjyYBQlLi+vKIUth0uGlco7Dx+Q qUX8Z05KZ1gFMnRGQv89cWNvrkwT2Qcky6FZ+nuNMBrBftA+rRKzVRM16gJLhtTIQVVK nxrqFiTJZUPF6a/AahnfVmIiOtIfMsbxhgNOzznab6ARd0lOvgU0gb8Jyb8rARey6Qki nz/w== X-Gm-Message-State: AODbwcB80ptqocNEh/xEOfunybQVKYs4eWtD1lSNqllZcuvTrCrzblGL ck0fmdcO4k1bTns2qECOxlLlKIaPm9cB X-Received: by 10.98.224.1 with SMTP id f1mr32292263pfh.116.1496257075701; Wed, 31 May 2017 11:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.165 with HTTP; Wed, 31 May 2017 11:57:55 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 31 May 2017 11:57:55 -0700 Message-ID: Subject: Re: enumerate packets not to ack? To: Patrick McManus Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113900be7d9f700550d67f6d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:57:59 -0000 --001a113900be7d9f700550d67f6d Content-Type: text/plain; charset="UTF-8" Section 9 says acks must not generate acks, but this is a gap. We should enumerate the packet types (and perhaps frame types too) that must not generate acks. I've filed #563 . On Wed, May 31, 2017 at 11:28 AM, Patrick McManus wrote: > Quic-Friends, > > It seems clear that Version Negotiation and Server Stateless Retry packets > should not be acknowledged (afterall they cannot be retransmitted, and they > use packet numbers not generated by the sender).. but I can't find any text > that says this. Am I missing it, should we add it, other? > > I guess I'm particularly concerned about interop running into "The sender > MUST close the connection if an unsent packet number is acknowledged" if > acks are sent here.. > > -P > > --001a113900be7d9f700550d67f6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 9 says acks must not generate acks, but this is a = gap. We should enumerate the packet types (and perhaps frame types too) tha= t must not generate acks. I've filed #563.


On Wed, May 31, 2017 at = 11:28 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
Quic-Friends,
<= div>
It seems clear that Version Negotiation and Server State= less Retry packets should not be acknowledged (afterall they cannot be retr= ansmitted, and they use packet numbers not generated by the sender).. but I= can't find any text that says this. Am I missing it, should we add it,= other?

I guess I'm particularly concerned abo= ut interop running into "The sender MUST close the connection if an un= sent packet number is acknowledged" if acks are sent here..

-P
=

--001a113900be7d9f700550d67f6d-- From nobody Wed May 31 12:16:09 2017 Return-Path: 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 D96E71275C5 for ; Wed, 31 May 2017 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com 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 iYPeX-qz5zVR for ; Wed, 31 May 2017 12:16:07 -0700 (PDT) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2BE126FDC for ; Wed, 31 May 2017 12:16:07 -0700 (PDT) Received: by mail-qt0-x241.google.com with SMTP id j13so3061970qta.3 for ; Wed, 31 May 2017 12:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance; bh=UpNfFLfy58MShyiIhv6hkmlI3C16YZ/UlRNiuIx1niw=; b=oOj2MIZFsgv3lGnLUNSeNqHeJlnnvABK8gKy3Xjp4QjWPiBMTwPdQrrGwp4iH15OWl Gmlo5DTKKKAYACFyYtT0JKw954IUDDIpk3paOvTj23Oa+wf8E0//Z/NA9tey/irtZo6m j5xpiAHuw2M44JSpAqpha5jr4meQQqNdPbNiDRmJISRoMZktv8AjKtlds4zZNezrFlIh 4sK2ifi3GEkNIwMUYTSsQX49iM2dx7oZwG4A7lUHDiB7Hg/0I0fPwa00arcDI9dzL6EF mnaDzVy/Sg6DxoSO2cZllgRQ3cbtv5yMcy7VsKLVDEw7FG+BKpWddXR2bWe+t3S2vuk7 OuOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=UpNfFLfy58MShyiIhv6hkmlI3C16YZ/UlRNiuIx1niw=; b=AZP+U03JckXJtYLlQHhXfxrN85oA0tsHSXU10E8/B8vQ75mdC+/VoWw8tZ7n+asE2p KEJq4sitgUg/3gcYTAr+j9svejO8zvhiIJCZpfmrWgZb39ODQvL3Dsa9dPJXRz0ykUsq zQIH03gM0mdVJd5wW2c7lopce9DO+1fKxlNWjJlrN7fEL3MSiSOGTKfwNZ72b8zakUy3 /btyVUhLF4HN/u9GmpivLM3U1JxciI6LRlcOydGgk2Ju20TtDM6byRYU2vJIvTK5SLO/ JR5zTrC6k+HsriSfqOGYXdTQcwt/acE5Le1kVSAJVFza7JPuVeHrPrQZ4m6k7pscol2g KkKg== X-Gm-Message-State: AODbwcB7U7CqZY0RFrzMgBby/Hm26arG6oJjs8kWsGFEG9FnXzl9tgGX Ma1lhyBWyIXgY/ShqP5ruw== X-Received: by 10.200.35.230 with SMTP id r35mr33236929qtr.167.1496258164553; Wed, 31 May 2017 12:16:04 -0700 (PDT) Received: from ?IPv6:::ffff:192.168.0.196? (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id y17sm11093410qtc.29.2017.05.31.12.16.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 12:16:03 -0700 (PDT) Message-ID: <592f1673.d125ed0a.8312f.350f@mx.google.com> MIME-Version: 1.0 To: "quic@ietf.org" From: Dmitri Tikhonov Subject: All stream frames are valid in IDLE state Date: Wed, 31 May 2017 15:16:00 -0400 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_9503849C-77C5-4A15-8C88-85F48E3EFA4D_" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 19:16:09 -0000 --_9503849C-77C5-4A15-8C88-85F48E3EFA4D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hello, Section 10.2.1 of draft-ietf-quic-transport-03 says that =E2=80=9Cany frame= other than STREAM, MAX_STREAM_DATA, STREAM_BLOCKED, or RST_STREAM on a str= eam in this [that is, idle] state MUST be treated as a connection error.=E2= =80=9D This list is exhaustive: no other frame types apply to a stream. This para= graph can be removed. - Dmitri. --_9503849C-77C5-4A15-8C88-85F48E3EFA4D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hello,

 

Section 10.2.1 of draft-ietf-quic-tra= nsport-03 says that =E2=80=9Cany frame other than STREAM, MAX_STREAM_DATA, = STREAM_BLOCKED, or RST_STREAM on a stream in this [that is, idle] state MUS= T be treated as a connection error.=E2=80=9D

 = ;

This list is exhaustive: no other frame types apply to a st= ream.=C2=A0 This paragraph can be removed.

 

- Dmitri.

 

= --_9503849C-77C5-4A15-8C88-85F48E3EFA4D_-- From nobody Wed May 31 13:09:49 2017 Return-Path: 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 46FF11270A0 for ; Wed, 31 May 2017 13:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 UdohJPfan6w8 for ; Wed, 31 May 2017 13:09:46 -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 78449120725 for ; Wed, 31 May 2017 13:09:46 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dG9w7-0006mi-Ju for quic@ietf.org; Wed, 31 May 2017 22:09:43 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dG9w4-0000ya-M9 for quic@ietf.org; Wed, 31 May 2017 16:09:41 -0400 Received: (qmail 30869 invoked from network); 31 May 2017 20:09:39 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.129]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 May 2017 20:09:38 -0000 To: quic@ietf.org References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> From: Christian Huitema Message-ID: <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> Date: Wed, 31 May 2017 13:09:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p8qehSwAAe6bnVNGNL65EqJdO13TseC0i" Subject: Re: Should QUIC have a path-verifiable proof of source address? X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXpLBbS4XiOO2BtzoPdv/NNfRcOb18WfxGyg6Om6u4YYm+JRzuI0KxQPUDde kimNQWo5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK01d1deOI5 CyvhtUNd0D+8CrbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa9r4/WJ1RLWJwzRV9d3nJc5yB/JkQGYxSR77 rOmXOEHrxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:09:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p8qehSwAAe6bnVNGNL65EqJdO13TseC0i Content-Type: multipart/mixed; boundary="XGIDsSe2ANrhE3uLDBvIWtWUJDr0mSo9f"; protected-headers="v1" From: Christian Huitema To: quic@ietf.org Message-ID: <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> Subject: Re: Should QUIC have a path-verifiable proof of source address? References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> In-Reply-To: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> --XGIDsSe2ANrhE3uLDBvIWtWUJDr0mSo9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/31/2017 4:53 AM, Brian Trammell (IETF) wrote: > "Shoud QUIC allow devices on path to distinguish QUIC traffic with vali= d source addresses from traffic with spoofed source addresses?" Brian, I am not sure I understand your requirement. Do you mean something like the reachability verification implicit in the three ways handshake of TCP? Or do you mean some kind of cryptographic proof that the device is allowed to use the source address? -- Christian Huitema --XGIDsSe2ANrhE3uLDBvIWtWUJDr0mSo9f-- --p8qehSwAAe6bnVNGNL65EqJdO13TseC0i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZLyMAAAoJELba05IUOHVQ0lEIAI9kTSxw0u/dWAkZTxPf5mbZ hsEB2+Zczp8tzEiz1SXTf1ZuN/WAeGJ/92p25GGjNv6XacBDhyE+525HtTKE4T8H P727GEaaQYBvdr83lvkZhRIt98U22Yt7D2Ztl9vrBn72Y+UcNSSmvuxAtijNVI6h w09nZhpCZJagwWJcY388pNseOVuFAAL7UXluiLLZqtx/9hmPIcEpnWRzii3z6vAD tpQ/YRlOHTNHOhunidpcVIwkSGRr0aLwrxtWOyWYIpHW7D+VXh2l4kQvTZNNTNcl waNOIWvqpK1eCEt56RgI7gRNaPSt5X16ZTPolQ6ac6WzAc0wS7TM/khkDc0qEys= =YIDs -----END PGP SIGNATURE----- --p8qehSwAAe6bnVNGNL65EqJdO13TseC0i-- From nobody Wed May 31 18:21:57 2017 Return-Path: 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 88323129ABE for ; Wed, 31 May 2017 18:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZTJxfOR_TESe for ; Wed, 31 May 2017 18:21:55 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05EB1294A2 for ; Wed, 31 May 2017 18:21:54 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id 99so18329115lfu.1 for ; Wed, 31 May 2017 18:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=StsdgMtZGnkunJpejv5qWnt+XroErWEcV6NybZXaYfA=; b=vANv8cM+f+VmbaY127uyxTrcceMAJtzPM74zY0bwYALcfIhoTT6uaN04OgjrJI817S 6kDpUqRfiPy9hZgjO6wdRgM/ugEBztZ4hv8Y0zivC7p0LgpNU1jSPtmq+XChpyAV5OPs NNtgtgK4nEkhdu5/w9+zBfGcEPfB4LNcTyvjzqb9NawOQIs+Sbg+lIq1lx7IAUeusTPP Ns3v3mYn9m3DFGtWc9sQGpHQuIAdTB+SDyujTLkgJnjAnbg+1gcox6I+za6kKv1PuRSs vX/ryRO011VdBV8bXDDmr/0EvGelLrcWhkUf2MkJ7f6MUthvMZ7uYhOSXFpyM/kxKqJp 4vbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=StsdgMtZGnkunJpejv5qWnt+XroErWEcV6NybZXaYfA=; b=nNK1YYd0Pepoc/8bY6JR9guRzno8mio8sndaLL8zjJS0BvlJj0UrcHk46Ao6/NzUWT 1nweSFVZuUp/CC4hoZEmnEpcgXE+21xm76rrPkOFlZ2ibFZLpwg6JlY//erEDO+hFCQ0 2aGZrLlH1+WC7pWeAf8yeok++viivJeI0qoKArXWBGV2V/JWagrYBdDcBF57GP3kksWE RAaALozt2U34i4cIBAiTQExIrG/mnobZ6hk9ZN3DAaKs71W56s9vPNItEMrNhGknh4cU eLsSBZ+Ob4okRm51p0lcCS2Ew2h46OgG16MqaMg/i3Lhfu7mNJd0YLHM3f5Mi1Fo5c2O R7Fg== X-Gm-Message-State: AODbwcBiKg4o76tSp5I2WI7NFyNU7nLj18Ze2Td/f6O0tKdGICXhXfzM 3GUDGg2MdZZMm9LPj+Dyqvi4+9D3Og== X-Received: by 10.46.7.10 with SMTP id 10mr9058888ljh.113.1496280112978; Wed, 31 May 2017 18:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Wed, 31 May 2017 18:21:52 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 1 Jun 2017 11:21:52 +1000 Message-ID: Subject: Re: enumerate packets not to ack? To: Jana Iyengar Cc: Patrick McManus , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 01:21:56 -0000 On 1 June 2017 at 04:57, Jana Iyengar wrote: > Section 9 says acks must not generate acks, but this is a gap. We should > enumerate the packet types (and perhaps frame types too) that must not > generate acks. I've filed #563. What's the taxonomy? Can we split this based on frame type? PADDING and ACK alone don't generate the need for an ACK. However, a packet with any other frame type does. Except when they are carried in Server Stateless Retry packets, which never generates acknowledgments. Version Negotiation packets don't contain frames so they don't cause acknowledgments to be needed. Here's a thought: maybe they should. From nobody Wed May 31 18:29:38 2017 Return-Path: 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 07A97129443 for ; Wed, 31 May 2017 18:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XjENAJPLvIxq for ; Wed, 31 May 2017 18:29:35 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D671292CE for ; Wed, 31 May 2017 18:29:35 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id a136so3803153lfa.0 for ; Wed, 31 May 2017 18:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=89fJvVYQcnsO+nfXNy+WwTLKxfulI1HpCwt6Njsb9lg=; b=Zd86DAPqHUdviksZTPZ6tsi66SnCHEZ65eJmh5sR8qjRr95qexcjE94197SNboOLxf j2ru5TWhwuS6b3HIADF+h83Gg0fWPmHHvjl+ko6FfX80KlIzVDGPddELziuNmGHvS2Fs KvaaWSnIikh5XB7SGbsZHKtoeE4JIwGM5MAS+/PwDlDh/S3XSqbNW/Fu/+hVp6aILElC b1TENGBOjILo4bgapbnMZb15HI+SduDkcYOVYAsPJzMkLw0yb98sXYwpPzlJHH0sTN7n Dfl0CVR/G64UaB2EYIXWHHLQljcV8z36K1/d7onJ/3rPVETQ2Bw0v5AaZOcRmsxRrFAm ZKEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=89fJvVYQcnsO+nfXNy+WwTLKxfulI1HpCwt6Njsb9lg=; b=WJoUm7cdMAS6IEvG9DuhIZsZR8tjFPl43/blV6zf83//HiR35GwmweCuRdDrDjwByE 3g020oRK0PhkAGr8yY4ujeO9RhAkkjgGyvD2XQ7vSGZmHD/eTNWZewcQv6DKrm8Q/5QR 1dQVh5a5WsHKzwgiJdkFTfvGBFZ78cK0mzTKFKNYB8ZTqCuJdWmPOcVnFza2EBdqtXL4 fLpiXo5sbkrxMyEebOi/skaYWAyJS11HCTlVnwnBLyKYayKJvPHqFp8uYS0CZirUwQ4N vJY9JgPr+K/HsMJWLJ8MIOctNvlJUxV/t2JKfeX7VGAKltUzW+E4LETKXdWidgZ/8iZ7 VneQ== X-Gm-Message-State: AODbwcDucUbgV5TqLjBkZXKXL+xcpjbq5hm9HSsyK4EdK4sLkcDl1lk5 v5ZrZfyvMFtkmeUhTOZ1Y6UEUcYIWNio X-Received: by 10.46.81.89 with SMTP id b25mr8660043lje.33.1496280573848; Wed, 31 May 2017 18:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Wed, 31 May 2017 18:29:33 -0700 (PDT) In-Reply-To: <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> From: Martin Thomson Date: Thu, 1 Jun 2017 11:29:33 +1000 Message-ID: Subject: Re: Should QUIC have a path-verifiable proof of source address? To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 01:29:37 -0000 On 1 June 2017 at 06:09, Christian Huitema wrote: > Brian, I am not sure I understand your requirement. Do you mean > something like the reachability verification implicit in the three ways > handshake of TCP? Or do you mean some kind of cryptographic proof that > the device is allowed to use the source address? At risk of speaking for Brian, I think that this is intended to cover the simple reachability verification implicit in TCP. That is, proof that the endpoint was able to see a packet that was sent to their claimed address. The verification provided by ICE also works. There, it's not a three-way handshake, but two independent request/response validations. (I think that I see a companion to Brian's "what is an endpoint?" doc: "what is a path?")